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:
If we had proposed the changes on the mailing lists, it would have
started a huge discussion about what people hated about the design
("you can't make the panel menu depend on beagle!!!") and how it
should be different. And then we could have either (a) completely
ignored everyone and done it ourselves anyway, or (b) had a long
conversation about the merits of the design and then not actually
finished the code in time for NLD10.
So we did it ourselves, and now either GNOME will like what we
did, in which case, yay, free code for GNOME, or GNOME won't like
what we did, in which case, no harm no foul for GNOME, and yay,
brand differentiation for Novell.
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
does not want to give up on community
involvement in design:
This is a very sorry state of affairs for GNOME. But it is not only
Novell and its employees who have adopted this commons-sapping,
community-tearing, morally and intellectually lazy approach to open
design and development in GNOME.... Ultimately, this is *killing
our community*. And it must be fought.
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:
If you design stuff in secret then publish it, it will have no
review of quality, no style checking, no security audit, no extra
pairs of eyes and extra brains on it. Mouths are in oversupply but
brains/eyes are not.
Jeff agreed, and went on to compare GNOME
development with how the Linux kernel is managed:
While the Linux process has its warts, there are two things it is
great at that we should mention here: First, a fairly easy to
understand technical and social leadership - decisions get
made. Second, a pretty uncompromising approach to design in the
community - it's really hard to drop a pre-cooked hairball (cat
hair *or* angel hair) into the kernel process without getting
roasted, spanked and harshly reviewed.
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
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:
They are writing a component for use by developers, not an end-user
product. And they aren't ashamed of it and they optimize for it and
they do it well.
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'
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
Comments (29 posted)
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)
Page editor: Jonathan Corbet
Next page: Security>>