To build the future we must first understand the past
How do you come up with a revolutionary new desktop while your users are wedded to the old familiar input ideas, tried and tested in the two decades since we all started using a keyboard and mouse?
If Linux were run by Apple, the developers would work in secret for years before announcing the availability of their new desktop metaphor. But the open source community doesn't work in the same way. Innovation has to be hammered out on online forums, in developer channels and through software releases. It's trial by committee, and many things can and do go wrong with the process.
Compositing effects are a good example. Almost as soon as David Reveman had finished his initial work on Compiz, patches could be integrated into almost any Linux desktop with no major changes. Users could install Compiz and start rotating their desktops within minutes.
But the task of turning these patches into a homogeneous part of the desktop experience has taken considerably longer, and it's an ongoing process four years after the initial release. This is because the path to acceptance for Compiz has been slowed down by the community, with disagreement, forks, apathy and duplication all hindering its progress. And it's the same for many other projects.
If you want to change the way people use their desktops, you have to change the underlying technology behind that desktop. Most developers interpret this to mean that they need a new release, with an all-new API and plenty of new technology for application developers to take advantage of. This is the theory behind KDE 4's glut of new libraries and frameworks, for example, but it also means that it takes time for developers to catch up, if they even feel so inclined.
Gnome development is more pragmatic. Version 2 was released at about the same time as KDE 3 in 2002, and broadly, it's still a version of this release that's the current version of Gnome. There have been no dramatic redesigns, API changes, feature overhauls or debugging marathons.
Instead, there's been the steady march of progress, and while Gnome may be missing some of the more experimental aspects of KDE, the latest release, 2.28, is still very different to the 2.0 release.
Topaz
This is partly because Gnome is more of a platform for applications than KDE. The user doesn't need to know that the F-Spot photo manager is written in Mono and uses C#, for example; the only important thing is that each Gnome application presents a standardised front-end by following Gnome's user interface guidelines.
It's for this reason that Gnome has been going from strength to strength, even on other platforms and operating systems, and this kind of idea doesn't need to be updated when a new version is released.
Gnome 3.0 is scheduled for release in September of this year, but like all version 2.x releases up to this point, it's unlikely to be a KDE 4-like revolution. Initially, there were plans for dramatic changes to be made, all falling under an umbrella term for Gnome 3.0 – ToPaZ (Three Point Zero).
If you look at some of the plans touted for Topaz, especially the results from some of the original brainstorming sessions, you'll see that most of the ideas remain in the current plan.
With the KDE 4 release, most of the development cycle for the revolutionary features that were supposed to make KDE 4 more attractive than version 3 actually occurred after the initial release. If KDE 4 were to be released now it would be hailed as a great success, rather than the stream of bugfixes and updates we've endured since 4.0 hit the mirrors in January 2008.
But at the same time, developers have to balance expectation. Would many people still be using the KDE desktop if they had to stick to KDE 3-era applications?
Fortunately, with the release of KDE 4.4, most of those criticisms and usability problems have been ironed out, and we finally have a KDE desktop that can replace KDE 3.5.
