On Sun, 28 Mar 2021, Mark Wielaard wrote: > He does indeed show up randomly claiming authority even if the GNU > community has told him no. And it is important to say upfront he has > no authority and that his attempts to cancel the work of hardworking > GNU contributors is unwelcome. IMHO for the GCC community this means > to be explicit he doesn't have any authority and he shouldn't be on > the GCC steering committee.
For example, consider the October 2019 discussion on libc-alpha of removing the abort "joke" from the glibc manual. We rejected RMS's claims of authority to say that the joke should be kept, or kept indefinitely until various general points could be decided, and removed it from the manual anyway without waiting for conclusions on all those general points. RMS only has authority over decisions taken about individual GNU packages where the people developing those packages let him have that authority and make or refrain from making changes based on what he says. We should not give him such authority by treating his views as having some significance not given to such views expressed by other people; changes he suggests can be considered, and accepted or rejected, on their merits. And the abort joke case illustrates that in fact he is not given such authority, when package developers are confident to stand up to claims he makes of authority, and provides an example that can speed up the rejection of any such assertion of authority to micromanage things that might be made in future. I agree with the conclusion of Nathan's original message, that RMS behaves in a toxic way, it is harmful to have him listed as being in a leadership role that might suggest what he does is acceptable within the project, and he should not be on the SC. This is based on the longstanding, well-documented patterns of how he has misbehaved towards women, *not* on the opinions he has expressed on other subjects, *not* on his choices regarding the use of language, *not* on his attempts to insist on language being used in particular ways, and *not* on where or when he has chosen to express such views. For the same reasons, I think it is harmful for him to be Chief GNUisance (but as above, I think GNU packages should not give a Chief GNUisance authority to micromanage decisions, beyond ensuring GNU packages follow basic GNU free software principles and cooperate with each other and with their development communities), harmful for him to be on the FSF board, and harmful for him to be seen as leader of the free software movement. (For the last point, I don't think the free software movement needs a single leader; it needs many people advocating free software, and discussing issues related to free software, from diverse perspectives. RMS's ideas that form the foundation of the free software movement are still of fundamental importance today. But other people can now build better on those ideas in today's context.) RMS does not, in fact, contribute usefully to the SC. Any time he suggests some feature for GCC, whether a good or a bad idea, that could be done just as well on the public mailing list (which would be a better place to find someone possibly interested in implementing a feature, and to discuss a feature's merits, in any case) without being an SC member. He's sufficiently far removed from toolchain development that he's not good at making reasonable suggestions for toolchain changes in any case. We can consider individual proposals or patches from anyone on their merits. We can have leaders who are accepted as leaders because contributors can see their relevant expertise that gives them legitimacy as leaders, and can see a good basis for decisions they make as leaders. But longstanding patterns of bad conduct by a leader, even when formally unrelated to the project, can reach the point where considering that person a leader is harmful to the project. I think the ways RMS has behaved have long since reached the point where it is harmful for him to be considered a leader for GCC or GNU, and that's sufficient to stop considering him a leader (even if he were sufficiently involved to be able to contribute much more usefully on a technical level). -- Joseph S. Myers jos...@codesourcery.com
