Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Does free software offer too many choices?
In the last dozen years, the question has been revived more often than the Daleks on Doctor Who. If the community could only agree to standardize on applications, deadlines, and options, the argument goes, then world domination would be within reach.
The latest version of this argument is Graham Morrison’s article, “The trouble with Linux: There’s too much choice.” Morrison writes that the amount of choice is “often overwhelming, needlessly complicated and an easy excuse for change. Choice goes hand-in-hand with redundancy and duplicated effort.”
Morrison goes on to suggest that, on the one hand, if the community doesn’t make a decision to standardize, then it will lose the choice because others — presumably, businesses and distros — will make the choice for them. On the other hand, by giving up a little unnecessary choice, “we’ll have gained a whole lot more choice where it’s important: the freedom to run secure, safe and supported software on whatever platform we choose.”
Essentially, Morrison says nothing new. Perhaps he does not need to, because, superficially, this argument makes sense. If you are a developer new to free software, you may be unaware of the open standards or the hooks into kernel space that provide an underlying unity.
Similarly, if you are an executive trying to make strategic decisions, you may be overwhelmed by the number of distributions and wonder how you can possibly support them all. In the same way, faced with choices where Windows offer none, a casual user may suffer option anxiety, and become paralyzed by indecision. So why not make everyone more comfortable and simplify everything?
The only trouble is, this criticism fails to take into account the structure of the free software community, to say nothing of the reason for its existence. As sensible as the suggestions may seem, they aren’t about to adopted — not to any degree, and not by the community as a whole.
Choice First
Probably the argument that Morrison revives is echoed at one time or other by every user of free software. When you see yet another plan to develop a music player or desktop, the chances are that you entertain the fleeting thought that the projects are a waste of time. Almost immediately, though, the thought is usually followed by a shrug and an acknowledgement that people are free to do whatever they please.
The fact is, there is not much interest in strategic efficiency in free software (tactical efficiency, in the form of well-written software, is another matter entirely). If there were, then the logic of Morrison’s argument would have been followed long ago.
But the interest is so small that, when Ubuntu’s Mark Shuttleworth called for the relatively minor goal of standardizing project release dates, the silence was deafening. Debian, Ubuntu’s parent distro, made some vague noises about having regular releases, and that was about the strongest response. Nor, in practice, has Debian been able to carry out its intention.
No one rejects standardization absolutely. In the abstract, many might even say it is a good idea. Yet it seems that no one judges it a high enough priority to make any focused effort to achieve it.
For all the attention that free software has paid in recent years to usability, it remains a developer-centered community. And while developers appreciate a usable interface as much as an ordinary office drone does, what most of them want in an interface is the ability to do things their own way. And, unsurprisingly, this preference makes its way into the code they write.
Even among non-coders like me, you aren’t going to hear too many complaints about an over abundance of choice. After all, most people who use free software regularly are fleeing a lack of choice in Windows or OS X. The whole reason for free operating systems like Linux is to offer alternatives, which is why calls like Morrison’s or Shuttleworth’s consistently fall on uncaring ears.
It is not just a case, as Caitlyn Martin points out in her response to Morrison that, except for a momentary initial confusion, no one is intimidated by the number of choices in the breakfast cereal aisle at the supermarket.
The analogy is accurate, so far as it goes, but, in the case of free software enthusiasts, it is probably only part of the reason so few care about standardization. An even greater reason is that, for many members of the community, reducing choices feels vaguely wrong.
For instance, it is no accident that some of the strongest complaints when KDE 4.0 was released were that it has fewer options than its predecessors. In most community members’ minds, the assumption is that each release will offer more choices, not less, so the work-in-progress that was KDE 4.0 seemed a violation of the natural order.
Even more importantly, I suspect, users expressed their dis-satisfaction with the worst insult they could find. Often, it took the form of saying that KDE had become too much like Windows or OS X — meaning that choice had arbitrarily snatched from users’ hands, and that developers had decided that they were more qualified to decide what was best for users than the users themselves were.
Morrison is right, of course, that in the absence of standardization, distributions have to decide what applications are included in their default installations. However, contrary to his assertion, such a decision does not limit freedom for users.
Not only are alternatives available in each distribution’s repositories, but if a user dislikes the defaults in one distribution, they can easily switch to another one. Unlike Microsoft or Apple operating systems, a free software distribution, even if it is sold commercially, places very few limits on choice. Their defaults remain a purely local phenomenon, and do next to nothing to reduce the availability of choice.
In fact, because choice is valued so highly, free software developers go to considerable lengths to assure it. I doubt it is any coincidence that the main emphasis in releases after KDE 4.0 was to restore most of the choices that users were afraid they had lost.
Similarly, when KDE offered a new menu or new layout for System Settings, its developers were careful to give users the option of using the old ones.
A dichotomy between standardization and choice is probably false. They are not natural opposites, and both can be useful. And, in general, free software projects see enough value in standardization that their members frequently talk to contributors to other projects and look for ways to improve interoperability. But such interaction is just a way to increase choice — for instance, to let users run a GNOME app more easily on the KDE desktop if that is what they want.
Forced to decide between standardization and choice, the average community member, I suspect, will support choice every time. Yes, choice is inefficient — but it is also a lot more fun than standardization can ever hope to be.
The Impossibility of Implementation
The arguments to reduce choice seem to have logic on their side. However, if the theory were accepted — which it obviously is not — the practice would be impossible.
At first, you might think that the choices would be obvious. For instance, OpenOffice.org is the most fully-featured office suite, so you might support it as the new standard. But what if someone else values speed instead? Then AbiWord or KOffice would be the application to support.
The decision can change drastically with the criterion. But if you allow too many different criterion, then standardization is either weakened or becomes self-defeating.
In cases where the differences are smaller, the situation is even worse. What argument could — or should — convince developers of GNOME to support KDE, or those of RhythmBox to abandon their efforts in favor of Amarok? Umbrella organizations like the Linux Foundation or the Free Software Foundation coordinate, but they have no power to compel, and no prospect of ever being able to do so, even if they wanted to. Get rival projects together, and the result would be a stalemate.
Undoubtedly, there would be advantages to standardization. But, equally, undoubtedly, it’s not going to happen. And if by some unlikely chance it did, then free software would cease to be free software. For better or worse, the messiness of choice is what free software is all about.
