What GNOME Can Learn from KDE's Recovery: Page 2

By contrast, GNOME 3 is as radical as it appears. Where KDE 4.0 allowed users to easily swap out sets of desktop icons, GNOME 3 ships with icons disabled. Where KDE supports a wide variety of panel or desktop widgets, GNOME avoids them in the name of simplification. Where KDE allows users to ignore activities and work on a single desktop, GNOME forces users to work in multiple workspaces.

The extensions of functionality and the flexibility of the KDE 4 series means that it has been relatively easy for many users to accept once they get over their initial resistance to change. But in GNOME 3, the changes are harder to ignore -- and if the changes don't suit your workflow, you are largely out of luck. Unlike with the KDE 4 series, acclimatization seems less likely to reconcile users to GNOME 3.

GNOME 3's inflexibility also means less room for evolution. KDE 4.0 was intended as a developer's release that would be gradually readied for users over the next few releases. Thanks to the eagerness of distributions to offer the latest software, as well as its misleading numbering, KDE 4.0 fell into general use before it was ready. However, its developers could always respond to criticism by telling users to expect improvements in the next releases.

But it is hard to see how GNOME can do the same when a single workflow is hard-coded in the design. Any attempts to add flexibility not only means working against the general design and adding complexity, but also admitting that the initial design was flawed -- something that none of its creators are likely to be comfortable about doing when they have worked for over two years on their re-imagining.

For such reasons, GNOME's ability to model its recovery on KDE's seems limited. Doing so isn't impossible, but seems in some ways unlikely.

Cons and Pros of the KDE Recovery

So what might GNOME learn from KDE's example? From a few comments I've heard about the Desktop Summit, the two projects do seem to be talking about the situation. The question is what is being learned.

With any luck, GNOME members have already learned that defensiveness doesn't help. Unlike KDE developers, some of whom initially responded angrily to criticism of their 4.0 release, GNOME project members have been largely silent in public about criticisms of their latest release.

This silence won't make the criticism disappear, and, if the silence lasts too long, may heighten the impression that GNOME doesn't care about users. Yet, in the short run, it is better than fueling the flame wars by participating in them.

Another negative lesson to be learned from KDE is that blaming free software journalists for reporting the reaction doesn't help them. Although KDE's representatives still raise the issue of balance in the free software media, they rapidly found that making themselves available to reporters is the easiest way to get their story out.

Sooner or later, GNOME needs to address the reactions -- and not in a marketing campaign. As soon as possible GNOME's developers need to imitate KDE's and place an emphasis on constructive criticism.

Like KDE's did, they need to engage documentation writers and other non-coding members of their project in the creation of the support infrastructure that their changes require. They need to show that they are not intimidated by user response or hostile to it, but welcome it.

In short, they need to show an awareness of users and to acknowledge their right to criticize in a way that they have never done before. KDE's recovery has succeeded to exactly the extent that it has done such things -- and failed to the extent that it has not carried such actions through all the time.