Linux.com

How Many Other Cases of Lock-In on Linux?

Posted by: Anonymous Coward on April 26, 2005 05:05 PM
How many other cases are there where Linux users and developers are being locked in? And are they even aware of it?

It is pretty much accepted that you can't be locked in if you use Open Source software, and open standards. The ability to fork ensures that a supplier who misbehaves can be replaced.

But, running on Linux will not keep you free if you allow yourself to be locked in by other proprietary components, such as applications, drivers, and protocols (APIs, Object Models, Comms, etc.).

I'm not so worried about simple lock-in, such as when someone uses a proprietary application. In such cases, the user knows what he or she is getting into, and that it may be necessary to change applications in the future.

Rather, the thing that worries me is Network-Effect Lock-In.

Network-Effect Lock-In occurs when users and developers are tied to each other by a common piece of proprietary middleware (an application, a driver, a communications protocol, etc.).

With Network-Effect Lock-In, the users find it difficult to get out, because they are dependent on multiple products (and multiple developers) that use the same proprietary middleware.

Likewise, the developers find it difficult to get out, because all their users are tied to the same proprietary middleware, not to mention any requirements for compatibility with other products based on that middleware.

A good example of Network-Effect Lock-In is Windows, where the users and developers are all dependent on the same proprietary middleware, namely, the Windows APIs.

Looking at Linux, are there examples of proprietary middleware that are creating Network-Effect Lock-In?

The answer is yes. The examples are numerous, and their use is growing more widespread.

Here are some that I can think of, off the top of my head:

- NVidia's and ATI's proprietary hardware drivers.

- MySQL, when used under its non-GPL license.

- Qt, when used under its non-GPL license.

- Wine, when used under its non-GPL license.

- Proprietary codecs for audio and video.

- RealMedia and its protocols.

- Flash and its protocols.

-<nobr> <wbr></nobr>.Net and its protocols (e.g. Trolltech built a<nobr> <wbr></nobr>.Net interface into Qt).

- Various other semi-proprietary protocols, such as SMB (Samba), the Qt APIs and Object Model (Qt),<nobr> <wbr></nobr>.Net (Mono), and so on.

- Various proprietary install procedures, such as those used by Linspire, or Xandros.

- And so on.

As Linux gains more casual users, the tendency to compromise on Open Source (or Free Software, in deference to RMS) principles is growing. This results in a growing use of, and acceptance of, proprietary middleware on Linux.

And that creates a threat.

Every piece of proprietary middleware in common use on Linux gives the owner of that middleware leverage.

How can that leverage be used? As we have seen in the past, say, with Windows, it can be used to dictate standards in favor of its owner; to give the owner's products a competitive advantage over others; or to expand the owner's leverage into other areas, such as applications, development standards, and ultimately the platform itself.

For example, what would happen today if Microsoft bought up NVidia, MySQL, Trolltech, and Macromedia? Would that be enough to guarantee the dominance of MS-Linux and<nobr> <wbr></nobr>.Net? Probably not.

What about five years from now, if we allow the continued encroachment on Linux by proprietary middleware?

It concerns me that more people are not speaking out on this. I would especially like to see some concern expressed by Free Software and Open Source leaders, such as RMS, ESR, Bruce Perens, and so on.

#

Return to The Ten Commandments of system administration, part I