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
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").
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
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:
The side-effects of this new way of organizing our releases,
would be: 1. we'd be able to embrace more contributors, as they'd feel more
part of GNOME with their "certified" app. 2. we'd be able to promote more
cool stuff happening inside GNOME community. 3. focus on promoting the user
experience which is common in all GNOME apps.
We close ourselves to a lot of innovation happening "outside" the
official releases. For example, GNOME
is great app, is getting a lot new users, looks good, has some
features that end-users value a lot — GNOME Do happened "outside"
"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.
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
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,
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.
to post comments)