> A private thread ensued between myself, GNU, and Benno, and what came out of that conversation was that Benno was not going to be allowed to become a maintainer of the project in GNU’s eyes.
This is the part I'm most curious about. Why didn't GNU let him become a maintainer?
> Off topic, but I enjoyed seeing the leaders of the various GNU projects listed in one place as signers of this letter. I don’t agree with them but it is good to see their names and projects listed.
Notice that for most of the big projects, it is not the leader name that appears on that list, but only a particular developer.
People developing software. For example the gnome folks. You, me. (don't know about you, but I have services that use systemd for starting and supervising the service)
> If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO.
Yes, actually, yes. If Linus decided that all future development he wants to do is now closed source, I either have the option to fork and continue in the open or GTFO. I'm not the one to decide what he can to in his time. There's be a number of legal issues surrounding that, for example that he can't take the current kernel code, but if he decides that within the given framework he closes his development, fine with me. If Linus decides that he thinks that a deep integration between the kernel and systemd is the way forward for his project, I have to accept that. I may not like it, but unless I do something to change it I can't force it any other way.
The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.
> though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license,
My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction.
So the license change was meant to prevent forks from merging in further work on XFree86.
Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
> And stop forking OpenSSL; you’re just making things worse.
I strongly disagree that forks are making things worse. The solution to a project that is too difficult to fix due to baggage or a bad community or bad maintainers is to fork.
I mean more like GNOME which once was a GNU project and then left GNU to continue on their own. There are more examples like that. They don't need new manpower or inertia. They just drop GNU if they feel it keeps them back (which a lot of projects recently think, apparently, after the whole RMS drama some time back)
> If you disagree with the kernel naming guidelines you are free to create your own fork. Good luck.
You do realise that cuts both ways. Why did some people raise this issue in the first place - according to your logic, they should have just forked it.
Silly arguments like this don't contribute to the discussion in any meaningful way.
> I'd just like to interject for a moment. What you're refering to as non-GNU Linux, is in fact, Linux, or as I've recently taken to calling it, GNU plus Linux minus GNU.
> Then the Michael Niedermayer side took back control and the group that took over ffmpeg abdicated power over ffmpeg and its brand and moved to a fork.
Once again, no, it’s not what happened. A team forked but failed to gain significant traction and the original project is now the only one remaining.
The email you quote comes from just before the fork. Niedermayer was the main maintainer of ffmpeg and as stated there was disagreement between him and what became the libav developers about the possibility of adding new features while improving the code.
The libav team wanted to fully focus on code improvement and left in a very vocal and really obnoxious way. As anyone could have predicted history showed the they were wrong. It was completely possible to do both new features and code improvement at the same time.
Niedermayer resigned in 2015 because the way the fork was handled had made things painful for him which I fully respect.
Nano has been part of the GNU Project since 2001, and Benno has been contributing to that project for years.
reply