If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Paolo Bonzini, the sed maintainer who stepped down, has published a clarification:
Originally posted by http://smalltalk.gnu.org/blog/bonzinip/what-do-about-gnu
What to do about GNU? By Paolo Bonzini - Posted on February 2nd, 2013
About a month ago, I released GNU sed version 4.2.2 and included in the release a "rant" (more of a criticism, perhaps—I'm not a native speaker) about the state of the GNU project.
I made it clear that I had no philosophical disagreement with FSF; in fact, that's likely the reason why almost no one took my post as an occasion to attack the FSF and Richard Stallman. To the few that did: guys, you clearly missed the point. I wrote that text because I want free software and the FSF to be successful. My concern is that if GNU loses, the FSF loses—even if some other piece of free software happens to win.
Anyhow, these people were clearly a minority. I was surprised by the positive reactions to my post. All of the flames mostly concentrated on the virtues and sins of the C++ programming languages. I was most pleasantly surprised by the amicable reactions from fellow GNU hackers and from Stallman himself.
In fact, Richard clearly understood the difference between quitting maintainership, and quitting the GNU project completely; the difference between not contributing any more code, and rescinding all links with GNU. Resigning commit access meant I'll be contributing less code to GNU, but if there are other compelling ways to help, count me in.
So, here are some proposals to fellow hackers. Some of them may work out, some of them may not. It is even possible some of them are inapplicable because of U.S. law for non-profits. But I'm sure that they are welcome by the FSF, and that's already a good motivation to write them.
First of all, let's talk about GNU. GNU needs updated coding standards, and coding standards are about much more than brace positioning. The GNU coding standards should summarize best practices into a free document that people can refer to; everyone, not just GNU developers. Most importantly, such an update should focus on existing best practices. If you don't like something in D-Bus or pkg-config or the Autotools, fix it upstream (and be prepared to be told you're wrong). That's how it works with free software.
GNU also has a maintainer guide. The maintainer guide should document the services that GNU makes available. For example, a short guide to debbugs and the Hydra continuous integration server, both of which are used by many GNU projects. As an aside, it would be great if some of the infrastructure put in place for GNOME and other large GNU projects could be reused by all of them. Regardless of personal opinions about desktop environments, the GNOME project is clearly a successful community, and we all should learn from it!
Second, let's talk about what GNU is. There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on.
GNU should be reorganized around a few high-profile umbrella projects: for example the development environment (GCC, binutils, gdb, glibc, etc.), the build system (comprising Autotools but also gnulib), the POSIX environment, and GNOME. Everything else should either integrate itself with such a meta-project, or find another home. For example, as I mentioned in my December post, GNU Smalltalk could become a GNOME project.
Third, what about the FSF? The FSF could be the home for some of these projects. GNU MediaGoblin is an obvious example, and could perhaps be a "pilot" for more projects to follow. The FSF would donate help with bureaucracy, including copyright assignment. FSF and the projects it endorses could mutually benefit in terms of branding. Similarly, organizing a donation process for FSF-endorsed projects will likely bring members to the FSF.
FSF projects would be vetted quite strictly, and not judged as parts of a system---but rather, for their contribution to the advancement of software freedom. Such projects are often tied to academic work. It would be great if the FSF gave exposure to research that advances freedom. Perhaps even get access to funding from the National Science Foundation (in the U.S.) or the European Framework Programmes, and use it to hire developers for FSF projects.
GNU has been producing free software for almost 30 years now, and there's no reason why it should stop. Join us now and share the software; you'll be free, hackers, and we'll do our best to make it fun!
Apparently Michael was one of those "few guys who missed the point", along with few other members on this forum.
Paolo article was a nice groundhog detector. I hope somebody pushes more, its awesome way to reveal the backstabbers.