[Readers interested only in technical matters should feel free to skip this (lengthy) message. I sent a draft of it to Koichi Murase, Martin D. Kealey, and Chet. Chet informed me that he thought it would be acceptable to post here and that he expected to follow up on it.
Since I first drafted it, Martin and I have had a multi-round, and, I think, pleasant and respectful private exchange. I feel that the main topics covered here are important for volunteer-driven and -governed Free Software projects, reflecting some values and good practices we've lost over the past 25 years as corporate sponsorships have come to play a larger role in FLOSS development and models of governance.] Hi Koichi, Good to hear from you. At 2025-09-11T00:25:43+0900, Koichi Murase wrote: > 2025年9月10日(水) 20:09 G. Branden Robinson <g.branden.robin...@gmail.com>: > > > That's not just observing, that's participating. This was exactly > > > my point: one can't follow a ticket UNLESS one adds a comment. > > > > As Chet pointed out, one can instead subscribe to this list, > > bug-bash. > > This mailing list only receives the notification of a new ticket, > meaning that replies therein won't be notified here. If one wants to > follow the discussions without being included on the CC list, one > needs to repeatedly open the ticket pages that one is interested in. A > new message is sometimes posted to a very old ticket, so one actually > needs to visit all existing tickets regularly, which is impractical. Chet clarified in an email to Savannah #67486[0], which didn't get archived in the tracker--I think because he didn't GPG-sign it--that he has the Savannah to bug-bash reflector configured this way deliberately out of concern that people would complain of too much list traffic otherwise. > > > There has been a depressing display of ad-hominem attacks on what > > > is supposed to be a technical mailing list. > > > > I don't agree. An ad hominem attack is a fallacy wherein one > > attempts to imply that a person's claim is false due to a defect of > > their character or circumstances. > > I think Martin is talking about the following reply from you: > > https://lists.gnu.org/archive/html/bug-bash/2025-09/msg00086.html > > > than having everything is gatewayed through a “boss” human. To me > > > it feels like the FSF has become an unapproachable cathedral, > > > while commercial systems like Github & Bitbucket are more like > > > bazaars where participation is encouraged. > > > > Oh, I see, you're a member of the ESR school. Forget my advice. > > There is likely no hope for you. > > So I guess you didn't mean to disagree Martin's claim by the above > paragraph, but you just commented it as an independent statement, > which is independent of the discussion itself. Yes?--if I'm following you. It's not for me to confirm or refute Martin's statement about his own feelings; in that mode of expression, he's not claiming to assert objective fact. I can't read his mind. > Why did you need to include the above paragraph if it was independent > of the discussion? I reckon I don't always trim the messages to which I reply as brutally as I might. > By the way, what is the ESR school? What do you specifically mean by > "no hope for Martin"? Why there is no hope for a member of the ESR > school? [I trimmed a couple of paragraphs on ESR; they proved superfluous to what Greg, Chet, and Collin have said on the matter. I add only this.] For a chronicle of Eric S. Raymond's practices as a software developer and project (co-?)manager, I recommend the following. https://invisible-island.net/ncurses/ncurses-license.html > > > So the situation is not going to improve until either (a) there > > > are substantial improvements to Savane and Savannah, > > > > Not that I expect _you_ to listen, [...] > > You imply that Martin won't hear, but is that true? How did you know > Martin's future responses? I stated an expectation, not a certainty. As you likely know from probability theory, expectation values often lie somewhere between zero and one. If we proceed only upon certainties, we are likely to stand still. I don't think either Martin's messages or my responses to them constitute a crisis, or even abnormal business. People sometimes clash. Suppression of conflict is not _management_ of conflict, but its sublimation--often, in a volunteer project, into something worse, like nonparticipation--an outcome that is desirable only if someone truly contributes nothing of value to the community in _everyone's_ opinion. As it happens, I appear to have been wrong. In private emails Martin has paid me the compliment of attending to my words closely. > > I'll give you an example. > > > > The foregoing is something of which I thought most people had > > acquired understanding by the age of 20 or so. I might not be > > mistaken, but rather some people find sport in pretending they lack > > it. [rearranging] > This is a mailing list for technical issues of Bash. Primarily, yes--but in the absence of a dedicated discussion list for project management, personnel issues--which need not be matters of conflict, but also can be simple notices of limited availability due to going on holiday[6]--or other "meta" matters, it's as good as any. I infer that Chet feels similarly, and doesn't interpret the list's charter as rigidly as you do, else he wouldn't have indulged a joke in response to one of my own messages.[1] A collegial environment leaves some room for humanity. I try to practice similar latitude on the groff@gnu list, for which I have administrative responsibilities. If I'm wrong about the boundaries of acceptable subject matter here, Chet can tell me so, publicly even, and I'll try to honor his wishes. If he imposes draconian limits, I know I have the option to leave. My E(x) of that outcome is near zero. > Are you also playing a sport to pretend to lack it by posting the long > discussion on Martin? I'd say I'm attempting to practice an art, not a sport. No score is kept, and the outcome is not zero-sum. We can all learn from each other and improve; but not all learning is passively, effortlessly, or comfortably acquired. Differential equations class was painful for me. > Martin is not a part of the Bash program, and this is not a place to > debug Martin's behavior. I disagree not just with your conclusion but with your choice of metaphor. Human beings are not programs or machines. We are made of meat, not bits. Reproaches need only be private when they are severe (and maybe not even then[4]). Public airing of a discussion forum's norms and standards of communication is how this information is best socialized--meaning, transmitted among participants and lurkers alike. No spectators exist to learn from a one-on-one private counseling, and if an authority figure applies too heavy a hand, no one else can see them do so. Similarly, closing public meetings by going into "executive session" can aid the privileged to avoid public accountability.[2] Open processes of conflict resolution and rule negotiation give all participants a chance to critique the existing norms, afford an opportunity for those with expertise in other projects to step forward and share potentially valuable perspectives, and let the entire community evaluate whether those who enforce its rules deal with people consistently, and whether they conduct themselves hypocritically or with favoritism. Those properties are key to maintaining an equitable and democratic environment even when some members have a lot of administrative privileges. They give the governed more of a voice in their governance; should that not be the case in a volunteer-run project? Openness better prepares participants to take on greater responsibilities, up to and including accession to administrative roles themselves in the event of a "developer hit by a bus" scenario. Apart from the well-known "(SA)BDFL" model where there is one autocrat and a group of co-equally wretched supplicants who can graduate to sycophants, one popular alternative is to post a (frequently legalistic) "Code of Conduct" somewhere and impanel a committee to enforce it. This committee administers demerits only privately (except, at its own option, in cases of escalation), asserts that disclosure of demerits by the recipient is itself a form of transgression--a "violation of [the committee's] privacy(!)"--and mutes or permanently bans participants with or without notice to the rest of the community.[7] It's an excellent system for cultivating a climate of fear and servility, because no one besides those with privileges to administer discipline can possess reliable knowledge about whether advice, reproach, or disciplinary measures are administered fairly. You can see how easily this system can rearrange a community into an "in group", where the people "in charge" can behave as they wish, and everyone else, the "out group", must practice great restraint and/or curry favor with the "in group". Some people find this form of government strongly appealing. Its most famous expression is known as "Wilhoit's Law".[5] Conservatism consists of exactly one proposition, to wit: There must be in-groups whom the law protects but does not bind, alongside out-groups whom the law binds but does not protect.[8] That alternative dovetails with a phenomenon, encountered frequently on the political left but also in "independent" evangelical Christian churches (almost invariably right-wing), known as "toxic positivity". https://en.wikipedia.org/wiki/Toxic_positivity In my experience, secretive practices in coaching and discipline are inimical to productive software development, both in professional and volunteer contexts. One of the most fundamental problems is that secretive practices make it hard to distinguish coaching _from_ disciplinary action. For decades, employees have understood that being summoned into a closed-door meeting with a manager is bad news for them more often than not, because the delivery of good news tends to be publicly announced or even celebrated. An ashen-faced team member shuffling into or out of the boss's office is useful to get scary rumors circulating and to intimidate all of the subordinate members in the organization--nobody wants to be "that guy".[10] In contrast, I have zero power over Martin except that of my words' persuasive ability, and that's exactly how I like it. > If you wanted to tell something to Martin in good faith, you should > have sent a private message to Martin (even if you somehow believe > Martin won't listen). "Good faith" is a phrase that is heavily abused. Sadly for me I've many times seen it asserted with the surplus freight of unrebuttability and unfalsifiability. You can keep using the term, of course, but it's not likely to convince me of anything--and I recommend skepticism to others. As an exercise, you might review the exhibits of Martin's style of expression in my earlier message[3] and evaluate how well they withstand the presumption of good faith interpretation. > By broadcasting this entire discussion, your purpose appears to be > showing off your supiriority to Martin to hundreds of people in the > bug-bash mailing list, rather than telling Martin an advice. No, just the latter. If Martin dials down the hyperbole I look forward to interacting with him cheerfully on topics to which I can contribute. With respect to attempted displays of superiority, I think of the words of Eugene V. Debs when he was being sentenced for sedition in 1918. Your Honor, years ago I recognized my kinship with all living beings, and I made up my mind that I was not one bit better than the meanest on earth. I said then, and I say now, that while there is a lower class, I am in it, and while there is a criminal element, I am of it, and while there is a soul in prison, I am not free. Grandiose stuff for a technical mailing list, but good to keep in the back of one's mind, especially when the turtlenecks come around proffering stock options, hawking cryptocurrency, and flattering individual contributors as elite members of a "family"--who nevertheless can be terminated without cause if the "operating expense" slice of the pie chart has grown "fat" and the next 10-Q filing looks dicey. > After all, an adult wouldn't create a topic named "On <someone's > name>" in a technical mailing list. That selection was to (a) flag the message as likely uninteresting to people like yourself with a narrow interpretation of the mailing list charter, and (b) make an attempt at a humorous allusion to the titling practices of the works of Aristotle. (It also achieved a pleasing symmetry with the title of one of the works I cited.) > I also feel there is some room to improve the way Martin argues if he > wishes, but I think it is a part of Martin's character. I don't question your right to disregard it as a personal eccentricity. > I don't think it is a big problem, though as Chet mentioned, I think > Martin is undermining his arguments with his behavior to some extent. I somewhat disagree--it's not the _arguments_ that are thereby undermined; as I tried to point out, the arguments themselves stand or fall regardless of the quality of rhetorical surplus around them. What a person might undermine is readers' _patience_ with their arguments. (We can take it as read that one might also lose patience with mine, starting with the length at which I write.) > > ... Or demonstrably false, even. Koichi Murase and Grisha Levit, > > for example, have repeatedly and recently made reports that Chet > > welcomed and contributed patches that he incorporated. You > > might consider closely emulating their approach and see if your > > reception improves. > > Grisha and I mostly raise trivial fixes (segfaults, memleaks, clear > bugs, small improvements in the behavior, etc.), I disagree with your characterization of fixes for segfaults and memory leaks (at least ones that grow without bound over the lifetime of a process). I think the work you and Grisha do is valuable, not "trivial". Is it widely scoped or revolutionary? No. Does it have to be, to be worthwhile? The Unix shell language is a difficult beast because it is the product of many different hands implementing many different ad hoc notions of design, and yet so deeply entrenched that revolutionary reform is, I _expect_, infeasible. Its manifestation is furthermore complex, even for those who have worked on language interpreters. Under these circumstances many programmers, especially those desirous of making a big splash in the community, would despair of contributing, and neglect the shell to stumble along with whatever defects it has. So as a Bash user I must express my appreciation for your and Grisha's efforts--along with Chet's, of course!--in sanding down the shell's rougher spots. > and they are essentially different from a typical discussion (related > to the development and the language design) raised by Martin, which is > expected to cause conflicts among different people having different > pictures about Bash, etc. I don't see as much daylight between these two classes of revision as you seem to. Developers can and do argue over any detail of implementation, from indentation to memory management strategies to whether the function `sprintf()` should be used. (Apple says "no".[9]) I applaud your generous attitude toward Martin's sometimes ambitious notions of reform, but I don't think the measure of an ambition's height proportionally licenses hyperbole or other forms of inflated rhetoric in its pursuit. I concede that it's a popular view; many Silicon Valley startups launched on that basis. Most of them failed, but culturally we're coached to lionize their principals anyway, due I think to a Nietzschean principle of capitalist society: "The errors of great men are more valuable than the truths of lesser men." (There's no limit to the upside of passing oneself off as a great man.) I think that's a bad principle. A fact is a fact and a falsehood a falsehood, be the utterer a great person or small. We should be especially wary of the falsehoods proclaimed by those thought great. How do we cultivate this skill? With practice--by holding each other to account when the stakes are low and nobody's so invested that they can't move forward amiably after the conflict. I look forward to hearing how I'm wrong. :) Regards, Branden [0] Message-ID: <3d8515e0-7e6b-422f-9344-65e8074da...@case.edu> https://savannah.gnu.org/bugs/?67486 [1] https://lists.gnu.org/archive/html/bug-bash/2025-09/msg00098.html [2] Here's an example. https://kansasreflector.com/2025/09/04/outraged-parents-demand-action-as-kansas-school-board-places-superintendent-on-administrative-leave/ [3] https://lists.gnu.org/archive/html/bug-bash/2025-09/msg00101.html [4] Consider the highest and severest form of social rebuke in human society: the death penalty. Reflect on the fact that the "disappearances" practiced most notoriously by Latin American dictatorships are widely regarded as (even) more abhorrent than public trials of capital defendants. Fortunately for us, we're just trying to develop software here. [5] https://publish.obsidian.md/dolores/5+-+Publish/Garden/Wilhoit%E2%80%99s+Law [6] For example, Thomas Dickey normally updates ncurses weekly on Saturdays, but sends a notice to the bug-ncurses@gnu mailing list if he expects to miss a week for whatever reason. [7] For example, there is the case of Python developer Tim Peters's unfortunate experience with the Python Foundation's Steering Committee. https://lwn.net/Articles/1002340/ Once closed-door executive sessions by elite leaders become normalized and accepted in one aspect of project management, those who have or seek powerful positions become enamored of them and replicate them for other functions, leading to fiascoes like RustConf's now-you-see-it, now-you-don't invitation to JeanHeyd Meneide to keynote an annual conference. https://www.sophiajt.com/why-i-left-rust/ [8] Why and how we can apply the term "conservatism" to this practice would carry the discussion too far afield even for me. To the curious I commend the works of Bob Altemeyer (_The Authoritarians_) and Corey Robin (_The Reactionary Mind_). For those of scholarly bent, these works can offer insight into how and why, as The Who put it, beards tend to grow longer overnight. [9] https://developer.apple.com/documentation/kernel/1441083-sprintf [10] https://www.imdb.com/title/tt1484414/
signature.asc
Description: PGP signature
