Looking a Novell gift horse in the mouth
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:
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 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.