One of the hallmarks of the GNOME project has been its rapid and continual development pace. Users who have followed the environment from its earliest days have been alternately treated to or felt hassled by the ever-evolving GNOME landscape, which has involved development not only of the components of the desktop themselves, but core libraries and other packages designed to provide support.

According to Adler, this rapidity has caused a few "stresses and strains" among the various groups coding for GNOME. Currently, for instance, though the project is moving toward an October release of version 1.4, work is already being done for libraries and packages that will form crucial parts of version 2.0, scheduled for next year.

"If you just look at CVS, there's no way to tell whether you're looking at the pieces of GNOME 1 or GNOME 2," says Adler, which he points out makes communication and coordination between the developers of all the various elements of the project that much more important.

Some of this overlap causes contention. According to Adler, "Everyone wants the one package they're working on to be an exception" to the current release schedule.

"Part of what's good about the GNOME foundation, even though it just looks like a set of companies, is that it also provides a way to formalize the way the hackers make decisions," he says.

Despite the organization offered by the GNOME Foundation, though, Adler notes that some broader issues seem to elude the Open Source community from time to time:

"There's a lot of delusion about quality and testing," he asserts despite what he refers to as his own marginal past advocacy of quality assurance testing, adding "I find myself feeling like a testing advocate all the time, now."

Despite this, though, he believes Nautilus will set a new standard among Open Source projects when it's released in October:

"I think that [testing] is something we'll do pretty well. People will be amazed at how good the quality of the product is."

Working well with the GNOME community isn't the only issue faced by Eazel's programmers. The variety of distributions and tools available for Linux make for some standardization challenges. The system update components of the services Eazel will be offering, for instance, will have to work well with a variety of packaging methods, such as Red Hat's RPM and Debian's dpkg systems.

Due to its popularity, the programmers at Eazel are using Red Hat 6.2 as a reference platform for their work, but Adler says confronting the wide variety of available configurations will be something Eazel will have to face:

"In the future, I think we're going to have to look for a way to abstract the package system much in the same way we've abstracted the file system," he allows. In addition, he notes that the diversity found in other areas of Linux distributions presents a daily challenge:

"We try to get weirdnesses out of our code as much as possible, when we discover we've accidentally done something distribution-specific, we try to 'unweird it.'"

Adler describes Eazel's role as developers within the broader Linux community as "good citizens" who are disinterested in seeing any particular flavor of Linux, or even specific Linux tool, rise to dominance at the expense of others.

Next: Building the Perfect Interface »