My take on the GNOME
3 discussion is that we have multiple goals at the moment which
are truly in conflict. On the one hand, we have the fairly traditional
desktop of today, with some growing userbase, and it’s important not
to break it. Most of the employed-to-work-on-GNOME developers are
focused on this. On the other hand, innovation is necessary to move
forward, and there’s a lot we could do. But we don’t want to drag
today’s users through broken intermediate states and make them wait 3
years for bugfixes to come out.
Look at how much screaming we get for relatively tiny changes
to today’s desktop such as the file selector, focus stealing
prevention, or whatever. Even with these small things, until the
details are ironed out (adding typeahead to the file selector, adding
flashing taskbar buttons to the focus stealing prevention) it’s pretty
There’s also a reality that the GNOME 2 desktop, as shipped by most
everyone, is the GNOME environment plus Firefox plus OpenOffice.org
plus Evolution or Thunderbird; which means that to take a particular
UI direction or add a platform feature, you have to convince all of
those projects to change… and they are incented to keep the platform
as similar to Windows in basic structure as possible. The value of
platform features is to create commonality between apps, so if apps
don’t use the platform, platform features are useless.
So the forces of existing userbase, the easiest-to-reach future
userbase, cross-platform applications, and funded development efforts
are strongly pulling GNOME 2 toward conservatism.
I think GNOME 3 should be a fork for that reason. There’s another
reason it should be a fork; I’ve been using a petrified wood
analogy. The process for forming petrified wood is that an organic
structure is replaced by minerals. The result is a rock, with the same
shape and structure as a piece of wood.
If you think about the transition from GNOME 1 to GNOME 2, as with
petrification we took the structure of GNOME 1 (session manager plus
window manager plus file manager plus control center plus panel) and
recoded it to be a different material, but the same shape. GNOME 2 is
in an important sense “the same thing” as GNOME 1, though it’s
certainly much more robust and polished.
This structural similarity is fractal in nature, so on the
whole-network level we have the structure of thick clients plus
mail/calendar server plus directory server for example, and or inside
the toolkit we have the basic premises shared by GTK+, Qt, and Swing.
Some people seem to think of GNOME 3 as “when we get to break ABI” – I
consider this a dumb goal, and I’m not sure breaking ABI even gets you
anywhere. GNOME 3 may be more about creating different ABIs. My
view is that GNOME 3 is interesting vs. GNOME 2 if and only if we are
changing the structure, i.e. what the desktop really consists
of and how it works on a macro level; GNOME 3 can’t possibly be worth
it if we’re just substituting minerals for lignin and cellulose but
getting the same structure in the end. It’s worth it if we’re building
a different kind of tree.
Something that makes GNOME 3 harder: you can’t change this macro level
in interesting ways without breaking all the apps. (I state this with
confidence because apps are the only interesting purpose of a desktop,
ergo failing to change the apps means you’ve failed to change anything
interesting.) Which doesn’t mean you can’t run the old apps, but it
means that today’s apps would be sort of freakishly out-of-place on a
GNOME 3 desktop that had changed shape. In other words old apps would
run in a “compatibility mode” and would be visibly distinct from new
I don’t know if we should do GNOME 3 today, or who should do it; but I
would caution that the purpose should be real value. Structural change
rather than rewriting purely to get new construction materials. And I
think this makes a temporary (but probably multi-year) fork almost
mandatory. Trying to do GNOME 3 “in place” will destabilize GNOME 2
while preventing the structural changes that would have value.
(This post was originally found at http://log.ometer.com/2005-04.html#21)