Oh, this is one of my favorite (and sad!) dramas in free software.
Five years later the main llvm developer proposed [0] to integrate it into gcc.
Unfortunately, this critical message was missed by a mail mishap on Stallman's part; and he publicly regretted both his errors (missing the message and not accepting the offer), ten years later [1].
The drama was discussed in realtime here in HN [2].
It also speaks to an absolute failure of governance. If I missed an important email on a FreeBSD mailing list, you can bet that a dozen other people would see it and either poke me about it or just go ahead and act upon it themselves.
The fact that RMS missed an email and nobody else did anything about it either is a sign of an absolutely dysfunctional relationship between the project and its leadership.
So, having been around a lot of different communication methods, I think email lists aren’t ideal, but for serious projects they’re better than all the alternatives.
Chat has a way of getting completely lost. All your knowledge that goes into chat either goes into somebody’s head or it just disappears into the ether. This includes Slack, Discord, Teams, etc. Useful as a secondary channel but serious projects need something more permanent.
Bug tracking systems just don’t support the kind of conversations you want to have about things. They’re focused on bugs and features. Searchability is excellent, but there are a lot of conversations which just end up not happening at all. Things like questions.
That brings us back to mailing lists. IMO… the way you fix it is by having redundancies on both sides of the list. People sending messages to the mailing list should send followup messages. You should also have multiple people reading the list, so if one person misses a message, maybe another gets it.
Mailing lists are not perfect, just better than the alternatives, for serious projects.
Piling on about chat. Slack threads are an abomination. They aren’t inline with the main channel so you can’t cut and paste an entire conversation with threads. And does exporting a channel include threads? Who knows because the admin wouldn’t do it for me.
Still, we are discussing it almost 30 years after it happened. What alternative messaging system offers such openness and stability? I don't see anything other than publicly archived mailing lists.
Sorry...maybe I'm dense. Email has worked for decades. If I don't catch something this relevant in an email forum, why would I automatically, without question, see it and understand its relevance in chat, Slack, etc.
Serious question, since in my experience even specifically assigning someone a Jira tix doesn't guarantee they'll actually look at it and act.
There is no communication method where this isn't possible. Email can be missed, chat can be missed, phone calls can be missed, even talking to someone in person can be missed. All forms of communication can fail such that the person sending the message thinks it was received when it wasn't. So one would need evidence that email is more likely to fail in this respect, rather than evidence it can happen at all, to show that email is a worse communication method.
And the result is that most new open source languages (and commercial companies) use LLVM instead of GCC as the backend => way more engineering resources are dedicated to LLVM.
For what it's worth, the leverage did work, just not forever. It was a play with a limited lifetime. It didn't necessarily need to shake out that way, probably if GCC was slightly easier to write for but not too easy people would have invested more. It took a major investment to create a competing product.
you only need to worry about GPLv3 if you are modifying gcc in source and building it and distributing that. Just running gcc does not create a GPLv3 infection. And glibc et al are library licensed so they don't infect what you build either, most especially if you are not modifying its source and rebuilding it.
Stallman's version of free is free to the end user. He cares more about whether the end user will have access to the source code and means to modify their software to remove any anti-feature, and less about whatever freedoms the developers of said software would want (such as, the freedom to close the source and distribute only binaries)
Ultimately Stallman was against a kind of digital feudalism, where whoever developed software had power over those that didn't
To which none can answer how it creates freedom without mass adoption to actually get the software into end users' hands. The great contradiction in FSF philosophy is to create highly pure software within a monastery of programmer-users while simultaneously insisting to focus on end-user freedoms without reconciling programmer incentives to build what these end users need.
Not that strange, as GCC was an effort to a goal of developing an ecosystem of Free (as in speech) software. While FSF had sometimes made allowances for supporting non-Free software (whether non-copyleft open source or proprietary), these were always tactics in support of the longer-term strategy. Much like you might spend marketing funds on customer acquisition in the service of later recurring revenue.
As RMS indicated, this strategy had already resulted in the development of C++ front ends for the Free software ecosystem, that would otherwise likely not have come about.
At that time the boom in MIT/BSD-licensed open source software predominantly driving Web apps and SaaS in languages like Rust and Javascript was still far away. GCC therefore had very high leverage if you didn't want to be beholden to the Microsoft ecosystem (it's no accident Apple still ships compat drivers for gcc even today) and still ship something with high performance, so why give up that leverage towards your strategic goal for no reason?
The Linux developers were more forward-leaning on allowing plugins despite the license risks but even with a great deal of effort they kept running into issues with proprietary software 'abusing' the module APIs and causing them to respond with additional restrictions piled atop that API. So it's not as if it were a completely unreasonable fear on RMS's part.
Oh, this is one of my favorite (and sad!) dramas in free software.
Five years later the main llvm developer proposed [0] to integrate it into gcc.
Unfortunately, this critical message was missed by a mail mishap on Stallman's part; and he publicly regretted both his errors (missing the message and not accepting the offer), ten years later [1].
The drama was discussed in realtime here in HN [2].
[0] https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
[1] https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
[2] https://news.ycombinator.com/item?id=9028738
I feel like this is a sort of evidence that even for the most serious of engineers email lists are not an ideal way to communicate.
It also speaks to an absolute failure of governance. If I missed an important email on a FreeBSD mailing list, you can bet that a dozen other people would see it and either poke me about it or just go ahead and act upon it themselves.
The fact that RMS missed an email and nobody else did anything about it either is a sign of an absolutely dysfunctional relationship between the project and its leadership.
So, having been around a lot of different communication methods, I think email lists aren’t ideal, but for serious projects they’re better than all the alternatives.
Chat has a way of getting completely lost. All your knowledge that goes into chat either goes into somebody’s head or it just disappears into the ether. This includes Slack, Discord, Teams, etc. Useful as a secondary channel but serious projects need something more permanent.
Bug tracking systems just don’t support the kind of conversations you want to have about things. They’re focused on bugs and features. Searchability is excellent, but there are a lot of conversations which just end up not happening at all. Things like questions.
That brings us back to mailing lists. IMO… the way you fix it is by having redundancies on both sides of the list. People sending messages to the mailing list should send followup messages. You should also have multiple people reading the list, so if one person misses a message, maybe another gets it.
Mailing lists are not perfect, just better than the alternatives, for serious projects.
(I also think forums are good.)
This is why the D community has forums. The messages are all archived as static web pages and are a gold mine of information.
https://www.digitalmars.com/d/archives/digitalmars/D/
BTW, like HackerNews, the D forums don't allow emojis, icons, javascript, multiple fonts, and all that nonsense. Just text. What a relief!
Piling on about chat. Slack threads are an abomination. They aren’t inline with the main channel so you can’t cut and paste an entire conversation with threads. And does exporting a channel include threads? Who knows because the admin wouldn’t do it for me.
praise https://github.com/rusq/slackdump
it does include threads, and no need for admins
Discourse (or other forums) would be my pick and what I’ve driven other projects I’m involved with to success.
They can be treated like mailing lists, but are easy to navigate , easy to search and index, and easy to categorize.
Still, we are discussing it almost 30 years after it happened. What alternative messaging system offers such openness and stability? I don't see anything other than publicly archived mailing lists.
Sorry...maybe I'm dense. Email has worked for decades. If I don't catch something this relevant in an email forum, why would I automatically, without question, see it and understand its relevance in chat, Slack, etc.
Serious question, since in my experience even specifically assigning someone a Jira tix doesn't guarantee they'll actually look at it and act.
There is no communication method where this isn't possible. Email can be missed, chat can be missed, phone calls can be missed, even talking to someone in person can be missed. All forms of communication can fail such that the person sending the message thinks it was received when it wasn't. So one would need evidence that email is more likely to fail in this respect, rather than evidence it can happen at all, to show that email is a worse communication method.
You can go yell in the others people ear
Somebody back in 2015 mentioned a relevant response to Richard Stallman from David Kastrup[1]. It's brilliant.
Did he convince other GCC devs with that post? Mentor younger devs on free software strategy?
What's happened in the ten years since?
C'mon GCC mailing list lurkers-- spill the tea! :)
1: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
And the result is that most new open source languages (and commercial companies) use LLVM instead of GCC as the backend => way more engineering resources are dedicated to LLVM.
For what it's worth, the leverage did work, just not forever. It was a play with a limited lifetime. It didn't necessarily need to shake out that way, probably if GCC was slightly easier to write for but not too easy people would have invested more. It took a major investment to create a competing product.
I thought GPLv3 adoption by GCC was what really lit the flames on moving to llvm by commercial entities?
you only need to worry about GPLv3 if you are modifying gcc in source and building it and distributing that. Just running gcc does not create a GPLv3 infection. And glibc et al are library licensed so they don't infect what you build either, most especially if you are not modifying its source and rebuilding it.
And what we've seen from e.g. Apple is that "make a private fork and only distribute binaries" is exactly what they wanted the whole time.
you only need to worry about GPLv3 if you are modifying gcc in source and building it and distributing that.
That's the context here. If you build a new compiler based on GCC, GPL applies to you. If you build a new compiler based on LLVM it doesn't.
Still some companies try hard to avoid GPLv3, see Apple, who either provide old GPLv2 licensed software or invest in BSD/MIT replacements.
You might know this history better than me.
Strange philosophy, imo. Feels very much like saying "My version of free is best, and I must force you to implement it yourself".
Stallman's version of free is free to the end user. He cares more about whether the end user will have access to the source code and means to modify their software to remove any anti-feature, and less about whatever freedoms the developers of said software would want (such as, the freedom to close the source and distribute only binaries)
Ultimately Stallman was against a kind of digital feudalism, where whoever developed software had power over those that didn't
> free to the end user
To which none can answer how it creates freedom without mass adoption to actually get the software into end users' hands. The great contradiction in FSF philosophy is to create highly pure software within a monastery of programmer-users while simultaneously insisting to focus on end-user freedoms without reconciling programmer incentives to build what these end users need.
I'm responding to this comment as an end user with a free browser and free OS and it works perfectly fine. Billions of users do in fact.
So there doesn't need to be an answer. He can just show it to you.
Not that strange, as GCC was an effort to a goal of developing an ecosystem of Free (as in speech) software. While FSF had sometimes made allowances for supporting non-Free software (whether non-copyleft open source or proprietary), these were always tactics in support of the longer-term strategy. Much like you might spend marketing funds on customer acquisition in the service of later recurring revenue.
As RMS indicated, this strategy had already resulted in the development of C++ front ends for the Free software ecosystem, that would otherwise likely not have come about.
At that time the boom in MIT/BSD-licensed open source software predominantly driving Web apps and SaaS in languages like Rust and Javascript was still far away. GCC therefore had very high leverage if you didn't want to be beholden to the Microsoft ecosystem (it's no accident Apple still ships compat drivers for gcc even today) and still ship something with high performance, so why give up that leverage towards your strategic goal for no reason?
The Linux developers were more forward-leaning on allowing plugins despite the license risks but even with a great deal of effort they kept running into issues with proprietary software 'abusing' the module APIs and causing them to respond with additional restrictions piled atop that API. So it's not as if it were a completely unreasonable fear on RMS's part.
Nit: non-copyleft open source is still free software (as defined by FSF).
"My version of Free is best" is like the defining feature of GNU/FSF.
(Not knocking them, i think sometimes being obnoxiously stubborn is the only way to change the world)
Freedom through obscurutiy