GNOME Interview

Like this article? We recommend 

I've been watching GNOME intently since Miguel sent me an email asking that I mention it on the Guile web pages. It's certainly changed a lot since then.

As we approached the 1.4 release, I wanted to take some time and talk to a couple of the release coordinators to get their take on the state of GNOME and the state of release management in the free software world.

Releases are something that don't seem to work too smoothly in either the free software or the proprietary software worlds. People even joke about never using an X.0 release. I'd love to see free software releases become so routine and so stable that users don't fear upgrades. It's probably an idealistic vision, but it would be nice.

This interview was carried out over email, between Jacob Berkman (jacob), Jamin Gray (Jamin), and me (Pate). Here's how it went.

Pate: Now that we're all here, let's start out with some introductions. I'd like to know who you are, how you got started with GNOME, what is your favorite GNOME package, and what do you do outside of GNOME.

I'm Pat Eyler, an unter-hacker and long-time user of GNOME. I first got involved in GNOME when I put a notice about it up at the guile web site, and have been using it since, hmmm, a long time ago. I spend a fair amount of time playing with gnumeric, abi-word, and the gimp, but my favorite application is same-gnome (I love watching my 7- and 11-year-olds play it...). Outside of GNOME, I do system/network administration consulting, cook, and try to get my kids hooked on good books.

Jamin: I am Jamin Gray (a.k.a. Skeezix). I've been using GNOME since about version 0.30 and h0ave followed its development closely ever since. For a while my primary contributions to the GNOME Project involved dispelling FUD, answering questions, and helping newbies. A few months ago I volunteered to co-coordinate (along with Ian Peters) the GNOME 1.4 Fifth Toe, a collection of GNOME applications which are not part of the core GNOME release but are popular and work well with the GNOME environment. My favourite GNOME package is Nautilus, though there are so many that I love and use daily—Evolution, Gnumeric, AbiWord, GnomeICU are amongst my favourites. Outside of GNOME I am a C++/COM developer working for a healthcare software company. In my spare time I enjoy reading, visiting pubs, and spending time with friends.

jacob: i'm jacob berkman.

i started using betas of kde 1.0 my freshman year of college at CMU. i didn't like it all that much for some reason. when gnome 0.9 came out, i gave it a try. once i saw the gnome panel, i never switched back to kde. i also used slackware back in those days, and the hours i spent getting gnome to compile ended up being very helpful when i started building packages here at ximian.

how i eventually got to hacking gnome is an interesting story, or at least i like to think that. in early 1999, i had recently abandoned a small project i'd been hacking, and was looking for something to do. i considered mozilla, but that seemed like such a daunting project to get involved with. i read about the gimp fork (http://slashdot.org/articles/98/12/15/0956214.shtml), and decided to poke in on #gimp on gimpnet.

soon after that, #gimp split into #gimp and #gnome, and the push for gnome 1.0 got into full swing. i started fixing small bugs in applets and mostly other parts of gnome-core (which were the parts of gnome i used). i ended up taking over maintainership of this module from miguel later that summer as he became too busy with things like bonobo and gnumeric.

i did a lot of bug fixing for October GNOME, and wrote bug-buddy soon after that.

at that time, i wasn't enjoying school very much and noticed that i could take a semester off from college and still graduate on time. there were various companies forming, and i talked to nat, miguel, and bart about working for ximian (then international gnome support) or eazel.

i ended up at ximian (by that time it was helix code) and my job was to do the helix gnome desktop. nat, tuomas, joe, and i worked fervently to get the first release out a little over a year ago, and have had some very high number of downloads since then.

after that, i was the release coordinator for gnome 1.2. i think i am still recovering from that.

since then, i've hacked a tiny bit on red carpet, ximian setup tools, and on our hp-ux port of ximian gnome.

right now, i'm a member of a team here at ximian focusing on development of technologies for the next version of gnome, as well as a bug finder for evolution and red carpet.

in my spare time i like to hang out with my friends and walk around beautiful boston. i love listening to music and will hopefully start playing some music again in the near future.

my favorite gnome package right now could very well be evolution; i'm really starting to enjoy using it, but i do enjoy same-gnome, gnome-breakout, and gyahtzee.

Pate: GNOME has gone through two big releases. As you started gearing up for 1.4, what did you see as priorities to making this release better? (Bonus question: What does better mean to you?)

jacob: [you said] two big releases; [there were] three, actually: gnome 1.0, october gnome, and gnome 1.2.

Jamin: What I really wanted to see happen during the release process of GNOME 1.4 was a high level of communication between the users, package maintainers and developers, and the release coordinators. The strength of Free Software is not just that many eyes can look at the code. It is also open nature of feedback and opinions that empowers Free Software. Consequently, I wanted a lot of feedback regarding which apps should or should not be included in The Fifth Toe (even the name of the extra set of packages was one of about two dozen creative suggestions).

A "better" GNOME environment than 1.2 to me means more stable, polished, better integrated, more powerful, and easier to use. GNOME 1.4 fits the bill nicely. Sawfish gives users tight integration with the desktop and windows, and you are still quite welcome to use any other window manager you prefer. The replacement of gmc with Nautilus gives an enormous boost to usability. With Nautilus comes the inclusion of new technologies such as the GNOME component architecture (bonobo), gnome-vfs, and better language bindings, which will make the GNOME development environment even more attractive to programmers. Finally, with the release of The Fifth Toe, new users will know right away which apps to try out first to see the best of the best.

One of the more important things to me, from a release standpoint, is the completeness of translations, and documentation for both users and developers. these are things that often get overlooked by developers because they are not exciting and don't affect the code much, but are important for the GNOME platform, and it is important that we keep improving in these areas.

Pate: Jacob, you're the veteran from the 1.2 release. Can you give us a little background on what was good and bad in that release from your perspective?

jacob: gnome 1.2 was an interesting release. it started out at the end of 1999 being a "hey, we should release this panel we've been hacking on for nine months, since it is really cool" release and turned into something much larger. we actually initially wanted to release it the beginning of february 2000, but i think it didn't end up coming out until the end of may.

it ended up being a larger release partly because of a large push for the documentation of almost *everything* (including just about every applet). user documentation had been more scarce than developer documentation in those days, and we finally had enough people who wanted to work on this, such as dan mueth and telsa gwynne. this was something i was really happy to see, and am also happy that their work is continuing from then to this release.

one thing that wasn't so great about 1.2 was that i ended up doing quite a lot of work. i was awake for something like 63 hours before the release went out, which wasn't all that fun. i think this was a result of a few things:

1. i had the time to spend on it.

2. other people were doing other things (working on nautilus, gtk 2, evolution, school, etc.).

3. i didn't communicate with people enough.

i feel bad that #3 was the case. the direct result of it was the creation for 1.4 of the release team. there is still a lot about releases that we have to flesh out, but i think we are on the right track to getting there. the contributions from sun (the application behaviour assertions) are also a positive step, and will be more helpful as we bring those into normal development.

when i look back on it, i am honestly amazed at the job that elliot did on OCTOBER gnome. i still feel like it was a better conducted release. however, i think the gnome that came out of gnome 1.2 was spectacularly better than any other previous to it. a lot of people really came together and did a lot of little things that made it feel like a nice release. it was really really nice to read the reviews of it in the various linux sites.

i think that guadec really helped gnome 1.2 out a lot. it was really helpful to have met in person the people you were working with daily. it's too bad that guadec will be happening after 1.4, but it will be a good place to plan out gnome 2.0.

Pate: Once the 1.4 release has been made, what are the factors you'll use to measure its success? Is there a specific threshold you need to meet to be able to say "We did a great job on this"?

Jamin: I think the two primary signs of a successful release are

1. Do users feel compelled to upgrade? Unlike Win98 -> WinME, I think GNOME 1.2 -> GNOME 1.4 is a very compelling upgrade. In addition to the small enhancements that further polish GNOME, users should readily see the advantages of the addition of the component architecture. Users will also instantly see the eye candy and usability improvements that Nautilus gives over gmc.

2. Will more Windows users be compelled to try GNOME because of what they read about 1.4? I didn't mention other desktop environments (though of course I'd like to see everyone try GNOME) because most of the world's desktops run Windows—it's Windows users we really should be targeting if we want to get millions more users. If GNOME 1.4 is good enough to convince more people to switch from Windows or at least use it in addition to Windows, then we're making progress and I'd view the release as a success.

jacob: for me, gnome 1.4 is more of an intermediate step in gnome's evolution rather than a real goal. there are many new gnome technologies in this release, such as bonobo, gnome-vfs, etc. that are only used by nautilus, and I am looking forward to when we can deploy them throughout the rest of gnome.

that being said, as long as i get to sleep the week before the release and the release in general goes smoothly i'll consider it pretty successful. what really matters is what is said about the release months from now, so it will take some time to find out how successful it is.

Pate: There has certainly been a history of corporate involvement in the GNOME releases (RHAD for 1.0 and October GNOME, and Helix Code for 1.2), but things seem more overtly corporate this time around with the advent of the GNOME Foundation, the involvement of Ximian and Eazel employees as 75% of the release coordinators, and the involvement of Sun as a contributor. Do you think this is going to help make the release better? What kinds of "growing pains" do you think will be the biggest problems? How much involvement would you like to see from companies leading up to a 2.0 release (and what kinds of involvement)?

jacob: well, without eazel nautilus probably wouldn't be what it is today, and I think the sun people are helping us take steps to having higher quality in our releases. so, for 1.4 it has helped. it also helps that the companies bring more "outsiders" into the gnome development community.

it can be tough at times, because the developers don't always have free will over what they work on. on the other hand, non-fun things get done that wouldn't normally get done. for example, while i would have liked to hack on other things more, the not-so-fun packaging I did last year helped gnome.

for 2.0 or later, i'm looking forward to sun helping with bonobo/uno integration and basic component deployment throughout gnome, as well as open office becoming more gnome-ized. I'd also like to see other companies like ibm become more visibly involved with gnome, too.

Jamin: As the 25% representation of the non-corporate involvement, I can look in from the outside, and what I've seen is that the resources that Ximian, Eazel, and Redhat bring to the table certainly have made the release better. Granted, when it comes down to it, it's people (whether a part of a GNOME-based company or not) who do the work—if Eazel and Ximian didn't exist we'd still get the work done; we're a community of hard-working individuals. However, we've been able to get things done faster and more efficiently by far because of their resources. GTK+ wouldn't be as good as it is now and we probably wouldn't even have Inti in the works if Red Hat hadn't been sponsoring GNOME development from early on. Without Ximian, would we have easy package installations and upgrades or software such as Evolution? Without Eazel, the GNOME project could not have developed such an advanced and professional file manager as Nautilus in such a timely fashion. And I think the recent involvement from Sun and other companies will provide a similar boost, especially in terms of bringing GNOME to other platforms and testing it thoroughly.

Pate: How does managing the release of a large Open Source or free software system differ from releasing a major package on its own (or a small package)? Does the basic methodology stay the same? Is there room for a "Releasing-Software-HOWTO" in the free software world? If so, what should it contain?

Jamin: Well, the primary difference between a large-scale free software project and a single package is the level of integration and coordination you have to achieve. The GNOME project is composed of many packages maintained by many different people. The challenge is to get all the packages to work together and to communicate deadlines, etc. to all the different package maintainers. There's pretty broad range in level of involvement on the part of the package maintainers, particular the Fifth Toe package maintainers. A lot of the packages are maintained by people with very busy schedules, working on their pet project in their spare time. Many of the packages aren't in GNOME CVS (at this time). So it is definitely a challenge to get the package releases in a timely fashion from such disparate sources; testing, documenting, and internationalization are all part of that challenge.

I think a document describing the release engineering process would be of great benefit to the free software community, particularly if it contained descriptions and examples of the entire process from start to finish—everything from setting schedules to releasing individual packages, staging the packages, testing the betas and release candidates, press releases, etc. There is so much that goes into the release process that users (and would-be project maintainers) aren't aware of.

jacob: there aren't all that many differences, other than the system being just more difficult to manage than a single project. you still need to coordinate with translators and doc people, and also to test your software with other software that may be installed. but all of this is just on a much smaller scale than with a project like gnome.

Pate: What do you think are the biggest obstacles to managing the release of free software? Many of the big (highly visible) free software projects have a history of slow release cycles, poor quality of initial releases, or both:

• linux: "brown paper bag" kernel releases and ~2 year cycle

• Mozilla: still not at 1.0

• gcc/egcs: long release cycle for 3.0

This isn't a flame; all of the above are making amazing progress if you look at components, content, etc. It's just that the releases seem to have problems.

What kind of tools does the free software world need to make project release management better? What tools are out there that aren't getting enough credit?

jacob: i don't know that it is really the tools which cause these "delays." if you look at microsoft, i believe memphis (win98) was supposed to come out in late 1996, and didn't until 1998. All the features of cairo are still not in win2k, despite it being delayed also. and there are still bugs in this software.

i saw some videos of the beta testing for win2k, and they have a huge number of machines and hardware combinations where nightly tests of that day's builds are run, which potentially lets them find a lot of bugs that would be hard to track down in the low-resource, volunteer-based free software universe.

other things that cause delays in free software are due to its open nature: because people are trying out your software, they find bugs and have problems that the developers have to look at. this is good, but it does take up time. also, it's difficult not to strive for perfection. if you don't have a corporation above you saying "this release has to go out," then there is more drive to have something perfect, especially if people can [use] and are using what's currently available.

also, at least in the gnome world, there aren't always clear goals set for releases, and software is usually in a more evolving state. this is similar to how red hat and debian handle releases. red hat has releases about every 6 months, while debian releases "when it's ready." red hat gets releases out which may have bugs, but they have some set of things they want to improve in that timeline (in the installer, for example). debian kind of just evolves over time, much like gnome.

Jamin: Well, one of the big problems is that many developers have different ideas of what they want to see go into a release; you end up in a situation where you're trying to do too much and the release is delayed. It is very hard to stick with a roadmap that was set before the hacking really began.

I can definitely see a need for a tool to manage the release process itself—creating the tarballs, staging them, updating the release metadata, and finally posting the release. We've got scripts to do those sort of things, but a piece of software that manages it all for you would save a lot of time.

Conclusion

So does this get us anywhere nearer to the goal of nice, clean, easy releases? Probably not. GNOME 1.4 came out, later than initially thought, but not far from the revised due date. There were certainly problems, but not as many as there likely would have been otherwise. I'm looking forward to seeing the state of free software projects continue to improve, and to see their release management keep getting better.