The Limits of Linux's 'Live Free or Die'

Because of this, software companies who don’t primarily deal in open source have shunned Linux. It’s something of a chicken-and-egg argument to say who shunned whom first. And perhaps it’s academic: does it matter who took the first step away from the table?

Still, here’s the key problem: There’ll always be a big gap between Linux advocacy and Linux reality as long as it remains biased toward the near-complete exclusion of binary-only / closed-source / proprietary software on Linux.

Binary blowout

The simplest and most obvious sign of how Linux’s open-only stance has played out in the real world is the sheer lack of binary-only software available for the platform. Not just applications, but device drivers, support tools—the whole gamut of things people take for granted in other places.

This isn’t to say that binary-only items don’t exist—just that they’re few and far between. And that Linux as a whole, both as an ecosystem and as a community, is biased against such things.

The ecosystem part is mostly logistics. People who try to supply binary-only apps or drivers for Linux quickly discover that it involves a great deal of work. This is because there’s no “Linux” generally—there’s a slew of distributions, a slew of kernel revisions, all subtly incompatible with each other on a binary level.

Last year I talked to a company (I won’t name them here) whose main business was on Windows. They have been putting out a binary-only Linux version of one of their main product for some time now. They admitted that the Linux versions lagged behind their Windows brethren because of the sheer effort involved in getting a binary-only app to behave properly across the major distributions they had targeted.

Worse, they had to think about each kernel revision within those distributions, going back about three or four iterations. This effectively makes them custodians of a dozen or more different editions of the same app for one platform. (The Windows version runs generically on all versions of Windows from 2000/XP forward.)

So additional effort is required to just make the apps do something that comes naturally on other platforms. For people who haven’t grown up with this as a way of life, it’s exhausting. It forces the manufacturer to support that many more separate editions of a single product. (I’m not sure this is what Linux advocates had in mind when they said the future of commercial software was in selling support and services.)

The few programs out there that have binary Linux editions—binary-only Oracle, for instance, or the Opera browser—are typically backed by major corporate muscle. And without big corporate cash, deploying something like Oracle—or even a program a fraction of its size—across multiple Linux distributions is so difficult that most companies either significantly narrow their focus or simply don’t try.

This is especially true if the program in question and Linux’s current target market (which is mainly servers) aren’t even congruent.

Live free or die?

A constant sentiment among some Linux advocates is that it’s best for Linux as a whole to reject closed-source drivers and software. To compromise on this issue means Linux runs the risk of falling into the hands of entities that can exert control over it.

Some of this fear is justified, especially in a software world that’s mulling the future of Sun and MySQL with increasing gloom (even if those things are largely the product of miscalculation on the parts of Sun and MySQL). But it’s not clear that all of Linux’s source-is-best stance is wholly a protective gesture to guard against the profit-only crowd.

More often than not, this stance is invoked to embody the concept that in five years, or maybe a decade (the exact time depends on the speaker), all software will be open source. And that the money to be made from this stuff will be from services and support, not software itself. Some even say that hardware will have its costs subsidized through support and be essentially free to own upfront.

It’s tempting to believe this is possible, especially when high-quality open source replacements for many commodity apps exist. But that requires ignoring all the high quality proprietary apps that show no sign of being replaced by open source equivalents.

A commonly-cited example is Photoshop. It can’t be replaced with open source in professional environments due to lack of support for patented products like Pantone. Graphics professionals aren’t going to wait with arms folded for those patents to expire—they’ve got work to do. They’re more than willing to pay money for a quality product, proprietary or not, that lets them do it. Pretending these things don’t exist, or trying to upend them by attacking the patent system, accomplishes nothing.

As for hardware costs being subsidized by support, I can only assume that argument is based on observations of the phone market. To assume what goes for phones will be what goes for computing hardware generally is not to think at all. The economy of phones is tied to the economy of the phone network, which couldn’t be more unalike the way, say, servers and the Internet at large work.

It holds even less water when you realize most people would be happy to use commodity devices like tablets or netbooks on cell networks … if only the network gatekeepers would let them.

The costs of freedom

So what are the end results of an insistence on open-only for Linux?

Mainly, it’s meant that Linux has had great trouble thriving in areas where the conveniences of proprietary software are taken for granted. The commodity desktop is the biggest example, where Linux remains a statistical blip or an occasional curiosity, instead of a strategically powerful alternative on the order of the Macintosh (or even the iPhone).