KDE 4 problems highlight shift from community users to consumers

The reasons for the user revolt against KDE 4, which we reported on yesterday, are still being sorted out. They appear to be a complex mixture that includes the assumptions that KDE used in its planning, the rush by distributions to include a release that was not ready for general use, and sensationalism in free software blogs and journalism. One reason that has yet to be discussed is one of the potentially most significant — the apparent shift in the FOSS user base. Judging from the quickness and thoroughness with which KDE 4 was rejected, the audience for free software seems to have shifted from a small group of knowledgeable users that treasures innovation to a larger one that values convention and familiarity and is actively suspicious of change.

In many circles, KDE 4 was greeted by an outpouring of emotions that you can deduce by the number of exclamation marks in the postings. Somebody, it seems, dislikes just about everything about KDE 4, from the icons to the menu to the use of Dolphin as the file manager. Some of these complaints, of course, are justified, but the complaints gallop off so quickly, in so many contrary directions, that the only way to reconcile them is to look for an underlying cause.

This cause, I suspect, is a dislike of anything radically new or different. Consider, for example, this anonymous comment on Groklaw: “Yes — a boring, old, unchanging OS, that does its job as only a tool is basic to the desired simplicity of what any business wants! … KISS — keep it simple stupid.” Although claiming to talk for business users, the poster can only be presumed to talk for himself, and what he — and many others — is saying is that they prefer what they know, and distrust change.

That’s an illogical attitude. The KDE 4 desktop may be more stylish than earlier desktops, with its photorealistic icons and vector graphic rendering, but it’s still a desktop, with a recognizable menu and panel. If some functions, such as adding an icon, are performed differently, they are not that hard to discover. Nor do you have to probe very far to discover that, if you dislike, for instance, the new menu (which I do), you can swap it for a classic menu. Meanwhile, the KDE 4 ports of standard programs are more conservative than that of the desktop itself. Many have facelifts, and most sport new features, but they are still recognizably the same program.

The trouble, of course, is that fear is not lessened by logic. For a sizable proportion of desktop GNU/Linux users — or, at least, a vocal minority — change is no longer welcome, but something to be avoided, except perhaps in bug-fixes or minute increments.

Because those with a fear of change are likely to be those newest to the free desktop, the chances are high that they will voice their complaints, not as constructive members of a project’s community, but in the only way their previous experience with proprietary software has taught them — as consumers who have to scream their anger or exaggerate it in order to get the attention of the leaders. Such is the consequence of free software’s growing popularity.

Looking for solutions

This situation leaves developers of large and popular projects with a dilemma. On the one hand, most free software developers want to add and enhance features. At times, too, they want to overhaul the code to make it more efficient. Their pride and interest in their work demands that they improve it, yet this desire may run counter to the desires of their most vocal users.

So what can developers do? The old hacker’s cry of “Code it yourself, then,” is not the answer. Nor can they ignore the users — those complaining will simply bombard the project with postings on its mailing list and rants on their blogs. If they can’t find a forum for their voices, they will hijack one. Before long, core developers will spend more time answering criticisms than programming.

Yet giving in to the complaints is no better as an alternative. While most desktop projects these days try to pay attention to user feedback, projects can do only so much to accommodate those who want no change; developers are not going to stay around if their activity is reduced entirely to bug-fixes.

So what is the solution? Introducing changes at a slower rate, so that users are not overwhelmed? Involving users more closely with the development process or communicating goals more clearly?

Large FOSS projects take note: Not only can you no longer assume that users will accept change. You may need to learn to live with the fact that many users will actively resist it, and will respond to it in the most adversarial way possible. Ignore that possibility, and you may find your project mired in the same morass in which KDE now finds itself.