How does a Linux desktop survive a user revolt? The recent history of KDE suggests some answers.
Desktop Linux has had four years of upheaval. Since 2008, KDE, GNOME, and Unity have all faced vocal criticism from users, creating an opportunity for other desktops like Xfce, LXDE, Mate and Cinnamon to gain popularity.
But, in all the discussion, one question has never been discussed: how did KDE, the first desktop environment to suffer a revolt, manage to live through the experience and continue to prosper?
The question is not just one of historical interest. Because KDE's revolt was the first in desktop Linux, it is further along than those that GNOME and Unity continue to face. Mostly, criticism of KDE has faded to a matter of personal choice, and the project enjoys almost the same popularity that it did before the revolt.
By looking at how KDE weathered its storm, we can start to judge whether familiarity will breed acceptance for GNOME 3 and Unity, and identify some of the cultural traits that might help or hinder a project from recovering from a revolt.
Of course, more examples might help. However, since KDE is the only example available, I can only extrapolate from it, like an exobiologist imagining life on other planets from terrestrial biology, knowing that more data could easily alter the conclusions.
All the same, I do not think KDE was simply lucky. Nor was its continued prosperity simply a matter of waiting out the complaints and letting people get used to the changes of the KDE 4 series.
Instead, I see nine reasons why KDE managed to move beyond the initial hostility towards KDE 4:
9. Hands on Usability Theory
Both GNOME 3 and Unity were shaped heavily by usability theory. Very few users complained about clutter on the desktop, but, citing theories that clutter was confusing for people, the developers of both set out to reduce the contents of the desktop. The dubiousness of this theory is suggested by the fact that almost all the extensions for both desktop environments return the desktop to the supposed clutter of GNOME 2.
KDE developers are no strangers to usability theory. However, theory rarely seems to overwhelm the traditional free software approach of developers building what they want to use themselves -- or, as Eric S. Raymond described it, scratching their own itch.
One example of this approach is seen in the blog of Aaron Seigo, the lead plasma developer. Although Seigo is frequently dealing with large scale changes, he often mentions interrupting his main work to add a small feature to one of the applications he cares about. Other KDE bloggers are much the same.
This approach might mean that some features get neglected for more interesting ones. However, it has the advantage that, if one person wants a feature badly enough to add it, chances are that plenty of other people do, too.
8. A Project Culture of Discussion
I start each day by scanning a number of sites, including the GNOME, KDE, and Ubuntu Planets (blog aggregators). This habit not only keeps me informed, but creates a strong sense of the culture of each project.
All three consist of blog entries about new features and applications, with occasional marketing and project news.
However, the KDE blogs are far more likely than either the GNOME or Ubuntu ones to include the history of new features and applications, and to explain the logic behind the features. As often as not, this explanation continues in the comments on each blog.
At first, this tendency might seem non-essential. I suggest, though, that these efforts to explain and justify serve as a replacement for abstract design theory. They ground KDE design in the practical, and encourage developers to discuss the rationale behind what both they and their peers are doing.
7. Extensions, not redesigns
When KDE 4.0 was first released in January 2008, it was perceived as being radically different from existing desktops. In some ways, this perception was accurate -- in particular, under the hood, KDE 4.0 had begun the policy of abstracting things such as personal information, sound, and interfaces into separate sub-systems, just as most desktops had abstracted printing over a decade before.
This change altered the logic of routine operations such as how setting up the desktop were done, and made possible changes like FolderView icon sets and task-oriented Activities interfaces.
However, once users got past the changes in logic and the setup, the KDE 4 series offers much the same user experience and workflow as earlier releases. The desktop has more capacities, but they are easier to accept because the fundamentals haven't changed.
6. Completism, not Minimalism
If you compare KDE applications to their GNOME counterparts -- for instance, in music players, Amarok to Rhythmbox, or in DVD burners, K3B to Brasero -- you soon notice that KDE developers cram everything into the interface, while GNOME developers focus on the most common functionality.
KDE's kitchen-sink approach creates problems with organization. For instance, for several releases, the Systems Setting window had an advanced tab that was a dumping ground for utilities that didn't fit into any of the existing categories.
However, this approach also means that KDE developers are less likely to make assumptions about how users are likely to navigate the interface. They put everything in, and let users figure out how to work with them.
If the result is sometimes confusion for first time users, it also means that users are less likely to have to adjust their work flow to the software. There is something for everyone, and everyone can work the way they want.
5. An Emphasis on Customization
KDE is famous for its customization options. In fact, one of the main complaints about KDE 4.0 was that it lacked the array of options that KDE 3.5 had – largely because it was meant as a developer's release. But subsequent releases soon restored the level of customization that users expected, and the complaints soon died.
Moreover, while GNOME and Unity were reducing the amount of possible customization by eliminating or de-emphasizing panel applets and desktop application launchers, the KDE 4 series not only kept both, but encouraged their growth. KDE adds swappable icon sets and openly encourages panel applets (or widgets, as it calls them), especially for social media applications.
The same thing happened with file managers. When Dolphin became the default file manager, Konqueror was supposed to be the official browser. However, Konqueror lost none of its features, and can still be used for file management.
You might say that where GNOME and Unity bring order to the desktop by restricting customization, KDE embraced the chaos of conflicting needs and offered something to everyone.
4. Creating New Places for Customization
Recently, GNOME has started emphasizing extensions. Similarly, Unity has encouraged innovations in lenses, the filters for the menu.
However, for every place where GNOME and Unity provide new ways to customize, KDE seems to offer two or three. Activities, desktop widgets, special effects, desktop setups, hot spots on screen edges – all these have been emphasized in KDE, providing more specialization than ever before.
3. No Forcing of Changes
The KDE 4 series opens up new possibilities to users. But it has also been careful not to force users to work with any of the new features. Despite all the emphasis on Activities, users can ignore them in favor of virtual workspaces, and work with a desktop whose appearance differs only slightly from what was available in KDE 3.5.
In much the same way, users who dislike the default menu can revert to the classic menu, and System Settings can be toggled from a window of icons to the traditional tree view.
Nor is there any discussion of phasing out such backward compatibility. KDE's default configuration amounts to a suggestion of which features to use, but does not compel users to accept the suggestion.
2. A Lack of Overplanning
Linus Torvalds recently said that the Linux kernel was successful because it does not have a "huge vision" of how it wants to develop. In other words, by not being locked into a detailed plan, it is free to develop in the ways that people want.
Much the same can be said about KDE. True, KDE does have a general sense of objectives, and features may be scheduled to be phased in over several releases. But so does the kernel. What both seem to lack entirely is a unified, exact vision of what the desktop should be, or how it is used. Consequently, its developers are less likely to assume that they collectively know better than users.
1. A Willingness to Face Problems
In the first months after KDE 4.0 was released, KDE developers kept mostly silent. Then a few reacted angrily, some of them blaming the media. However, after about six months, KDE began making serious attempts to assess what went wrong, discussing the situation in their blogs for much of 2008.
Some of this assessment was defensive, with developers claiming that, eventually users would come to accept the changes brought by the new release series. But a surprising part of it was thoughtful and nuanced, recognizing that the revolt had multiple causes, and that some of the blame was due to how the release was managed and faulty expectations within KDE.
How much this assessment affected the next few releases in the KDE 4 series is hard to say. KDE had always planned to restore the features missing in 4.0, so satisfying users was sometimes only a matter of staying the course for the next few releases.
But the fact that KDE recognized that a problem existed did result in more attention to online help and efforts to engage the community in the release process. While these efforts might have gone further, they showed that KDE was at least intermittently listening to complaints.
If nothing else, KDE's members recognized that a problem existed. By contrast, much of the anger expressed about Unity and GNOME seems due to the impression that their developers are not interested in hearing from users.
What KDE Teaches
KDE did not do everything right in responding to its user revolt. It could have responded sooner and more sympathetically. Just as importantly, aspects of the project's culture that helped reduce the revolt might cause other problems.
But what matters is that KDE did enough to preserve most of its popularity. Within a year, the revolt was already starting to sputter out, and, within two years, those who continued to complain about the KDE 4 series were starting to sound crankish.
To some extent, the GNOME and Unity revolts may also seem to be dying of natural causes. As the two desktop environments become more polished, some reviewers seem to be coming to a grudging acceptance of them.
Others seem to think the discussion has gone on long enough. For instance, when a posting about the upcoming GNOME 3.6 release produced the usual acid remarks, Jonathan Corbet, the editor of LWN, suggested that such remarks were no longer useful, if they ever were. Corbet was pleading for a more focused and productive discussion, but his comment did little to raise the tone, which suggests that, for many, the revolt remains far from over.
The reasons why KDE survived its revolt could be summarized in four maxims:
- Innovate, but not too much
- Suggest, but do not enforce
- Encourage variety, not uniformity
- Acknowledge that others perceive a problem, especially if you don't
Currently, I judge both GNOME and Unity as behind where KDE was at the same point in its revolt. I suggest that their ability to quiet the revolts and retain users will depend largely on their ability to make these maxims part of their project cultures.