Who controls glibc?
Toward the end of April, Raymond Nicholson posted a patch to the glibc manual removing a joke
that he didn't think was useful to readers. The joke played on the documentation
for abort() to make a statement about US government policy on
providing information about abortions. As Nicholson noted: "The joke
does not provide any useful information about the abort() function so
removing it will not hinder use of glibc
". On April 30, Zack
Weinberg applied the patch to the glibc
repository.
Richard Stallman, who added the joke sometime in the 1990s, asked that it not be removed. The resulting
discussion touched on a number of issues. Carlos O'Donell, who has been
trying hard to resolve the issue with some degree of consensus, suggested that the joke could hurt people who
have had bad experiences associated with abortion. He proposed a
couple of possible alternatives, including avoiding jokes entirely or
discussing such issues in a different forum. Stallman, however, replied that "a GNU manual, like a
course in history, is not meant to be a 'safe space'
". He suggested
the possibility of adding a trigger warning about functions that create
child processes, since childbirth is "far more traumatic than having an
abortion
".
Whether the joke belongs in the glibc manual is an issue for the glibc
developers to decide and wouldn't normally be of much interest beyond the
project itself. But in this case, it raises the question of how the
developers make this decision. The project's wiki
states that the project "uses a consensus-based community-driven
development model
". In this case, there seems to be a fairly clear
consensus among the actual glibc developers that this joke is not
appropriate in the project's manual. Weinberg's application of the patch
was based on this consensus.
Stallman, however, has made it clear that there are limits to the extent to
which glibc is consensus-based; his response was: "My decision is to keep
the joke
". Weinberg stated his
refusal to revert the change; Stallman answered: "I stand by my decision to
keep the joke
". O'Donell apologized
for not contacting Stallman directly about the removal, but also stood by
the decision to remove it. He asked:
Weinberg defended his application of the patch:
Stallman was unimpressed, though, and fell back to a pure authority play,
saying: "As the head of the GNU
Project, I am in charge of what we publish in GNU manuals. I decide the
criteria to decide by, too
". He later added:
O'Donell repeated that a discussion was underway and that the maintainers did not intend to revert the patch. He also asked whether the change violated any GNU policies — a question that went unanswered as of this writing. He also stated clearly that the joke would not return in any form until some sort of consensus was reached.
One could argue that the consensus is already there if one looks at the developers who actually work on glibc; it is difficult to find any of them arguing for the joke's return. The number of people arguing for the joke in general is quite small. That did not stop Alexandre Oliva, who evidently has a high opinion of Stallman's sense of humor, from reverting the change early on May 7 — his first glibc change in 2018. He did not post his change to the mailing list (and only explained it after being asked); his attempt to justify it as a return to consensus did not fly with O'Donell. This discussion, one suspects, is not done.
Each project has its own governance model. The "authoritarian leader"
model is quite common in this space, with many projects subject to the will
of a (hopefully benevolent) dictator who can decide to accept or reject any
change. Sometimes that model works better than others; glibc itself
improved its processes and inclusiveness considerably when its single
leader was replaced by a more consensus-oriented model. Usually, though,
such leaders are at least active developers in the projects they manage;
that is not the case for the GNU projects. It can be discouraging for a
developer to discover that their changes are subject to a veto from on
high by somebody who is not otherwise involved with the project's
development. The echoes of this action may thus persist in the glibc
community
for some time.
