Lock in

In economics, vendor lock-in, also known as proprietary lock-in, or more simply, lock-in, is a situation in which a customer is dependent on a vendor for products and services and cannot move to another vendor without substantial costs, real and/or perceived. By the creation of these costs to the customer, lock-in favors the company (vendor) at the expense of the consumer. Lock in costs create a barrier to entry in a market that if great enough to result in an effective monopoly, may result in antitrust actions from the relevant authorities (the FTC in the US).

It is often used in the computer industry to describe the effects of a lack of compatibility between different systems. Different companies, or a single company, may create different versions of the same system architecture that cannot interoperate. Manufacturers may design their products so that replacement parts or add-on enhancements must be purchased from the same manufacturer, rather than from a third party (connector conspiracy). The purpose is to make it difficult for users to switch to competing systems. Examples include the various EBCDIC character sets by IBM, the several slightly different implementations of various open standards, the many variations of Unix, Microsoft Office's file formats, and also Microsoft's software in general.

Lock-in may eventually also be damaging to the company or industry in question. In the UNIX wars, various Unix vendors battled so hard to lock their customers into their version of Unix that the entire Unix market was seriously affected.

One way to create artificial lock-in for items without it is to create loyalty schemes. For example, frequent flyer miles that can only be used with one airline create a perceived cost of switching airlines.

The Microsoft example

Microsoft software carries a high level of vendor lock-in, based on its extensive set of proprietary APIs.

The European Commission, in its report on Microsoft's business practices, quotes Microsoft general manager for C++ development Aaron Contorer as stating in an internal Microsoft report for senior management:

"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...

"It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO [total cost of ownership], our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago."

Combating vendor lock-in

In the 80s and 90s, public, royalty-free standards were hailed as the best solution to vendor lock-in. The weakness of such standards was that if one software vendor achieved a dominant market share, "embrace, extend and extinguish" (EEE) tactics could be used to obsolete the standard.

Since the late nineties, the use of open source/free software (FOSS) has been pushed as a stronger solution. Because FOSS software can be modified and distributed by anyone, the availability of functionality cannot tie a user to one distributor. Also, FOSS tends to cling to standards. The ineffectiveness of distributor lock-in means there's no incentive for FOSS developers to invent new data formats if usable (royalty-free) standards exist.

In particular, copylefted FOSS is particularly resistant to the above mentioned "EEE" tactics since anyone distributing modified versions must also distribute the source code to their modifications.

As of 2004, IBM is promoting and contributing to the development of certain FOSS projects to weaken the market dominance of competitors such as Microsoft. This is interesting, not only because IBM was once one of the biggest users of the vendor lock-in tactic, but also because IBM is simultaneously funding and promoting software patentability and "trusted computing", the two biggest impediments to FOSS development.

See also

• Network effect
• Embrace, extend and extinguish
• Vendor lock-out