Theory of competition fails in open source, elsewhere

Monopoly is a dreaded word for the open-source community, so why are we as prone as anyone else to embrace natural monopolies?

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
2 min read

The natural state of a market doesn't appear to be broad competition between Lilliputian-sized competitors. Rather, markets tend to crystallize around a few dominant players.

Ironically, this is as true of open source as it is of proprietary software.

In September I asked if open source can monopolize a market. ZDNet's Dana Blankenhorn and others gave great feedback, but the market since then has provided the best evidence:

Yes, we can have an open-source monopoly (at least, a natural monopoly). In fact, this may actually be the normal state of a healthy open-source market.

If we think of markets broadly, e.g., the "e-mail/messaging market," we're unlikely to have open source dominate such a market in the near term, though with Linux, Firefox, and other open-source projects gaining momentum, full market monopoly may not be too far off.

If we constrain a market to just open-source competitors, however, we're already there.

Within the open-source market, Red Hat dominates Linux. Firefox dominates browsers. VLC dominates media players. MySQL dominates databases. Android dominates mobile operating systems. SugarCRM dominates CRM. And so on.

Name the market, and you're almost certainly going to come up with just one dominant open-source project or vendor. There are exceptions, of course: Drupal and Joomla duke it out over supremacy in Web content management. We'll call them a duopoly. But these exceptions prove the rule:

Open source loves a monopoly.

This shouldn't be surprising. While the theory of unfettered competition sounds great, it's actually hard for mere mortals to process.

For example, when I walk into a grocery store, I don't want 30,000 cereals competing to be my morning meal. I want just a few. (Ever notice that the same cereals sold when you were a kid persist on those store shelves? We don't seem to want much competition over time, either.)

It is convenient for open source to think itself different, and to rally the troops against "Darth Vaders of IT." But that's all it is: convenient. A convenient fiction that makes us feel that this time it will be different, that this time it's all about kumbaya and the customer.

The customer doesn't want 50 vendors providing support for one open-source project. It wants to invest in Red Hat, Canonical, or Novell, and probably just one of those. It wants Android or Symbian, MySQL, or Postgres. And so on.

Manageable choice. Choice that starts to look an awful lot like monopoly. It's not that customers want to have a market dominated by a single vendor. It's just that they'd rather have a limited choice of a few good vendors, rather than an unwieldy choice between scads of competing vendors.

The difference is code transparency, process transparency, data transparency, standards transparency, and so on. This lets customers buy into a limited choice, but have a more open option for exiting that choice. It's a distinction that is more meaningful in theory than in practice, but it's still worth something.

Just not as much as we thought.