LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in Business
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for August 22, 2002The hard side of the BazaarThe "Bazaar" style of project management, as described by Eric Raymond and typified by the Linux kernel development model, is undoubtedly effective at producing quality software, at least in some situations. It can also, however, be a harsh environment in which to operate, as demonstrated by events in the kernel community over the 2.5 series, and especially over the last week.Readers of the LWN.net weekly Kernel Page will have been following the development of the IDE/ATA layer in the 2.5 series for some time. For the rest, here is some quick background to provide context for the rest. The IDE layer, of course, is the low-level code that handles the disk (and CD) drives found on most Linux systems. This code operates under a number of serious constraints. It must be fast - able to drive the hardware at its maximum speed; the performance of a Linux system as a whole is highly dependent on how fast its disks can go. It also must be absolutely correct; users get grumpy when their data is lost or corrupted. And it must deal with a wide variety of, um, "inexpensive" hardware that does not always behave as the documentation and standards say it should. Hacking on the IDE subsystem is not for the faint of heart. In recent times the IDE maintainer has been Andre Hedrick. Andre has had numerous communication problems with Linus (and others) which have made it difficult for him to get patches into the kernel. It is also fashionable in certain quarters to criticize the quality of Andre's code. But, it should be said: Andre's IDE layer has proved, over time, to be rigidly standards compliant and highly reliable. Andre's inability to get patches into the kernel left a void in the 2.5 series, however. That void was filled by Marcin Dalecki, who started posting his "IDE cleanup" patches back in February. The "cleanups" began to look increasingly like a complete rework (and hostile takeover) of the IDE code, and, with IDE 18, Marcin put his name into the MAINTAINERS file. Marcin's work has been controversial all along - especially after he started removing features that people were using, and when the IDE layer started breaking for some users. His approach was not subtle, and he seemed untroubled by the concerns of the other Linux kernel hackers. After all, said Marcin, "Breakage is the price you have to pay for advancements." Linus, for the most part, seemed to agree; he merged almost every patch from Marcin through IDE 115, posted on August 9. All this changed on August 16, when Linus, without fanfare, deleted the entire 2.5 IDE subsystem and replaced it with the "foreport" of the 2.4 IDE layer, done by Jens Axboe and others. The word from Linus is that Marcin got tired of all the criticism and quit; Marcin, himself, has been silent since then. It is telling, though, that Linus responded by simply deleting and replacing the entire body of 2.5 IDE work, rather than trying to find somebody who would continue that task. Either Linus came to agree with other kernel hackers about the quality of the reworked IDE code, or he concluded that nobody else would be willing to work with that code. The end result is that six months worth of Marcin's work, in the form of 115 IDE patches, has just been dumped into the bit bucket. And that is an example of the harsh side of participating in the kernel bazaar. One can work for months, see that work apparently accepted, then have it vanish in a moment. Linus has said numerous times that the doesn't much care about the feelings of kernel hackers; he is far more concerned about the quality of the code. This approach may well be part of why Linus is a good manager for Linux development - in the end, the code quality must remain high or the whole thing will collapse under its own weight. But it also explains why kernel hackers occasionally get frustrated and leave the kernel development community. The bazaar can be fun and effective, but it's not always nice.
The GNOME Human Interface GuidlinesThe GNOME project has announced the release of version 1.0 of the GNOME Human Interface Guidelines (HIG). The HIG is, according to the announcement:
...the most complete and carefully researched document of its kind
in the Free Software community [and] a major step
toward the creation of an easy to use and powerful set of free
applications with a distinctive and coherent style.
Leaving aside the hype, some examination of this 130-page document shows that it is, indeed, an impressive piece of work. The HIG examines many aspects of the usability of graphical applications, from window layouts, color selections, icon design, etc. through to things like how to label menu entries. A simple example of the sort of work that has been done:
User testing of MIT's Athena system revealed that users had
difficulty finding the file manager because they were unfamiliar
with the name "Nautilus". Because users did not associate the word
"Nautilus" with the concept "file manager" the menu item did not
help them.
Like many things in the usability arena, this conclusion seems obvious - in retrospect. Even after years of human factors research, creating highly usable applications still requires a great deal of plain hard work. Application designers are often blind to things they do that confuse their users. Creation of the best desktop applications available requires more than just great hacking; it requires serious attention to all of the little things that make those applications really work for the people who will use them. The HIG, thus, is a great contribution to the free software community, in that it will help to focus and guide that attention. The HIG is also the sort of work that free software developers are not supposed to be good at. What self-respecting, ego-driven, itch-scratching free software hacker is going to bother with human factors research, after all? Such claims have been increasingly hard to defend for some time; the HIG is just one more example of what the free software community is really capable of. One other quote from the announcement is worth a look:
Further, we would like to challenge the KDE project to serve the
general user community by partnering with us in developing these
guidelines to create a common Free Software interface style.... We
call on the members of the KDE project to rise above Not Invented
Here (a natural tendency that neither project has been particularly
succesful in repressing, we know) in taking a major step for the
good of both our user bases and the long term success of Free
Software on the desktop.
A true gesture toward cooperation could certainly have been done in a less public and challenging way. It is true, though, that the creation of a common interface document could be a good way for the two projects to work together. The creation of a more consistent desktop environment across the two projects would help both - as would a more formal approach to human factors in general. And both projects could join this work while maintaining their own code bases. It's worth some thought.
The obligatory LWN status updateThere is not a whole lot to report this week with regard to LWN's status and life expectancy. We are still in "discussions" with our credit card clearing company. We are still hacking on the subscription code (it's mostly complete) but are not sure if we will be able to accept credit cards to pay for those subscriptions. Hopefully all of this will settle out before too long. Meanwhile, we're doing what we can to continue to produce the best news available for the Linux and free software community. Thanks, as always, for your continuing support.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||