Dependence on a particular vendor's technology which makes it difficult or expensive to use products from another vendor (whether replacement products, or products which answer different needs). Lock-in is usually enforced through a proprietary interface of some sort, protected by either trade secrecy or IntellectualProperty
laws (patents mainly; though copyrights can impose a barrier as well).
It is often alleged that certain vendors (MicroSoft
being one, Apple being another) spend a considerable amount of effort designing VendorLockIn
s into their products. (MS, for instance, went out of its way to make NetscapeNavigator
function poorly on recent versions of the WindowsOperatingSystem?
). Many VendorLockIn
s arise by happenstance or accident (any file format, API, etc. which isn't fully and publicly specified is a potential source of lock-in).
One particularly notorious method of VendorLockIn
occurs when the company creates a popular product which uses an open standard, then uses the leverage created by the product's popularity to add proprietary extensions to the standard. It is important to differentiate between semi-innocent addition and adding to the standard with the itent of causing VendorLockIn
. The former is a combination of the natural evolution of information and cultural carryover from a company which is not used to the open standards process; the latter process is often called EmbraceAndExtend
- Printer manufacturers often embed ICs in ink cartridges whose sole purpose is to verify that they are an "official" cartridge (advanced cryptographic protocols are used for this purpose); the printer will refuse to use any cartridge that lacks the IC. One printer manufacturer (Lexmark?) recently sued an aftermarket ink cartridge manufacturer for reverse-engineering its lock-out technology (claiming copyright infringement); I believe the printer manufacturer lost the case. (Anyone recall the details?) (See here: http://www.geek.com/news/geeknews/2004Oct/gee20041028027613.htm)
Try this: Get a super cheap Epson printer
at Frye's. Run it for two years, and notice a curious fact: The printer cartridges hold about 3 thimble-fulls, and the cumulative cost of the ink exceeds that of the printer. That's why it was cheap, and they could afford to keep a sales representative on the floor hawking them.
Oh, and the stupid thing can't print black-and-white only if the color cartridges are not filled. Brilliant.
Next, the ink cartridges have chips in them, so aftermarket cartridges sometimes work and sometimes don't. The final straw came when the printer refused to use an Epson cartridge.
We went back to Frye's, and get sales help without a non-Frye's badge. They direct us to a wall, far from the high-end printers, where they lined up the business workhorse printers. We got a laserjet - Samsung - not an inkjet, and we made the sales representative show us the huge ink cartridges.
Bottom line: Never get an Epson again. Too many games played at our expense.
One person's lock in is another person's nifty, valuable feature. Use Oracle for shredding XML? Whoops, you're "locked in". Want to use BEA's .jpf files for Page flow in a web app? It's nicer than Struts, but boom! you're locked in. Do you care? Maybe not.
As someone else pointed out, lock in is not a binary thing, it is a continuum. Lock-in is best quantified by "how much does it cost to switch vendors?" The importance of lock-in is this quantity multiplied by the likelihood that you will have to move.
So when you buy an Oracle database
, Oracle-centric tools (not necessarily from Oracle, like maybe TOAD), train your people on Oracle, and build your apps to exploit Oracle features.... all of this implies that if you were to switch from Oracle DB, there is a price you will pay. But what is the chance you will need to move? Want to move? The price might be in the millions of $USD, but totally irrelevant if Oracle is delivering what you need.
You could do it all in MySQL but what is the cost of the effort involved in doing it all yourself?
The worst cases of Lock-in were found in the Unix/HW wars, when DEC, Wang, Prime, Data General, Stratus, and so many other companies built their own HW and own OS. None of them reached critical mass, and so some customers were stranded by either the unavailability of talent, or the high cost of equipment or software, or the complete unavailability of hardware due to cessation of the company. This defined the "lock in" problem. Nothing so extreme, IMO, has been seen since.
Betting on a viable company that is fairly certain to not disappear or be swallowed, is a good strategy for avoiding the costs of lock-in. Another good strategy is not committing to anything that is not a commodity. These two are generally opposing alternatives; you need only one to effectively mitigate the risks of lock-in.
Turning to current events, the jury is still out on the Oracle and Peoplesoft situation -- the two just signed a definitive merger agreement as I write this. Peoplesoft
looked to have been a viable and stable apps vendor, now they have been swallowed. It remains to be seen whether current Peoplesoft customers will be stung by lock-in costs, or if Oracle will extend long-term support to them to mitigate this. -- DinoChiesa
, December 2004
Returning to current events (2009), the entire global economy is in collapse. No vendor is "fairly certain to not disappear or be swallowed." Still think that accepting lock-in is a good strategy?
One of the most painful kinds of switch is from one database to another -- see DatabaseVendorLock
And another is switching from one version control system to another. Especially when the vendor doesn't even provide an upgrade route to new versions of the same product.
If I put a lot of effort into transparency layers, etc., to avoid vendor lock in, then if I never actually switch, all that effort is wasted.
On the other hand, if I don't bother with any of that effort, then if I ever do need to switch, it really stings.
Tough choice -- but DecisionMathAndYagni
can help make and document the choice, so no matter what happens you won't feel guilty about making the "wrong" choice. Don't for get to include FutureDiscounting
. It is an important factor.
You also need to consider whether to work with the "lowest common denominator" of features across vendors vs. taking advantage of the features offered by one vendor while knowing you'll probably need to implement those features in a program layer, later, if you ever wish to port to another vendor.