Havoc Pennington

April 21, 2005

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 disruptive.

There's also a reality that the GNOME 2 desktop, as shipped by most everyone, is the GNOME environment plus Firefox plus 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 [ ]. 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 apps.

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.

Copyright 2005