Vendor Lock In
Vendor Lock InDependence 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 VendorLockIns into their products. (MS, for instance, went out of its way to make NetscapeNavigator function poorly on recent versions of the WindowsOperatingSystem?). Many VendorLockIns 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.
Other examples:
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 for details.
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.
See also:
EditText of this page
(last edited August 14, 2010)
or FindPage with title or text search