5 ms·

The discussion is a proxy for how executive decisions are made for glibc, and in particular by whom. The merit of a stale joke from the 90s is meaningless, and

The discussion is a proxy for how executive decisions are made for glibc, and in particular by whom. The merit of a stale joke from the 90s is meaningless, and posturing about its appropriateness is disingenuous. Open source principals have always been eccentric (Torvalds, Raymond(!), etc.), and the FOSS community tolerated it not only because of their technical contributions, but because the open source community itself is an expression of tolerance based on shared objectives. Of course others would like to wield their influence in the generation of the DNA of the internet, and there is a tremendous amount to be gained by scandalizing, discrediting, and isolating its core maintainers. Perhaps eventually RMS will come around and remove the joke himself, after finding it does not stand the test of time. But it would go a long way to resolving this if they could demonstrate they aren't just using the joke as a pretext for scandal to undermine the decision making structure of a project. It's clearly not about the joke.

geofft 9y ago
This seems to ascribe a high amount of ill will to glibc maintainers who have been faithful and productive GNU maintainers for many years, and I don't believe there's any other evidence that they wish to undermine RMS' authority. However, if those maintainers find that their faithfulness is rewarded by being told that they don't actually maintain the project, they're just tending it while RMS is busy, it seems entirely reasonable to me that they would become upset at RMS trying to undermine the decision-making structure of glibc. The principals here, the people making the technical contributions, are the glibc maintainers.
- motohagiography 9y ago
  Except that perhaps RMS's approval and veto are no longer legitimate? It's not ascribing ill will at all. They've stumbled on a canary or a "brown M&M," where regardless of how good they think they are, they've transgressed a boundary of the implicit agreement of who has final say. They would have to be good and faithful to have contributions approved to glibc, so I would argue that's not the point. As the principals age, the question of succession and governance in key open source projects will become more explicit. Seems they walked into this one.
  - geofft 9y ago
    Yeah, I think they stumbled into this, and having realized where they were, decided that having a proxy fight about RMS' authority in general is something they were needing to do at some point. I just don't think they set out to end up here because they were looking for the fight, and I read your comment as accusing the glibc maintainers of being non-core maintainers who were looking for a way to cause a scandal. If I misread it, I apologize.
    - motohagiography 9y ago
      I could have been more clear and less punchy. It's a sensitive topic and perhaps my pen leapt from its scabbard a bit. :)
  - jlebar 9y ago
    > It's not ascribing ill will at all. They've stumbled on a canary or a "brown M&M," where regardless of how good they think they are, they've transgressed a boundary of the implicit agreement of who has final say. I dunno, is it fair to call it an "agreement" if one side doesn't think they agreed to it? zwol says: > I don't think I did anything wrong procedurally. RMS may be the project leader, but he is not a glibc maintainer. His wishes regarding glibc are perhaps to be given _some_ more weight than those of any other individual, particularly when he is also the author of text under dispute, but we have never, to my knowledge, treated them as mandates. Seems pretty clear he isn't party to this agreement, implicit or otherwise.
- Pyxl101 9y ago
  > However, if those maintainers find that their faithfulness is rewarded by being told that they don't actually maintain the project, they're just tending it while RMS is busy Someone or some group/process has to be in charge, be the final decision-maker for a group. In the case of the GNU Project, the Free Software Foundation is likely that decision-maker as the owner of the trademark for "GNU". The FSF as a non-profit organization has articles of incorporation and bylaws [1] describing its process for making decisions - but it is a corporation, just like any corporation, and its decisions concerning its assets are binding in the same way as if Google made a decision about one of its products. I haven't read the FSF bylaws in detail, but it sounds like RMS believes that he has decision-making authority over the FSF and GNU Project, which he probably does. Someone has to - what's the alternative? In organizations like the FSF and Wikipedia, someone or some process has to have the authority to make decisions. There is no way to delegate actual decision-making to the "community" at large. A person has to have it, either individually or as the executor of a process. I suppose the alternative is having no trademark nor legal organization in charge of a project, but in that case, a disagreement could result in two different projects contending for the same name. Besides, someone or some organization ultimately has to be in control of properties such as domain names and source control accounts. The moment that a project manages any properties like this, there has to be a formal decision-making process or the project is at risk of chaos. The person who has legal control over project properties like the project domain name, or IP like its trademark, is in de facto final control over the project itself. There are undoubtedly options for going over RMS's head, such as convincing the directors of the FSF [2] to take a vote on the issue, or take a vote to remove him as president or as a director. Alternatively, people who feel passionately about this issue could lobby the FSF directors to put pressure on RMS to reverse this decision or delegate it, without using the mechanics of a formal vote, such as by threatening resignation. Furthermore, donors of the FSF could threaten to pull their funding over the issue. Alternatively, project maintainers can fork the codebase and carry on under a new name, managed by a new organization, which is their right to do since the code is open source and free software. To the extent that an open source project or any project is operating under a specific name, managed by a corporation, we should all understand that someone is always "in charge", though that person or group may act with a light touch or operate largely behind the scenes. [1] https://www.fsf.org/about/financial https://www.fsf.org/about/financial [2] https://www.fsf.org/about/people/board https://www.fsf.org/about/people/board P.S. This comment is not an endorsement of either side of the issue in a normative sense. It is intended to be a positive comment concerning the expectations we should have in working with corporations.
djsumdog 9y ago
I just finished reading The Dictators Handbook and it's crazy how these same principals seem to apply to OSS organizations. This is more about politics than anything else, and hopefully everyone involved will learn it shouldn't be.
jancsika 9y ago
> Open source principals have always been eccentric (Torvalds, Raymond(!), etc.), and the FOSS community tolerated it not only because of their technical contributions, but because the open source community itself is an expression of tolerance based on shared objectives. I think you're confusing two separate issues. Torvalds' acidic method of communication is certainly eccentric. But from my casual reading of LKML what he communicates is not. Like: * some patch is prone to bugginess and not suitable to merge * some patch shows that the submitter doesn't understand some fundamental aspect of C and thus isn't suitable to merge as written * some patchset looks similar to some previous subsystem that caused massive problems and should therefore be avoided * the patch was measured to break things or perform poorly * the patch is shoehorning in a feature that doesn't belong in the kernel * some non-technical proposal would cause future problems for Kernel devs and should be avoided In the case of Stallman's joke, we can certainly say his method of communication-- popping in to make a surprise decision by fiat-- is eccentric. But we can also say the content of what he is communicating is also eccentric. What possible rationale could there be to tying up volunteer glibc maintainers' time for a bike-shedding session about a decades-old joke? It's the difference between someone with a Penguin fetish favoring Penguin-based metaphors, and someone with a Gnu fetish forcing you to sit through 125 "funny" videos of Gnus. Scratch that-- there are 10 more "Abortion Joke" messages from April. So make that 126 "funny" videos about Gnus.
djur 9y ago
Regarding standing the test of time, one of Donald Trump's first acts in office was to reinstate and expand the global gag rule: https://www.apnews.com/868c8211b4f948d8b7f7ce58ab08a78b https://www.apnews.com/868c8211b4f948d8b7f7ce58ab08a78b That isn't a comment on whether the joke should be removed or retained, but it's worth noting that this "stale joke from the '90s" is actually very relevant to contemporary politics.
tomtimtall 9y ago
Should they also faithfully maintain the pretense of every damn pointer he initiated? Their the ones doing the work of maintaining the project, removing no-value jokes in the documentation should not warrant this amount of weight throwing nomatter who put them there.

geofft 9y ago

This seems to ascribe a high amount of ill will to glibc maintainers who have been faithful and productive GNU maintainers for many years, and I don't believe there's any other evidence that they wish to undermine RMS' authority. However, if those maintainers find that their faithfulness is rewarded by being told that they don't actually maintain the project, they're just tending it while RMS is busy, it seems entirely reasonable to me that they would become upset at RMS trying to undermine the decision-making structure of glibc. The principals here, the people making the technical contributions, are the glibc maintainers.

motohagiography 9y ago
Except that perhaps RMS's approval and veto are no longer legitimate? It's not ascribing ill will at all. They've stumbled on a canary or a "brown M&M," where regardless of how good they think they are, they've transgressed a boundary of the implicit agreement of who has final say. They would have to be good and faithful to have contributions approved to glibc, so I would argue that's not the point. As the principals age, the question of succession and governance in key open source projects will become more explicit. Seems they walked into this one.
- geofft 9y ago
  Yeah, I think they stumbled into this, and having realized where they were, decided that having a proxy fight about RMS' authority in general is something they were needing to do at some point. I just don't think they set out to end up here because they were looking for the fight, and I read your comment as accusing the glibc maintainers of being non-core maintainers who were looking for a way to cause a scandal. If I misread it, I apologize.
  - motohagiography 9y ago
    I could have been more clear and less punchy. It's a sensitive topic and perhaps my pen leapt from its scabbard a bit. :)
- jlebar 9y ago
  > It's not ascribing ill will at all. They've stumbled on a canary or a "brown M&M," where regardless of how good they think they are, they've transgressed a boundary of the implicit agreement of who has final say. I dunno, is it fair to call it an "agreement" if one side doesn't think they agreed to it? zwol says: > I don't think I did anything wrong procedurally. RMS may be the project leader, but he is not a glibc maintainer. His wishes regarding glibc are perhaps to be given _some_ more weight than those of any other individual, particularly when he is also the author of text under dispute, but we have never, to my knowledge, treated them as mandates. Seems pretty clear he isn't party to this agreement, implicit or otherwise.
Pyxl101 9y ago
> However, if those maintainers find that their faithfulness is rewarded by being told that they don't actually maintain the project, they're just tending it while RMS is busy Someone or some group/process has to be in charge, be the final decision-maker for a group. In the case of the GNU Project, the Free Software Foundation is likely that decision-maker as the owner of the trademark for "GNU". The FSF as a non-profit organization has articles of incorporation and bylaws [1] describing its process for making decisions - but it is a corporation, just like any corporation, and its decisions concerning its assets are binding in the same way as if Google made a decision about one of its products. I haven't read the FSF bylaws in detail, but it sounds like RMS believes that he has decision-making authority over the FSF and GNU Project, which he probably does. Someone has to - what's the alternative? In organizations like the FSF and Wikipedia, someone or some process has to have the authority to make decisions. There is no way to delegate actual decision-making to the "community" at large. A person has to have it, either individually or as the executor of a process. I suppose the alternative is having no trademark nor legal organization in charge of a project, but in that case, a disagreement could result in two different projects contending for the same name. Besides, someone or some organization ultimately has to be in control of properties such as domain names and source control accounts. The moment that a project manages any properties like this, there has to be a formal decision-making process or the project is at risk of chaos. The person who has legal control over project properties like the project domain name, or IP like its trademark, is in de facto final control over the project itself. There are undoubtedly options for going over RMS's head, such as convincing the directors of the FSF [2] to take a vote on the issue, or take a vote to remove him as president or as a director. Alternatively, people who feel passionately about this issue could lobby the FSF directors to put pressure on RMS to reverse this decision or delegate it, without using the mechanics of a formal vote, such as by threatening resignation. Furthermore, donors of the FSF could threaten to pull their funding over the issue. Alternatively, project maintainers can fork the codebase and carry on under a new name, managed by a new organization, which is their right to do since the code is open source and free software. To the extent that an open source project or any project is operating under a specific name, managed by a corporation, we should all understand that someone is always "in charge", though that person or group may act with a light touch or operate largely behind the scenes. [1] https://www.fsf.org/about/financial https://www.fsf.org/about/financial [2] https://www.fsf.org/about/people/board https://www.fsf.org/about/people/board P.S. This comment is not an endorsement of either side of the issue in a normative sense. It is intended to be a positive comment concerning the expectations we should have in working with corporations.

djsumdog 9y ago

I just finished reading The Dictators Handbook and it's crazy how these same principals seem to apply to OSS organizations. This is more about politics than anything else, and hopefully everyone involved will learn it shouldn't be.

jancsika 9y ago

> Open source principals have always been eccentric (Torvalds, Raymond(!), etc.), and the FOSS community tolerated it not only because of their technical contributions, but because the open source community itself is an expression of tolerance based on shared objectives. I think you're confusing two separate issues. Torvalds' acidic method of communication is certainly eccentric. But from my casual reading of LKML what he communicates is not. Like: * some patch is prone to bugginess and not suitable to merge * some patch shows that the submitter doesn't understand some fundamental aspect of C and thus isn't suitable to merge as written * some patchset looks similar to some previous subsystem that caused massive problems and should therefore be avoided * the patch was measured to break things or perform poorly * the patch is shoehorning in a feature that doesn't belong in the kernel * some non-technical proposal would cause future problems for Kernel devs and should be avoided In the case of Stallman's joke, we can certainly say his method of communication-- popping in to make a surprise decision by fiat-- is eccentric. But we can also say the content of what he is communicating is also eccentric. What possible rationale could there be to tying up volunteer glibc maintainers' time for a bike-shedding session about a decades-old joke? It's the difference between someone with a Penguin fetish favoring Penguin-based metaphors, and someone with a Gnu fetish forcing you to sit through 125 "funny" videos of Gnus. Scratch that-- there are 10 more "Abortion Joke" messages from April. So make that 126 "funny" videos about Gnus.

djur 9y ago

Regarding standing the test of time, one of Donald Trump's first acts in office was to reinstate and expand the global gag rule: https://www.apnews.com/868c8211b4f948d8b7f7ce58ab08a78b https://www.apnews.com/868c8211b4f948d8b7f7ce58ab08a78b That isn't a comment on whether the joke should be removed or retained, but it's worth noting that this "stale joke from the '90s" is actually very relevant to contemporary politics.

tomtimtall 9y ago

Should they also faithfully maintain the pretense of every damn pointer he initiated? Their the ones doing the work of maintaining the project, removing no-value jokes in the documentation should not warrant this amount of weight throwing nomatter who put them there.