LWN.net Weekly Edition for February 9, 2006

Looking a Novell gift horse in the mouth

Novell's February 7 press release proclaiming its contributions to the X.org and GNOME projects was generally well received. It is hard to disagree with better graphics and more fun eye candy, after all. Novell's work shows that the free software community has the potential to take the leadership on desktop issues, and that is a good thing. Free software desktops will only take over the world if the community can produce a desktop experience that is truly better than the alternatives.

The issue that has come up in some quarters, however, is that of "community." Developers in the wider GNOME community, in particular, are feeling somewhat excluded from the process. Novell's work, to them, is not a community development - it's a product which has emerged in complete form from a corporate cathedral. While it is great that Novell is doing this work, they say, wouldn't it have been better to involve the community from the outset? Now community members are in a position of reviewing a large drop of code that they had no part in designing, and not all of them are happy about it.

If the words of Novell's Dan Winship are representative of the company's position (he claims to be speaking only for himself), Novell believes it has taken the right approach:

Dan goes on to say that it simply is not possible to perform software design in a community setting. Everything good which has ever been done in the GNOME project has been the result of a small group's work. All big community debates tend to do is to slow down or stop the process. "Design by committee," says Dan, does not work.

GNOME hacker Jeff Waugh disagrees does not want to give up on community involvement in design:

One useful perspective in the discussion came from Alan Cox, who made a distinction between "design by community" and "design in the community." The latter approach leaves the bulk of the design work in the small group which is most interested in it, but which recognizes that the community may have something to add. When design work is taken out of the community altogether, something is lost:

Jeff agreed, and went on to compare GNOME development with how the Linux kernel is managed:

If, from this particular perspective, the kernel process is seen as being more successful than GNOME, it might be worth asking why. It is indeed true that the kernel community responds poorly to large piles of code which appear out of the blue. Often, such code must go through substantial revisions before it will be considered for merging - the community gets its say in the end after all. The reiser4 experience is a good example; the new version of the Reiser filesystem showed up in complete form, with a request for expedited merging. Numerous problems were found with the code, however, and reiser4 remains out of the kernel years later, even with numerous fixes made and features removed. In the kernel space, most developers learn, sooner or later, to involve the community early in a project's life.

The leadership issue is worth a look as well. As Jeff pointed out, the kernel has a relatively clear decision-making process, though it can be frustrating for contributors to work with. Discussions tend not to go on forever because, in one way or another, decisions get made. Instead, says Jeff, GNOME is "without coherent leadership." He would like to see the GNOME project structure reworked so that decisions are easier to make - though what form those changes would take is yet to be worked out.

Another issue, raised by Havoc Pennington, is the vision the project has for itself. The GNOME project, says Havoc, needs to come up with a better idea of who its user community is and to not be afraid to lose users who are outside of that community. When the project has a clearer sense of what it is trying to do, decisions will be easier to make. The kernel project knows what it is trying to do:

Havoc suggests that GNOME might want to take a similar approach: create a series of components which can be rearranged and customized by distributors and gadget-makers to fit their specific needs. Such an orientation would let GNOME focus on making the best tool possible while allowing others, who are arguably closer to the ultimate users, to make the desktop fit those users' needs.

That leads to one of the driving forces behind this entire debate. To a great extent, companies distributing Linux (or products incorporating Linux) tend not to differentiate their offerings with kernel features. Distributors do add kernel patches, but the size of those patches has gone down considerably with the advent of the 2.6 development process. This is an important point: the development process change has had the effect of significantly reducing the differences between distributors' kernels. But user interface changes are visible to all who work with a system in a way which most kernel changes are not. Distributors will thus always have a strong incentive to put their particular mark on the desktop and to try to have the coolest features first. So, at best, we are likely to see more desktop work done in relative secret until it is deemed ready to be shipped. At worst, we could see a repeat of the highly tweaked desktops shipped during the worst of the proprietary Unix days.

Distributors have strong reasons to differentiate their offerings, but they also depend heavily on projects like GNOME to provide the foundation on which they can create those offerings. Taking much of their development semi-proprietary may help sales in the next year or so, but that could happen at the cost of eventually tearing apart the community upon which they depend, even if they do not necessarily respect its design guidance. If GNOME is to remain healthy well into the future, these two forces will have to be reconciled. The solution will likely involve a combination of project governance changes and a more community-oriented approach by all participating companies. This should be something the community can achieve.

Comments (29 posted)

Easter eggs and free software

Someday, when you feel that you have been sufficiently productive for a while, fire up the OpenOffice.org spreadsheet application. Select a cell, and insert =Game("StarWars") into that cell. Launch missiles at alien creatures until you feel ready to get something useful done again. Yes, the OpenOffice.org developers, evidently feeling that the application had become too small and quick, decided to toss in an easter egg. Judging from the occasional German-language popup window, this feature has been present for quite some time. Others exist as well, happy hunting.

Easter eggs have been present in software - free and proprietary - for many years. Old versions of make used to respond to "make love" with "not war?"; your editor notes with sadness that GNU make does not retain that feature. In general, easter eggs are a way for developers to express themselves, and are generally seen by users as amusing, or harmless at the worst. Recently, however, an OpenOffice user complained about the presence of the StarWars game. Free programs, he says, should not contain hidden features like that. One of the advantages of free software is supposed to be the lack of surprises; if you install an office suite, that is what you should get. The hiding of games, pictures of the developers, and other unrelated features in free software threatens to make the whole enterprise appear to be insufficiently serious.

Others have argued that easter eggs can endanger the use of free software in settings (like schools) where hidden games might not be welcome. This is, they say, one Microsoft feature that we do not need to emulate. To that end, various bug reports have been filed asking for the removal of easter egg features.

As a counterpoint, one could argue that free software is supposed to be fun for both its developers and its users. Those who don't want to play "StarWars" might be well advised to install a sense of humor upgrade and simply not invoke the feature - which, after all, one has to go looking for in the first place. When the code police start going after easter eggs, humorous diagnostics (the kernel still has several variants of the "peripheral is on fire" message), or possibly offensive code comments, some of the developers will start to think that they want to go elsewhere.

As free software development processes mature and the user base increases, it seems likely that many of the easter eggs are likely to disappear, especially in the larger, more mainstream applications. Developers who are interested in code quality and bloat will see an easy way to remove an apparently unnecessary feature. Projects which have their own PR departments (and, yes, such projects exist) will not welcome the sort of attention that easter eggs bring. And those which remain may be excised by the more business-oriented distributors. But, free software developers being what they are, there will always be a surprise or two waiting for those who know where to look.

Comments (22 posted)