posted by David Adams on Wed 29th Jun 2005 14:57 UTC
IconFans of just about anything alternative all seem to suffer from a similar affliction: a nave underestimation of the pains of switching. This goes for U.S. fans of the metric system, alternative fuel proponents, vegetarians, and yes, OS fanatics. Now, personally I'm all for a lot of those things I just mentioned, but as a lapsed vegetarian, I know full well how, despite the advantages of the alternative, sometimes it's hard to switch and easy to go back.

Rather than try to mention all the reasons why it's hard for an alternative OS to make it in the marketplace, I'd like to focus on one of the main obstacles to embracing an emerging platform: vendor lock-in. in essence, in the software world, vendor lock-in is when a customer is dependent on a particular vendor's product, and the costs of switching from that product are prohibitively high. Cost of switching may be kept high by various means, but most of them focus on a lack of compatibility or interoperability, often intentional.

Data Formats

One of the classic tricks in the software industry is to keep a lid on data formats to promote lock-in. Customers will happily input and import data into a system, but find that exporting the data back out is very difficult, if not impossible.

In desktop applications, companies do this with document file formats. Users create a library of files that are only readable by the vendor's application, resulting in platform lock-in. There's another twist on file formats too: if you change the formats to not be backward compatible with older versions of the software, you may be forced to upgrade if you work in an industry that shares a lot of files, because when people start sending you files based on the new version, you will need to upgrade to read them.

This tactic rears its head in the OS marketplace when often-exchanged files such as documents and media files are saved in proprietary formats that are not readable on an alternative platform. Over time, ingenuity often wins out, as Mac and Linux machines can now display most files for Windows applications, but it's a constant struggle.

Thankfully, most customers will not stand for such user-unfriendly tactics, so most software today offers some mechanism for exporting to interoperable formats, though in most cases you lose some of the special software features in the export.

Those special features are a corollary to the data format method of lock-in. A perfectly legitimate form of "soft" lock-in is for an application vendor to be constantly introducing new functionality into their programs that are reflected in the saved files. Old versions of the software and competing applications will not be able to read the data because they don't offer the functionality. In this case, the users are locked in if they use those features. Microsoft and Adobe are especially adept at this method, but it can be good for the users because the software gets more and more feature-rich. Of course, a lot of this functionality ends up being gratuitous, and results in merely a more bloated install, and more complicated user interface. Application vendors walk a fine line when attempting this "soft" lock-in.


A European Commission report on Microsoft's business practices quotes a Microsoft executive in an internal memo, cited in Wikipedia: "The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead." In other words, it's easy to write software that's intimately tied to the Windows OS, and takes more effort to write more-portable software; therefore, much of the software out there would require extensive rewriting to work on another platform.

And this does not just apply to off-the-shelf software that you might want to use. Most of the software written in this world is never sold to anyone. It's written for in-house consumption. So if a particular company has written some custom software (and they have the source code and the skills necessary to port it) they may have relied so heavily on the Windows APIs while writing it that it would be prohibitively expensive to port it. And in-house software is more likely to have been written using this quick-and-dirty method, precisely because it's meant for in-house use.

Of course, offering great developer tools and a deep and wide API isn't evil. I'd venture to say that the developers for every platform want the best tools and the most developer-friendly hooks possible. It makes their job easier. But it also takes a massive expenditure of resources on the part of the OS vendor to make that possible. If a great API weren't an effective anti-competitive tool, I wonder if Microsoft would have made it such a priority.

Table of contents
  1. "Page 1"
  2. "Page 2"
  3. "Page 3"
  4. "Page 4"
e p (0)    57 Comment(s)

Technology White Papers

See More