GNOME releases chug right along: every 6 months we have a new release with a big slew of new features. But most of the changes are really narrow and incremental. It’s really hard to do a feature that requires changes in multiple places in the stack; that requires new API at the library level. This is especially true if the new API at the library level isn’t obviously useful.
As a simple example, some years ago, as I was working on polishing font rendering for Red Hat 8.0, I made the observation that there were very strong individual preferences as to font rendering. Some people wanted contrast above all else; other people were willing to accept a little fuzziness to get well formed and spaced letters. So, I wanted to offer a choice of “Best Shapes” or “Best Contrast” in the GNOME fonts control panel. This simple idea required patches to: the GNOME control panel, gnome-settings-daemon, GTK+ (the GUI toolkit), Pango (text layout), Xft (font display), FreeType (font rasterization), and the fonts.
Now, the entire patch set wasn’t that big … less than a thousand lines, I’d guess … and at that point I maintained two of the modules listed above (GTK+ and Pango) and was personal friends with the maintainers of most of the rest of the modules. But it was still a huge pain to get all the patches upstream, and for years, perhaps still, a lot of people on other distros had a control panel with the options of “Best Shapes” and “Best Contrast” that looked exactly the same. The only reason the change was at all feasible was because working at Red Hat, I was able to go ahead and add the patches to our packages without going upstream. I could create an example desktop where the idea was fully worked out.
Right now, there are two main ways to make a change that spans across many pieces of GNOME. One is to advocate a vision strongly enough that you can convince people in advance that it makes sense, and then get maintainers one-by-one to accept your patches . This works fine if you are a big name and a powerful arguer; if you can produce patches that are so clean, so nicely coded, so authoritative that they get accepted even if the big picture is fuzzy. It doesn’t work for newcomers to the project. The other is to work for a Linux distributor or create your own Linux distribution and make the changes at the packaging level rather than upstream. Which has its own problems, and doesn’t seem to be a generalizable model. How can we make GNOME more friendly to innovation that cuts across different modules?
To me, any progress here is predicated on being able to treat the GNOME desktop as a product, rather than as a bag of tools for people to build products with. There is no way I can get people to try out GNOME with my cool new patch set if the way they try out the standard GNOME is to wait for their distribution to ship the next version.
A basic barrier to trying out GNOME, whether standard or patched, is the complexity of the whole thing … jhbuild is a really cool tool, but when there are dozens (hundreds?) of modules from different source repositories with different version control systems in different languages using different build tools, something is going to break on almost any run of jhbuild, and you are going to have to be a wizard to fix it. Not to mention the pure time commitment for jhbuild. A fresh jhbuild will take the better part of a day.
One thing we should always keep in our heads is how do we reduce the complexity of GNOME. No matter how much well we manage the complexity, it isn’t going to help newcomers navigate their way around and productively make changes. Unfortunately, reduction of complexity is never easy, especially when trying to maintain compatibility. But we should try to figure out how to make sure that by GNOME-2.24, a build of the basic GNOME desktop doesn’t include ORBit, bonobo, audiofile, esound, libgnome, libgnomeui, and so forth. If that causes ABI breaks (say, a distribution has committed to the CORBA parts of the accessibility stack as stable API), then we need to figure out how to manage and message those breaks. In the past, I’ve been known to say that API/ABI compatibility is a black and white thing, you are compatible or you aren’t. We should explore the grays. And we need to clamp down on people introducing massive amounts of new complexity.
A more immediate thing we need to do is to create standard jhbuild configurations. If you looked at what operating systems GNOME developers are using, you’d find that a very small number of Linux distributions and versions count for almost all of them. Given that I was running jhbuild on Fedora 7, there’s no reason it should have downloaded and built fontconfig-2.4.1when fontconfig-2.4.2 was installed on the system. There’s no reason I should have had to figure out the need to install perl-XML-simple when the build broke with a message about XML::Simple. In fact, there was no reason I should have had to decide what directory I was going install into, create it, and muck with permissions. It should have been as simple as installing a yum repo file, then ‘yum install gnome-jhbuild-2.20; gnome-jhbuild-2.20 build <wait three hours>’. And given standard configurations, we can tinderbox these configurations and let people have a high degree of confidence that things will just work. (I don’t think this idea of standard for-the-distribution jhbuild configurations contradicts the idea I started with of custom-GNOME-variant build configurations. It should be orthogonal.)
Given a standard-per-distribution configuration, it’s 100% feasible to go further and have things like the ability to rsync the tinderbox build tree from the last nightly build to reduce the build time. But that’s gravy. Reducing build time is not as important as reducing the need for manual intervention.
Then finally, you need to make sure that there are easy ways to try out the new build. You should be able to fast-user-switch and log in to the new build without logging out of your current session.
The basic message here is that we should consider building GNOME from source not to be an esoteric and experts-only activity; we should design GNOME to make it easy, the same way we design GNOME to make it easy access your recent documents. If we couple that with attention to keeping the complexity within bounds, and then think about how someone could create “a branch of GNOME”, we’d greatly increase the possibility for substantive innovation.