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:
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.
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.
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.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.