top | item 4956899

GNU sed 4.2.2 released, maintainer resigns

399 points| bonzini | 13 years ago |article.gmane.org | reply

122 comments

order
[+] chernevik|13 years ago|reply
All disagreements aside, I'm deeply grateful for the efforts made to maintain and extend tools like sed.

I can't help see posts like this and worry about the perpetuation of open source, and wish I had the chops to do more to help.

As I write I'm downloading a Raspberry Pi image for my son's hardware. I'm getting him an Arduino, a soldering iron and a book for Christmas. I'm looking forward to learning along with him. I don't claim to understand the particular flows of code or inspiration, but I don't see how those projects happen without open source.

I also don't see how the Pi happens without industrial scale chip production. As I understand the matter, the Pi was developed by Broadcom staff on their own or 20% time, and its production occurs on interstitial time on production lines that could never be justified by a $25 SOIC. Pi is basically a cheap add-on to a massive industrial base.

Of course one point of vision is describing a realizable potential not apparent to the rest of us. But vision can and does proceed despite deviations from its perfect realization -- and sometimes is corrected by those deviations. I deeply disagree with RMS' politics, I'm deeply grateful for his technical contributions. I hope the community can always find a way forward.

[+] epistasis|13 years ago|reply
> I can't help see posts like this and worry about the perpetuation of open source, and wish I had the chops to do more to help.

I wouldn't worry about open source, that is thriving and alive. "Free software" is different, and very specialized. I also deeply disagree with RMS, but further I disagree with "free software" being the one true way (though I happily use it), and think that open source is better all around, for everyone.

[1] http://www.gnu.org/philosophy/open-source-misses-the-point.h...

[2] http://www.gnu.org/philosophy/free-software-for-freedom.html

[+] MatthewPhillips|13 years ago|reply
Why is Stallman still BDFL if he hasn't contributed a meaningful amount of code in years? Let him be the spokesperson so he gets the attention he desperately needs and leave the coding standards to people who code.
[+] dalke|13 years ago|reply
The FSF isn't about coding standards, its foremost about moral and ethical standards.

Edit: Oops! You mean BFDL for GNU, as compared to the FSF. That's a good question - should Stallman relinquish GNU leadership? What is the replacement plan should something happen to him?

I don't think that recent hands-on code experience necessarily plays a role in either case.

[+] bjourne|13 years ago|reply
I wish people would stop parroting that stupid lie. RMS is curently heavily involved in GNU Emacs development and has been for many years. Just check the mailing list sometime.
[+] piqufoh|13 years ago|reply
Agreed, but by definition BDFL is FL - For Life.
[+] juddlyon|13 years ago|reply
I wouldn't characterize that as a rant, Rails is a Ghetto was a rant. This was more of a reasoned venting. Too bad though, the guy seems like he's poured a lot of himself into these projects (from an outsider looking in).
[+] dfc|13 years ago|reply
I have been a FSF supporter for a very long time. That being said I have never understood why the gnu-prog-discuss mailing list is so secretive. I can understand having restrictions on posting but I have bever heard a good argument for keeping the discussions behind closed doors. I do not think SPI has any cabalistic mailing lists.
[+] bonzini|13 years ago|reply
It's secretive because "GNU is not about openness".

I personally believe it's okay to have a "cabalistic" mailing list, the problems are: 1) that the open mailing lists (bug-standards, gnu-system-discuss) are basically unused; 2) that rms is trying to make some topics (e.g., discussing if something could be used as a GPL loophole) taboo even for gnu-prog-discuss.

[+] belorn|13 years ago|reply
I find the "rant" and the linked post by Nikos Mavrogiannopoulos sadly missing any direct details over what the actual issues are. From reading it, one could get the idea that all the problem stems from GNU coding standard being archaic and not updated for modern programming.

Okey, I am skipping all the rant about FSF not funding software projects to pay developers, or that the GNU brand is not "hot", but both feels a bit silly. The hotness of a brand is transient, and in reality, only a handful number of brands inspires users and developers. I can't see how GNU would be more or less hot than say Gnome, KDE, or apache which each has a large number of projects under them. As for funding, since when did any of those organizations actually fund the projects? They role is provide help in setting up funding systems, help with tax declarations and provide further legal help.

Thankfully, the last link in the end (http://lwn.net/SubscriberLink/529522/854aed3fb6398b79/) looks to bring some light of what the actually issues really are: copyright assignments being US only, who the "owner" of a community project is, Nikos' feeling that he aren't getting any tangible benefits from being under the name GNU, and last a request for more transparency in the GNU projects decision process.

As for those reasons, there are two I agree with and two I don't. Firstly, Copyright assignments being US only is bad and shows an inflexibility a non-profit foundation should not have. Their role is to help projects, and thus should be as flexible as possible and thus provide equal possibility to assign copyright to US or EU. Second, as for who the owner of a community project is, the answer should stare the developers in the face. It should always be the community (developers and users) that "own" the project and decides its fate. If Nikos' announcement had included a decision by the community (preferable in a transparent manner), it would had been hard for GNU to object. Third, Nikos' feeling that he aren't getting any tangible benefits from GNU are his to have, but legal assistance is something many projects value. If a project has no need for legal assistance, no need for help in creating donation systems, and don't feel a threat about lawsuits against individual developers, then a foundation such as GNU, Apache or other similar organization are not going to give much tangible benefits. Fourth, in regard to more transparency in the GNU projects decision process, I can only agree with Nikos. The corner pillar in a community is transparency, and GNU should be fully aware of this. If there are discontent growing because of an lack of transparency, it should be addressed and fixed with high priority.

[+] CJefferson|13 years ago|reply
Just on your comment of legal support. One of his major complaints is that actually he is not getting the legal support he wants, and he thinks that he could do better by himself.
[+] dasht|13 years ago|reply
For a time I too was the maintainer for GNU sed. Part of that time I was paid by the FSF for that work (this was a long time ago, when the FSF had a small staff working directly on the Hurd and GNU). When I started, GNU sed was very incompatible with the relatively new Posix standard for sed. When I finished, it was less incompatible. It was during this same time that I started work on a new regexp engine for sed but that was not done by the time I stopped work on sed.

From that position I was able to observe fairly closely how the GNU project was being led, technically, in the days before the Linux kernel had had any real impact.

RMS's technical leadership was, I think, not very skilled. Let me explain what I mean:

If you were working on a program and sought his advice, he was very good at zeroing in on the issues and giving excellent advice. And sometimes if you were working on a program and he noticed something he didn't like about your approach, his criticisms were very good. People used to tell stories about how good a programmer he was and those stories were basically all true. He was sharp and I assume that, in spite of his age, he still is.

The problem was that he showed no effective capacity to really lead the larger meta project of pulling together a complete OS. He tried -- with projects like autoconf and documents like the GNU coding standards. And he kept a list of programs that, once we had those (he reckoned) along with a kernel -- GNU would be "done". That was about the extent of his "big picture" for project management.

Mainly, he concentrated on advocating for the idea of software freedom. I think the gambit was that if enough people demand their freedom, the project of organizing a GNU project would become easier. I don't think this gambit worked.

That was never a clear enough, coherent enough, or informed enough vision of the complete GNU project and, consequently, GNU has never really successfully gelled. You can grab some "100% libre" distributions, these days, but only barely. There is no sustainable culture and technical organization there ("yet", I hope).

The RMS failure I see is a failure at being a community organizer of GNU programmers. A lot of people got the vague idea of a GNU project. Many of us were happily recruited to the goal. But everyone I worked with at the FSF, including me, kind of went off in various incoherent directions -- doing what we guessed would help and that seemed interesting to us. We never "pulled together as a team" and, in the GNU project, that still doesn't happen.

The GNU project gradually accumulated a heck of a lot of very good "parts" but could never gel. The first three world-changing releases (GDB, GCC, and Emacs) really startled people. The various shell/text utilities in those early days spread because they were often usefully a little bit better than the proprietary "native" equivalents shipped by Sun, Dec, AT&T, etc. People sat up and took notice but behind the scenes the project of setting up a lasting "complete OS" project that would promote software freedom for all users ... never quite came together.

The "open source" people -- who I also later worked for, because I made a mistake in trusting them at their personal word to me -- seemed at first like they might help bring resources to the problem. In fact, what they mostly concentrated on was creating proprietary products using the free software "parts" from the incomplete GNU project. In the early days they sought to monopolize some of the key labor for the GNU project (and they succeeded, because they paid much better than RMS and many of those particular hackers didn't really give a shit about the freedom of users). As the "open source" industry matured it perfected its model of a perpetually incomplete / inadequate free software OS as a source of inspiration to enthusiastic youngsters, realized in practioce as a perpetually freedom-denying set of proprietary OS products. Companies like Red Hat and Canonical realized that they could exploit the deficit of community organizing to charge high rents for libre software, so long as they don't care seriously about the freedom of users. That's what they did and what they do.

So in my view, RMS was not good (and still is not good) at leading the GNU project -- but the real tragedy is brought on by the glad-handing, deep-pocketed, "open source" rentiers who place concern for their own profit above the freedom of the community.

[+] jcurbo|13 years ago|reply
> That was never a clear enough, coherent enough, or informed enough vision of the complete GNU project and, consequently, GNU has never really successfully gelled. You can grab some "100% libre" distributions, these days, but only barely. There is no sustainable culture and technical organization there ("yet", I hope).

Debian is a 100% free distribution, with a strong culture and high technical organization. It was the GNU distribution in the 90's until they parted ways.

Are there not dozens if not hundreds of distributions of free software based on Linux and the GNU core? Compared to the early days of Linux (and GNU as well), I'd say Free Software as a whole is doing pretty good. The very existence of those distributions and the amount of software based upon them is your sustainable culture and technical organization. Canonical and Red Hat could go away tomorrow and they'd still be there.

[+] rogerwilco|13 years ago|reply
What does it even mean for an OS to be "complete"? That no further work remains to be done on it? I wouldn't call that "complete"; I'd call it dead. A state that, not coincidentally, a lot of GNU projects have reached over the years-- Hurd among them. And now it looks like GNU sed has arrived there too. It's this attitude that you have to be the only one in charge of everything, the only one doing anything or being creative, that kills projects and communities.

And now we get to the real heart of the matter. Is it about giving companies, users, and communities the freedom to do what they want to do? Even if that thing is proprietary software, or open core models, or sharks with laser on their heads? Or is it about political, social, and technological control? The Apache foundation is about the former, and so is the Linux kernel. But the FSF has always been about the latter. It looks like they have poisoned your thinking too.

[+] pron|13 years ago|reply
> He was sharp and I assume that, in spite of his age, he still is.

Seriously? He's not 100, you know. Why wouldn't he be as sharp, or sharper, than ever?

[+] yuhong|13 years ago|reply
proprietary OS products?
[+] marcoamorales|13 years ago|reply
As someone who shares beliefs with FSF's ideals, reading this rant makes me think that maybe there's a chance to bring up another movement with the relative same ideals as Free Software but have a different type of leadership.
[+] algorias|13 years ago|reply
Doesn't the open source movement overlap quite heavily with the ideals of free software? I know there are also significant differences, specially the tolerance of proprietary code.

I'm not trying to start a flamewar here, just honestly curious why you think a 3rd alternative would bring change in any meaningful way. We have enough fragmentation as things stand.

[+] pestaa|13 years ago|reply
I made a few vague observations based on comments scattered around the web and this rant just made me want to write them down.

* GNU leadership seemed very stubborn from the beginning.

* GNU software is really great.

* Gnome is the new GNU.

I wish they wouldn't lose more momentum or the wide variety of software they write and maintain will suffer, too.

[+] dfc|13 years ago|reply
"Gnome is the new GNU"

I have heard this before but never really understood what it was supposed to convey? Is this statement purely from a technical viewpoint? Has Gnome done a lot of work with licensing and activism that I have not heard about?

[+] ilaksh|13 years ago|reply
I believe that MIT/BSD/Apache-style licenses are not only better for business but also better for developers and better for users than GPL-ish licenses.

If we get to a point where people don't have to make money, then maybe GPLish will be better.

I think that in a way the GPL and older code bases are just a less evolved and less practical tradition.

If I'm wrong, please explain to me why I'm wrong, because I would like to know.

[+] vsbuffalo|13 years ago|reply
I really like the elephant and gazelle argument. I am a huge emacs proponent and I love using it, but I feel like it need to be forked and gutted. The whole beauty of an extensible editor is that extensions should be optional. Including more shit each release is not justifiable.
[+] kindahero|13 years ago|reply
> but I feel like it need to be forked and gutted.

There is Xemacs FYI..

> Including more shit each release is not justifiable.

Maintainers have indeed plans to split the packages out of the core, as the package manager is already up and running..

[+] bonzini|13 years ago|reply
That was not a technical argument (slow, etc.)

It's about the structure of the project.

[+] peripetylabs|13 years ago|reply
Copyright assignment is impractical, and a great way to eliminate outside contributions to a project.
[+] nullc|13 years ago|reply
But the polar opposite where companies like qualcomm are aggressively patenting techniques their employees 'contribute' to LLVM/CLANG with nary a suggestion of offering licensing that makes it lawful for anyone to use... thats okay?

What the FSF does has its costs and limitations, but when the mobile patent war spreads to LLVM and renders it unusable except in the underground and by a few large patent mongers, we'll be thankful for the FSF's licensing stewardship on GCC and the rest of the GNU projects.

[+] binarycrusader|13 years ago|reply
I disagree. Copyright assignment is appropriate for some projects and not others. The mistake many people make is assuming that it should always happen or never happen.

Some projects owe part of their success to copyright assignment, like Ogre3D.

[+] ohnoohno|13 years ago|reply
My view: sed does not need to be "extended" nor should it require much maintenance. At least, the BSD sed's I use have not needed much work. I recall Brian Kernighan mentioning how little maintenance awk has required over the years. As such, I fail to see why changing maintainers is newsworthy. Perhaps someone was looking for an excuse to state their opinions on other matters?

I'll be honest I could not understand what Mr Bonzini is trying to say anymore than I could understand Mr Stallman's antics in the recent YouTube clip. With all due respect, what are these people on about? What is the problem? Clearly and succinctly, please.

[+] bonzini|13 years ago|reply
Just as an example of extending sed, I introduced "sed -i".

Yes, it doesn't require much maintenance, but sometimes you can be surprised. I started maintaining GNU grep 3 years ago because it was in a really sorry state. Some parts were almost rewritten to make it faster and more correct.

[+] nnq|13 years ago|reply
> It is likely not possible to convince a diverse group such as the group of GNU maintainers to agree on coding standards for C++

...bluntly asking: why? (In any closed-source C++ project, if someone writes a "style guide and coding standard" thing and the project manager supports it, people start writing "compliant" code, grunting or moaning at first but they do, and then it becomes part of "company culture" and people find it natural to write code by it - I believe with Google's C++ was like this too... why does it has to be harder for an open source project?)

[+] tomprince|13 years ago|reply
That was exactly the point being made. That things like coding standards often need somebody to make a decision and enforce it, and that RMS didn't do that.
[+] piqufoh|13 years ago|reply
If GNU BDFL is not supported by the community, and he wields his power unwisely, then maybe it is time for a fork - GNOME?
[+] rwg|13 years ago|reply
Except GNOME is a GNU project (the "G" in "GNOME" used to stand for "GNU"). This point was driven home about three years ago when RMS descended from upon high to decree that posts mentioning non-free software shouldn't be allowed on GNOME's blog aggregator, Planet GNOME.

Coincidentally, it was around this time that people started making noise about splitting GNOME off from GNU...

[+] cmccabe|13 years ago|reply
I wonder if his copyright assignment agreement also covered the assignment of trademarks. The name of the project, which seems to be the thing under dispute, would certainly fall under that umbrella rather than copyright law. On the other hand, GNU might have a pretty strong case that including the word "GNU" in the name without being actually affiliated with them would be misleading.

I have to say, cases like this really point out the flaws in copyright assignment. It just doesn't make sense from a developer's perspective. If you put in the work to create the code, why would you allow someone else to control the licensing and the name? With proprietary software, the reason is clear-- in exchange for money. But with open source or free software, you really have nothing to gain from copyright assignment, and a lot to lose.

If you disagree with whatever the GPLv4 ends up being (or v5, or v6...), your only option is to fork the codebase and choose a new name. Experience has shown that renaming the project loses most of the userbase (think OpenOffice vs. LibreOffice.) This just isn't right. Developers should have a say in how their code is used-- they should be consulted when the code is going to be relicensed.