On Wed, 14 Apr 2021, Eric S. Raymond wrote: > I'm not judging RMS's behavior (or anyone else's) one way or > another. I am simply pointing out that there is a Schelling point in > possible community norms that is well expressed as "you shall judge by > the code alone". This list is not full of contention from affirming > that norm, but from some peoples' attempt to repudiate it.
Since RMS, FSF and GNU are not contributing code to the toolchain and haven't been for a very long time, the most similar basis to judge them would seem to be based on their interactions with toolchain development. I think those interactions generally show that FSF and GNU have been bad umbrella organizations for the toolchain since at least when the GCC 4.4 release was delayed waiting for a slow process of developing the GCC Runtime Library Exception. Things have gone most smoothly when no actions or decisions from FSF or GNU have been required and when RMS has not attempted to make any decisions related to the toolchain. When RMS has attempted to make any decisions, or suggest features, etc., that's generally served to waste a lot of time explaining to him why his ideas are irrelevant or based on a fundamental lack of understanding of the issues involved. Even when he's made suggestions that are reasonable, he's still wasted a lot of people's time arguing about points that should not be controversial. (By way of example, on 20 Sep 2017 he suggested to the SC that GCC should support direct use of non-ASCII characters in identifiers. I replied pointing him to the guidance I'd given in bug 67224 comments 11, 19 and 21. So far, that's reasonable, but he then entered into prolonged discussion of the details of what particular patches did or didn't do, exactly what characters should or should not be allowed in identifiers, how GNU relates to standards, to what extent we need to design a feature properly before including it in GCC, and so on. None of his comments there were at all useful, since he's far too far removed from current GCC development to comment usefully on such matters, and any useful comments in that area would have been better somewhere public anyway. And in due course we did get a new GCC contributor who successfully implemented the feature in GCC following the guidance I'd given, despite RMS's notions that that would be too hard.) In things where the FSF and GNU have been supposed to be acting as umbrella organizations, that has generally been done badly (e.g. there have been problems with long delays in processing copyright assignments many times over the years; they never managed to come up with a simple GPL/GFDL dual-licensing notice so requiring instead the cumbersome system of having both GPL and GFDL copies of certain text in target.def and tm.texi). For fairness, I should note the *unique case I know of in the past decade* where RMS was involved in a positive toolchain contribution. On 11 Nov 2011 he started a discussion with me regarding the problems with glibc maintenance, and that ultimately started the transition to more community-oriented glibc development. But ultimately the key parts of that transition were not the parts that actually involved RMS - it was discussions with Roland McGrath, not with RMS, that were key to achieving the transition successfully. New GNU maintainers of glibc, as recommended by me, were added on RMS's direction (maintainers revision 1.1352 on fencepost, 10 Feb 2012). But the actual problems before then with glibc development weren't with the GNU maintainers (steering committee), beyond that they didn't do anything much to address the dysfunction in glibc development - it wasn't the GNU maintainers who were pushing away contributions. And it was the deliberate work on building a community, getting people contributing, getting contributions committed (bootstrapping off Roland's authority to approve changes regardless of whether the then lead developer cared for them) that was actually the key part. The announcements relating to changes <https://sourceware.org/pipermail/libc-alpha/2012-March/028224.html> <https://sourceware.org/pipermail/libc-alpha/2012-March/028226.html> were primarily concerned with a situation that already existed at that time, and that had been achieved by following a process that Roland had convinced me would be the right way to achieve changes, not with announcing anything done on the authority of RMS (which had happened over a month earlier without any public announcement). So in that case, while RMS started the discussion (or at least the part of the discussion I saw, I don't know what might have happened before 11 Nov 2011 involving other people), the useful changes could have been achieved by following the same plan with Roland but without RMS involved at all, whereas if only RMS's part had happened and there had been an attempt to change things only on the authority of RMS without actively building the community first, it would have been much less likely to succeed. No GNU authority was ever needed to achieve the changes and the exercise of GNU authority that happened through appointing new maintainers was only legitimate because it was part of recognizing community changes that were in the process of occurring. -- Joseph S. Myers jos...@codesourcery.com
