Home > Articles > Operating Systems, Server > Linux/UNIX/Open Source

GNOME Interview

Pat Eyler asks Jacob Berkman and Jamin Gray some tough questions about GNOME 1.4 and new product releases in the free software world.
Pat Eyler is the author of Networking Linux: A Practical Guide to TCP/IP (New Riders, 2001, ISBN 0-7357-1031-7).
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.


Editor's note: Because this is an interview, spelling and capitalization have not been standardized. We hope you'll enjoy the flavor of the authors' (written) voices.

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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020