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].
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.
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.
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.
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
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.
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/
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.
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.
Freedom through obscurutiy
Strange philosophy, imo. Feels very much like saying "My version of free is best, and I must force you to implement it yourself".
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.
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
"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)