The road to GNOME 3.0

The GNOME desktop environment made its 2.0 release in June of 2002, and quickly established a six-month cycle between stable releases. Now the release team has drafted a plan for GNOME 3.0, tentatively to arrive two cycles from now in March of 2010. A few user-visible changes are slated to appear, accompanied by far more refinements in the dependencies, language bindings, and the structure of what constitutes the core of GNOME.

Vincent Untz sent a planning statement to the GNOME desktop development mailing list on April 2 to outline the big issues and the release team's plan. The discussion is of course ongoing, but the basic idea consists of three components: new technologies that will directly affect the user experience, structural changes to the modules and module sets that define GNOME, and ways to promote GNOME in hopes of growing the surrounding community.

Zeitgeist and the Shell

The two major user-facing technologies scheduled to debut in GNOME 3.0 are GNOME Shell and GNOME Zeitgeist.

GNOME Shell is a new desktop layer that will handle displaying application windows, notifications, and other objects. It is intended to take the place of both the GNOME panel and the window manager, combining those functions into a unified "scene graph." GNOME Shell will use the OpenGL-based Clutter for rendering, and is written primarily in Javascript. Owen Taylor explained on his blog that the choice of Javascript allows a lower barrier to entry for applet authors. GNOME Shell will be an option in the GNOME 2.28 stable release scheduled for the fall of 2009.

GNOME Zeitgeist is a non-hierarchical file management system. Rather than finding files based on their location in the filesystem, Zeitgeist provides a suite of alternative interfaces to use: a last-accessed-on calendar, an easy-to-use bookmark system, tags, and content-type filters. Other entry points are in the works, including attached comments and location awareness (as is "files last opened when I was in Barcelona").

Library work

Developers will probably be more interested in changes to the platform itself, including shuffling out of old libraries, inclusion of new ones, and possible changes to GNOME's module sets.

According to Andre Klapper, several deprecated libraries will be removed in 3.0, such as the sound server esound, the file system layer libgnomevfs, 2-D graphics library libart_lgpl, and printing library libgnomeprint. Some new libraries will be introduced, including the aforementioned Clutter, GeoClue for location-awareness, and libchamplain for easy rendering of maps. Also new is the idea of "staging" level libraries; components hopefully in transition towards full support in a future GNOME release, but still making API or ABI changes. The key example here is GStreamer, which is widely used and enjoys tremendous support form the GNOME community, but still undergoing rapid development. The project also hopes to encourage developers to increase the usage of non-GNOME dependencies like D-Bus and Avahi.

More subtle changes are likely to come in the way GNOME is packaged. The current and long standing scheme divides the code into "module sets," as Untz and Lucas Rocha explained. Each set contains libraries and applications for a particular usage profile: the desktop, mobile, developer tools, platform bindings, and so on. One concern is that the current module sets make unnecessary divisions. Untz noted that the "developer platform" modules set (which contains C bindings) should really be combined with the "platform bindings" module set (which contains bindings for other languages); keeping them divided adds to the perception that C is blessed, but other languages are not.

Another problem is that the module sets have slowly become too rigid over the course of the 2.x releases, no longer encompassing all of the applications in the GNOME community, and perhaps unintentionally communicating that some applications are "official" while others are not.

Untz and Rocha cited several examples where two or more excellent applications of the same type seem to compete, including Rhythmbox and Banshee, Empathy and Pidgin, and gThumb and F-Spot. If the project selects one for inclusion in the desktop module set, it inadvertently slights the other, which is not the intention. "My personal opinion is that we should have a very small 'desktop core' module set and that's what we build and package 'officially,' then we have a separate process of certificating apps as 'GNOME-compliant.'" said Rocha. He continued:

"There's also the fact that we can create a 'brand' that can easily be recognized by users: if it's a GNOME app, then it's good," added Untz. Both agreed that the project should take steps to be more welcoming to outside projects and contributors.

Promotion

The third focal point for 3.0 is promoting GNOME better. To be sure, widening the community through reorganizing the module sets will draw in more developers, but as Untz observed, developers are only one of three target audiences. The others are users and vendors — a group that includes Linux distributions and mobile device makers.

In recent years, Untz felt that the project has not had a "crystal clear message." It has a good message with respect to usability, accessibility, and internationalization, but is not as coherent at presenting the GNOME desktop platform as a whole.

Exactly how to proceed is not as clear as identifying the issue. GNOME is a large project, but it is in the middle of the stack — neither a single application that a user can try out with a simple package install, nor a full operating system comprising a complete solution. GNOME Foundation executive director Stormy Peters observed that the vast majority of GNOME users use the environment courtesy of an install-time option from their Linux distribution. "That said, if a user has a question about a GNOME feature or application and search for it on the web, they are likely to end up either on the GNOME pages or a random distributor site (not necessarily the distribution they are using.) We want to make sure we are ready for those people."

The promotional effort will entail revamping the gnome.org web site, and a concerted effort from the GNOME marketing team. Untz summarized the challenge, "the hardest part (setting goals) is done. Now, it's about achieving them, and even doing more than that if we can."

Just the beginning

With two full release cycles in which to work, the discussion is just the beginning. There are several additional changes that could make their way into GNOME 3.0, including replacing the aging gconf configuration system with dconf, and an emphasis on "social desktop" technologies like the Telepathy framework.

Rocha and Ken VanDine both observed that they hope the 3.0 cycle widens the GNOME community. Rocha said he would like to see more space for experimentation, and VanDine added that he would like to see GNOME project infrastructure (such as git and bugzilla access) opened up to individual developers, so that they could create their own branches, propose merges, and participate.

However it plays out, Peters is confident it will reflect the wishes of the GNOME community. "The interesting thing from my perspective is how this is done in an open fashion. Before plans are even finalized we are reaching out to the GNOME community, our partners, the distributions and even users to hear everyone's input and to involve them in the process as much as they wish to be. It's likely that we'll hear a lot of dissenting opinions in the process — that's part of a good discussion — but the end product will be even better for it." The members of the release team are tracking the process in public; you can follow the roadmap as it develops from the GNOME project's wiki.