The Internet has a habit of making anything you say obsolete as soon as you say it. No sooner had I compared the future of the GNOME and KDE desktops than GNOME announced that a version 3.0 would be released after all.
Because of the announcement and the subsequent discussion, I immediately had to reconsider my original conclusion: Does KDE have the evolutionary advantage after all? Or could GNOME regain it and continue to surpass KDE?
At this stage, definitive answers are impossible. While GNOME’s plans have received widespread publicity, they are still in the earliest stages. Few milestones have been set, apart from having GNOME 3 released a year from now, and the plans are essentially wish lists that have not been officially approved.
However, assuming that the plans go ahead in something like their present form, one thing seems clear: Whether GNOME competes successfully in the long term depends on usability issues.
Specifically, GNOME’s success depends mainly on whether users will accept the vision of usability contained in GNOME 3.0. This vision depends partly on GNOME’s final road map, and partly on the influence of Ubuntu’s Mark Shuttleworth’s campaign to make the desktop the rival of Apple, which should be in place about the same time that GNOME 3 appears.
The GNOME wish list
Considering that GNOME has championed incremental releases for the past seven years, the rapidly developing plans for GNOME 3.0 are surprisingly revolutionary.
According to Vincent Untz’s email to the desktop-devel-list and the discussion that follows it, GNOME 3.0 will be an ambitious re-imagining of the desktop. The GNOME Shell will replace the current panel and window manager, and GNOME Zeitgeist will introduce file management that is based, not upon the traditional hierarchy of folders, but on such alternatives as bookmarks, calendars, tags, and comments.
Behind the scenes, GNOME 3.0 will see a number of libraries deprecated, such as the esound sound server and the file system layer libgnomevfs, and the introduction of new ones, such as Clutter. In addition, a staging area will be created for applications like GStreamer that do not quite conform to the desktop’s standard, and greater provisions for D-Bus, Avahi, and other technologies that are, strictly speaking, external to GNOME, but whose use the project wishes to encourage.
Another factor that will affect GNOME 3.0 is the development of the third version of GTK+, the widget toolkit that GNOME uses. Although currently detailed plans for GTK+ 3 are yet to be drafted, they will almost certainly be affected by the efforts in GNOME.
An emphasis on usability
My first impression when reading the plans for GNOME 3.0 is that the planners are being optimistic. Considering that KDE 4.0 took eighteen months to plan and another eighteen to implement, the chances that GNOME 3.0 will be released in a year seem small.
It seems likely that at least six to eight months will be needed just to finish organizing the effort. I mean no disrespect to GNOME, but I wonder whether, after years of incremental releases, the project has under-estimated the time needed for such disruptive changes.
As I look more closely, I also notice that in a number of cases, the plans are not so much a rebuilding from scratch, like KDE 4.0, as they are a vacuuming out of some of the cruft that has accumulated over the years. Perhaps this difference makes the schedule more realistic, but I wonder how thorough a cleaning will result.
In general, it appears that GNOME 3.0 will not be as much of a fresh start as KDE 4.0 was, although this appearance may be due to the lack of detailed plans and my lack of familiarity with some of the technologies to be introduced. Certainly, the fact that the GNOME Shell uses Javascript should make it easier for developers to contribute to the project.
For now, the plans for GNOME 3.0 seem best judged by the changes to usability they propose. Nor is that the worst criterion; while developers might worry about the state of the back end, end-users are more apt to be concerned about the state of the desktop (unless, of course, the back end significantly affects performance). And, by this criterion, GNOME may be about to attempt changes that are far more radical than the ones that had KDE users screaming obscenities last year.
Next Page: The GNOME Shell, GNOME Zeitgeist and Usability Changes
The GNOME Shell, GNOME Zeitgeist and Usability Changes
I confess that I am still trying to compile and install the GNOME Shell on one of my computers, so I am undoubtedly missing many of its details. But the screencasts on the project page and the discussions about it on the desktop-devel-list are enough to start raising the alarm.
Judging from the screencasts, the GNOME Shell seems to position and resize windows far more efficiently than Metacity, GNOME’s current window manager — and, for that matter, better than any window manager I have seen. It also features a zoom for the simultaneous viewing of work spaces similar to the one in the KDE 4 series.
However, as someone who values his screen space, I am less thrilled by the removal of the application menu and applets from the panel and the dumping of them on to the screen.
Nor do I see any advantage to displaying applications as search results in alphabetical order. At least in the existing menu, you have the option of arranging menu items in meaningful categories. So far as I can judge, the GNOME Shell menus seem clumsier than the existing ones.
GNOME Zeitgeist raises similar concerns. By abandoning the traditional file hierarchy in favor of other search methods, it also abandons one of the last links between the desktop and the command line. That may not concern anyone who plans to work only on the desktop, but it means that, if they ever want to run a command from the prompt, they will need to learn another metaphor for file locations. Moving away from traditional file management may save time in the short run, but in the long run it may seriously limit users.
Such changes would not matter much if they were offered simply as alternatives. Personally, I forgave two of the most radical changes in KDE 4 — the Kickoff menu and the move away from icons on the desktop — because I was eventually given a choice of whether to accept them.
By contrast, the discussions about GNOME 3.0 suggest that users will not be presented with choices. Rather, the possibility seems strong that users will be presented with the new paradigms and expected simply to get used to them.
In the past, GNOME has had something of this tendency (it was the main reason, if you remember, that Torvalds criticized it), but GNOME 3.0 threatens to exaggerate this tendency until it is unbearable.
If that happens, then GNOME 3.0 will be a far more radical departure from the traditional GNU/Linux than KDE 4. It will also make the complaints about KDE 4 sound like an employee feedback session in the presence of the boss, and send users stampeding to KDE. In fact, just making the GNOME Shell and GNOME Zeitgeist the default options might be enough to remove GNOME from competitiveness.
The Canonical Factor
The wild card in the future of GNOME is Mark Shuttleworth, the founder of the Ubuntu distribution and of Canonical, Ubuntu’s commercial sponsor. Last summer, Shuttleworth began a campaign to make the free software desktop surpass Apple’s for usability in eighteen months.
Since Ubuntu’s default desktop is GNOME, GNOME is the main focus for Shuttleworth and his Design team. They are already in the process of persuading GNOME to accept their modifications to the notification system, and while these modifications have received criticism, they seem likely to be accepted as the first of many over the next year.
Canonical’s usability changes, in themselves, could have a large influence on the future of GNOME. Additionally, though, these changes could give Shuttleworth and Canonical a major voice in what happens in GNOME 3.0.
Next Page: GNOME consulting KDE?
Granted, Canonical is not the only voice in GNOME, and has no direct control over decisions. But Ubuntu is the most popular distribution, and Shuttleworth, with his determination and powers of diplomacy, has a history of getting what he wants. Nor does any other group have such a strong interest in usability issues. Given that Canonical is already concerning itself with GNOME usability, what could be more natural than it getting involved with the changes proposed by GNOME 3.0?
In these circumstances, how Canonical views the GNOME 3.0 proposals could be a major factor in their success. On the one hand, in the past, Canonical has not objected to changes that reduce options for users. While working on notifications, its Design team has shown a willingness to strip out features in the name of usability, which could well mean that Canonical will have no trouble with the proposals.
On the other hand, if the proposals contradict some of the usability principles developed by Canonical, then the company could be strongly motivated to campaign against them within the GNOME project or suggest alternatives. At this point, we simply can’t tell what role Canonical will play in GNOME 3.0, except that it is likely to be a large one.
GNOME consulting KDE?
What GNOME 3.0 will look like and how it will be received is still uncertain. However, a strong possibility exists that the result will be less of a technical overhaul than KDE 4 and a much more widespread user revolt.
Of course, that doesn’t have to happen. In practice, GNOME developers could take less of a hard line than they have done so far. They may also have the sense to consult KDE about how not to implement radical change, or be persuaded by Canonical to reconsider some decisions. Possibly, too, I am wrong about how GNOME 3.0 will be received, and there will be enough new users that the complaints of long-time users will be drowned out.
However, the early indications are not promising. Perhaps feeling the pressure as KDE 4 gains acceptance, GNOME seems to have been panicked into a hasty decision. It may have articulated a vision, but what if it is a vision that nobody else will want to share?
Bruce Byfield is a regular contributor to Datamation, where this article first appeared.
