Every time someone dares to mention Linux suffers from some unnecessary fragmentation, someone eventually appears claiming Linux is all about choice. “Choice is what makes Linux better” or any number of equivalent statements. We could even dare to formulate Godwin’s law open source analogue: As an online discussion involving Linux grows longer, the probability of someone stating Linux is all about choice approaches 1.

Let’s start by dissipating a common misconception.

Freedom and choice are not synonyms

A slave given two choices for who will become his master isn’t more free than a slave with a single choice. When the FOSS community talks about free software they’re not advocating more choice. In fact, the word choice isn’t even mentioned in the definition of FOSS:

1. The freedom to run the program, for any purpose.
2. The freedom to study how the program works, and change it so it does your computing as you wish.
3. The freedom to redistribute copies so you can help your neighbor.
4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes.

A universe with a single piece of software that complies with the conditions given above would be a freer universe than a universe with an infinite number of propietary programs and no FOSS programs. Having clear that out, let’s continue.

More choices are not always free (as in beer)

Let’s imagine two sets. You’re given the choice between the two sets. The first set has 4 choices of cars and the second one has 8 different choices of cars, including the cars from the first one. From which set would you rather choose? Obviously the second one. The advantages of more choice over less choice are usually presented in a similar fashion, in a way in which the bigger set of choices has no disadvantage whatsoever over the smaller one.

In the real world with its finite resources, finite programmers, finite time, finite number of users, limited everything, a bigger set of choices has drawbacks. Eight programmers working constantly for months in a single application can produce a much better application than any of them can code individually. So there’s a trade-off, if everyone of the eight programmers work individually there’s more choice, but every single one of those options are inferior to the one in the single choice case.

Take another market, say, the smartphone market. This market has many hardware choices, is the smartphone market all about choice then? Of course not.

More choices are not always a zero sum game either

Are people justified when they criticize a company for “losing time” changing or doing something that is perceived as useless or a waste ? Yes. Companies have finite resources, so they need to prioritize their investments, but that’s only relevant internally for the company. When there’s no central planning or and stuff is done a hundred percent voluntarily or there’s no company that controls the entire extension of the choices, things can become quite more complicated. A programmer may be willing to invest his free time on creating a new music player but not on something else that is perhaps more needed: This is a case in which the set of choices expands for “free”. We can manufacture a definition to express this more adequately:

An increase in choice is locally free if introducing more options doesn’t take resources and time away from the alternatives, otherwise we say is locally costly.

Say you want to create a new torrent client and you’re not willing to spend your time contributing to current projects (for example, because your ideas about how the interface should be are entirely different, or simply because you want you do your own thing). The resources and time available to developers of current torrent applications are not affected by this. Therefore the expansion of choices you would cause with your piece of hypothetical software would be locally free. In the other hand, if half the developers of the Linux kernel decided to create their own that would be locally costly.

The unintended consequences of more choices

Even when you’re dealing with “free” expansions of choice, they still can prove to be costly for other projects. It’s a bit like economic externalities. It works like this: If there’s multiple choices of a kind of software then other programmers may have to offer support for all of them, costing them time and resources. Therefore, an expansion that may appear free can turn out to be very expensive. Let’s be a bit more analytic, we can create yet another pair of categories:

An increase in choice is externally free if introducing more options doesn’t take any significant amount of time and resources away from other unrelated projects (i.e. projects that are not an alternative to the piece of software in question). Otherwise we say is externally costly.

Since torrents are standardized, the new torrent application probably wouldn’t impose any significant cost to other projects, so it would be externally free. Because hardware manufacturers would need to write new drivers for the new kernel, and many developers would need to port their code, the new kernel by the former Linux developers (if successful) would be externally costly.

In fact, let’s say the cost of supporting a project A is C(A)=a (read as the cost of supporting A is a). Now, let’s say we get an increase in choice that is externally costly, the project B. The cost of supporting B alone is C(B)=b. You may intuitively think the cost of supporting both is necessarily C(A&B)=a+b, but you would be wrong. For example, now you may need to create and support a piece of code to switch between A and B, which is not included in the cost of supporting either of them alone (think of the choice between multimedia frameworks, Xine or GStreamer), so more often than not C(A&B)>a+b.

In the modern world of desktop operating systems almost nothing is absolutely externally free (hence, the “any significant cost” instead of “no cost” in the previous definition). If the new client becomes more popular than KTorrent, Plasma developers may need to create a way to integrate it into the notifications widget, imposing a cost to them even if is not a significant one. However, this sort of issue is often reduced. In the real world mechanisms have been put into place to reduce external costs.

Freedom doesn’t imply no planning

Big projects need order and good code doesn’t just happen magically. You need planing and a well designed structure to manage all changes to the code, reject and accept patches, feature requests and more. FOSS projects have all kind of government structures ranging from what is commonly known as benevolent dictatorships for life to open source democracies. If you want to know a bit more about open source governance you can check our article on the matter.

Cost and benefit analysis 

Since expansions of choice are not often locally and externally free, cost and benefit analysis ought to be a major part of software development and in the introduction of alternatives. Also rather counter-intuitively external costs are way more important than local costs, after all locals costs are limited in scope. An expansion of choice may be locally free but disastrous externally, it may even destroy an entire ecosystem (the economic analogue would be the climate change caused by dumping greenhouse gases into the atmosphere: it may end up costing us a lot of resources or perhaps even our extinction).

For example, there was plenty of discussion and planning involved in intended switch of display managers, from X to Wayland. Why? It was not about the local cost, it was all about it being very externally costly. All Linux toolkits, window managers, desktop environment, hardware manufacturers, among many other need to change their code to add support for Wayland. As such, they had to be very careful and make the sure the benefits of switching to Wayland were worth the cost imposed on all other developers.

Standards 

When entire markets and ecosystems try to set standards is because they wish to reduce the cost of supporting too many different things. For instance, instead of Plasma’s developers coding something specifically to support your new torrent client they offer an API so any developer can plug into it and become integrated to KDE’s notifications. This is also helps reduce local costs by avoiding duplication.

In other words, standards are a way to create an ecosystem with the highest degree of choice for the cheapest cost possible. Choice is often related with the concept of competition, but I believe cooperation is way more important than competition has ever been (and therefore, I think cooperation trumps just a big number alternatives). If projects were just competing against each other they may end up committing suicide (as if often the case in markets) by being externally costly on purpose as a way to compete and beat the alternatives (by forcing the rest to choose only one of them). By getting together and creating a standard projects are avoiding dumb competition, reducing duplication (local and internal costs) and above everything external costs.

Is not about limiting the freedom of users

Remember, free software has nothing to do with choice. Therefore, when the community creates a standard or chooses to ignore the program from some or other group of developers they’re doing so because they don’t think the cost of supporting it is worth the benefits of supporting it. Not because they don’t want users to be able to choose. More choice would be externally too costly and the user would be in a situation in which users have more choice regarding a specific type of program but everything else would being degraded in quality (and probably even number). I.e. They think is a waste of time and resources.

Users are not the ones in a position to decide if it’s a waste of time or not. They get choose among the options a group or another of developers thought was worth investing time in. In things like display managers, not even that. Most users don’t know what a display manager does or doesn’t do, let alone the technical merits of one or the other. They don’t even choose their display manager, it is handed to them, bundled with a bunch of other stuff they want and depend on a functional display manager.

In other words, all these decisions are up to developers. In fact, the only reason you’ve seen the controversy regarding Linux display managers is because it’s a discussion held in public. Microsoft and Apple surely had to develop and plan their own display managers for Windows and Mac OS X. I’m sure there were frictions and discussions internally. But it would’ve been senseless for any of them to ship with two different display managers that would force developers (internally and externally) to spend more than twice the effort, money and time (recall that C(A&B)≥a+b).

Conclusions

If I was able to communicate myself clearly, perhaps the next time someone says “Linux is all about choice” you will know he’s confused. FOSS is about the four conditions described at the beginning and Linux is about making the best possible operating system (with as many FOSS software as possible). None of this has anything to do with maximizing the number of choices. Worse yet: Increasing choices can get in the way of achieving it, it can be detrimental. Only locally and externally free new choices need little to no planning. Increases in choice in key parts always have to be planned and as much as possible be built on top of standards to reduce costs and ensure the ecosystem stay healthy and functional. No one benefits from the worship of choices for the sake of choices, not developers, not users, not Linux, not the FOSS movement.