Fog Creek Software
Discussion Board




Does "vendor lock-in" really exist?

Every so often someone ventures "lock in" as a problem of cost. Is it really? Can someone demonstrate a situation where some development project costs a company *more* money because they are "stuck" with a "locked in" platform?

Mind you, there might be a very credible one; I just can't think of it right now.

Philo

Philo
Saturday, August 16, 2003

TCO is so nebulous. Sitting around thinking about how life would be grand if our data wasn't locked into some system that costs too much to replace is like second guessing sports calls. Say 50 development projects over the next two years would cost $10,000 less per project if we used some other system, that comes out to $500,000. It could very well cost so much more to replace that system with new licensing, training and effort. I am always skeptical when Sales people tell us we will save millions over three years using their product, but in the end who's to know if the right decision was made? Do companies know how to calculate a true TCO?

m
Saturday, August 16, 2003

Well, I'll venture that I won't trust any company's computation of TCO if I've ever heard them utter the phrase "sunk cost"... [grin]

Philo

Philo
Saturday, August 16, 2003

The one thing I always warn people of doing is  throwing good money after bad. As some point one has to be willing to walk away from a project that has failed, and seek alternatives instead of buying more buckets to try and save the Titanic.

"Vendor lock in" is bandied about and seems to occur for a number of reasons, including ;

1. Inertia - not many folk want to change, and will generally resist totally new ideas.
- e.g. conversion from Imperial to Metric

2. My Turf - both from a new-tech will replace me or my skills as well as the more usual "current tech is my baby" so replacing it a a bad reflection on me.
- e.g. most tech projects in most companies

3. B*llShit experts, usually paid for by current bigCo, trying to explain away the competition and in effect raise the competitions prices in the eyes of the customers.
- e.g XYZ consultancy reports on Microsoft vs Linux

Ultimately though, people do see through the veneer and will abopt new techs.

A similar argument was prediction by some Experts that CDs would never take off because everyone had too much invested in tapes and vinyl.

Tapiwa
Saturday, August 16, 2003

Just a couple more things.

Anyone who has studies management accounting and investment theory will tell you that when you evaluate projects, think of what bang you will get per dollar spent from this point forward. How much went into whatever project is inconsequential. Managers just seem to forget it when they are protecting their turf.

I want to throw up every time expeerts come up with fantastic amounts for the costs of training. Folk aren't that dumb. Some aren't too brainy, but learning is not that difficult. I always start my training course with a variation of the quotation by Bruce Ediger "The only "intuitive" interface is the nipple. After that it's all learned." Its all about the attitude.

Microsoft was pretty good at fighting the Vendor lock-in FUD. I remember using Excel on Win 3.1 way back when. It had a Lotus 123 emulation mode of sorts... you could use Lotus style commands, and menus.

The only time I want to experience vendor lock-in is in my local pub!!

Tapiwa
Saturday, August 16, 2003

If you mean by vendor lock-in an inability to change platforms or products, no it does not exist.

What does exist is vendor incentive.  It is usually easier and cheaper to stay with what you have, although it may not be a better technical decision. 

This is what keeps Windows on the desktop and in the server room.

Mike
Saturday, August 16, 2003

If you (or your company) are ever in a situation where you would have chosen to migrate to a different database, hardware, operating system, compiler, application server, or web server but the cost of migration made you decide not to do it (despite the cost of acquisition being acceptable), then you have suffered from vendor lock-in.

Vendor lock-in exists, and costs companies huge amounts of money.  I have seen it all over the place.  A product that has an acquisition cost of near $0 (like Apache) can have its total acquistion cost rise into the millions because you are already locked in to another product.  Similarly, a product with a low acquisition cost can bite you for millions in a few years when you try to migrate away from it.

Most of those costs are the opportunity costs of not being able to switch to a more beneficial product or platform, since most companies will continue to use the old products (or upgrade to the latest supported version) rather than spend megabucks to rewrite and migrate.  But still, those opportunity costs are not trivial.

These costs often could be avoided if the systems built on the vendor's products were designed to avoid vendor-specific features or to encapsulate the use of the vendor-specific features within designated libraries (so they'd only have to rewrite the libraries, not the whole system).  But companies still let themselves get locked in because they only care about short-term results and marketing hype.

T. Norman
Saturday, August 16, 2003

T, you've *described* the standard "vendor lock-in" FUD, but I don't see a specific example.

Let's take LargeNonITCo as an example. They're 100% MS - VB, MSC++, SQL Server, Win2k.

How does "vendor lock-in" affect them? They have systems running. Either they want to design a new application/system, or upgrade an existing one. In either case, it's .Net/SQL vs. (for example) Java/Oracle.

Okay, given that they have x years of data in SQL Server, I would be hard-pressed to recommend moving to another database platform. But that recommendation applies to the next version of SQL Server, too. If the question is "SQL Server 2004 vs. Oracle" then I'd have to do a TCO analysis. Yes, their current SP's are in TSQL, but is there value in refactoring to a new back end?

Of course, with either vendor, the *code* is going to be rewritten from scratch, so MS doesn't get any kind of "lock" there.

Longhorn vs. Redhat? Debatable. Again, I'd have to do a TCO analysis based on their needs. I don't see MS getting an easy lock based on history here, either.

Most of these changes can be phased as well, if you're careful.

I see *some* benefit to staying with one vendor, but no way is it a "lock", IMHO.

Philo

Philo
Saturday, August 16, 2003

T. Norman - I like your description.

The question is: Is that really lock-in to the existing vender or investing into a future lock-in strategy? The company has presumably already paid to get into their current "mess".

To build a solution where any of the components can be swapped out as new, more advanced ones come into play is seldome a requirement companies are willing to pay for. Also, to not take advantage of vendor specifc functionality is wasting your investment in some cases.

m
Saturday, August 16, 2003

>"T, you've *described* the standard "vendor lock-in" FUD, but I don't see a specific example."

Mainframe applications are a prime example.  Some places are happy to keep running twenty-year-old mainframe systems -- no problem for them.  Others have a strong desire to get rid of the mainframe or even just to upgrade to a more modern mainframe but they can't because it would be so expensive to rewrite those millions of lines of code which even includes hardware-specific embedded assembler routines.  So they instead bear the cost and limitations of continuing to use the mainframe, because they are locked in.

Note that vendor lock-in isn't absolute.  No lock is unbreakable.  It's just that some can be expensive and time-consuming to break.

>"Let's take LargeNonITCo as an example. They're 100% MS - VB, MSC++, SQL Server, Win2k.
>How does "vendor lock-in" affect them? They have systems running. Either they want to design a new application/system, or upgrade an existing one."

They are locked in, but if they have no desire or requirement to migrate away from any of those solutions the lock-in won't cost them*. But if they ever have to move away from those platforms because Microsoft increased their licensing costs by 200%, or they need some sort of capability not supported by SQL Server, it would be very costly for them whether they decided to stay or migrate.

*As long as a significant portion of customers are locked in, the lock-in can also cost customers who didn't allow themselves to get locked in, because the vendors are able to keep prices high when they know most of their customers are locked in.

T. Norman
Saturday, August 16, 2003

>"To build a solution where any of the components can be swapped out as new, more advanced ones come into play is seldome a requirement companies are willing to pay for."

I agree.  But 5-10 years from now they'll pay for the cost of moving to a new system or suffer the opportunity costs of not being able to move.

>" Also, to not take advantage of vendor specifc functionality is wasting your investment in some cases."

True, but that should be weighed against the expected cost of lock-in, to determine whether the value of using vendor-specific features outweighs the costs of lock-in. And it often is possible to encapsulate vendor-specific stuff inside libraries.  But most don't care about taking either of those protective measures, since they won't suffer the costs of lock-in until years later.  Or they can deny that it exists, and people will believe them.

T. Norman
Saturday, August 16, 2003

"Mainframe applications are a prime example.  Some places are happy to keep running twenty-year-old mainframe systems -- no problem for them.  Others have a strong desire to get rid of the mainframe or even just to upgrade to a more modern mainframe but they can't because it would be so expensive to rewrite those millions of lines of code which even includes hardware-specific embedded assembler routines.  So they instead bear the cost and limitations of continuing to use the mainframe, because they are locked in."

Are you talking leased mainframe, or purchased?

If leased, then you have to do a TCO analysis - cost of continuing with the mainframe vs. cost of rewriting the functionality and porting the data. (Note: the crew at Camel made what I consider a critical mistake that in a rewrite, you start with the existing app. We kept trying to convince them down that path lay failure.)

If the mainframe is purchased, that's a sunk cost, and therefore a nonissue. Again, you do the TCO analysis of rebuilding vs. not.

Maybe I'm mistaken, but I've always thought "vendor lock-in" meant "if we choose Microsoft for this solution, then we have to stick with Microsoft forever" (including other projects and later versions). Now maybe the vendor behind the current solution has the edge, but I'm still not seeing any serious financial "lock" pinning the client to the vendor, except in the client's own mind.

Philo

Philo
Saturday, August 16, 2003

"If the mainframe is purchased, that's a sunk cost, and therefore a nonissue. Again, you do the TCO analysis of rebuilding vs. not."

What you already spent has nothing to do with lock-in.  It's how much you will have to spend to get off of it, if you ever have the need to get off of it.  If you do a TCO analysis and find that the cost of migrating dominates to the extent that you still wouldn't migrate if the new and superior product was given to you for free, then you are definitely locked in.

Don't migrate, and you suffer the opportunity cost of not being able to benefit from the added features/performance/reliability/maintainability or whatever aspect the new product does better.  Do migrate, and you pay the heavy cost of rewriting significant chunks of code.

T. Norman
Sunday, August 17, 2003

>'Maybe I'm mistaken, but I've always thought "vendor lock-in" meant "if we choose Microsoft for this solution, then we have to stick with Microsoft forever" (including other projects and later versions).'

That is what lock-in is about.  There are strong tendencies to stick with the same vendor forever, because the technical difficulties of changing vendors are prohibitively expensive.

>"Now maybe the vendor behind the current solution has the edge, but I'm still not seeing any serious financial "lock" pinning the client to the vendor, except in the client's own mind.'"

The locks are not imaginary, but they aren't unbreakable either.  Eventually, once the need to break away is strong enough, the client will pay the price and move to something else. But generally, they would have made the move much sooner if the technical "lock-in" forces were not present.

T. Norman
Sunday, August 17, 2003


If you're going to discuss vendor lock-in, then I think the scope should include more than Development projects.

One kind of lock-in is licensing revenue. As a business, you want to be able to predict future costs. Let's say you have a business-critical component which has two suppliers, and you are using one of them exclusively, and the cost of switching between the two is non-trivial. Then the vendor can charge you a price that's non-trivial as well ;), more concretely, the price can approach the cost of switching.

In the software world, an added complication is that the vendors can change the terms of the license as well.

Lock-ins (high cost of switching) are in the vendor's interest; multiple identical or nearly-identical suppliers (to minimize the cost of switching) are in the purchaser's interest.

Peter Breton
Sunday, August 17, 2003

Although vendor lock-in is used to describe modern software lock-in, I think the term arose in the days when choice of departmental computer dictated application software and everything else. That was real lock-in.


Sunday, August 17, 2003

Does vendor lock-in exist? Yes.
Is it as big a problem as it is made out to be? No

The is a Chinese proverb that says....
"Never charge someone more than the cost of getting you killed."

T. Norman, I would like to see a situation where the cost of an apache install ran into millions .... Skip specific web-apps, just the apache install running into millions.

I would postulate that in most situations where companies have found themselves locked into a vendor, the problem lies squarely with themselves.

If you build a custom big$$$ app using an obsure language that runs on obscure hardware, then you are in short, f*cked! The cost of switching to something else might be huge.  So when big$$co revises their pricing, and stops supporting the version you have, your choices are rather limited to something that costs less than the cost of killing big$$co.

If today you bought a train, and did not own the rail tracks, you are locked into the tracks vendor. You buy a car, and you are locked into the road vendors. Its a choices you make initially that determine the extent of your lock-in.

As interfaces become more and more alike, even on the desktop the costs of switching are not extraordinary. As more and more standards become entrenched, the cost of switching between competening products becomes smaller.

Businesses like revenue streams and costs that are predictable. Having said that, faced with a choice between paying big$$co, £1mill this year, and maybe more next year, or taking a £2 mill charge this year and free upgrades into the forseable future, I would argue that the latter choice is more desirable.

The only problem is that while it is a sounder business decision, it just makes you look bad in this current financial year, and that is a call that most managers are not willing to take. (Too much CYA).

Again, faced with a choice of scrapping big$$ investment, and spending $2 mill to do it right, and free after that, most managers will gladly pay £1mill a year into perpetuity. No one really wants to be associated with a project that failed and had to be scrapped. One that affords them a budget of $$ every year, makes them feel good (bigger empire), and means that they can still be wined, dined and schmoozed by suppliers.

I recall walking into a firm once (when I was working for a big$$ mgmt consultancy) and being appalled at the level of wastage because managers were protecting the  sizes of their empires, and because they were pals with the vendors that sold them big$$ products.  That and the fact that they seemed too lazy to explore alternative options (easier to wait for call from $$vendor who want to take you to lunch to discuss business) meant that the status quo was maintained.

From that point on, I take and TCO analyses by either a vendor, or entrenched management with a pinch of salt.

And this is where the big problem lies. When you eliminate the two groups above, it does not leave too many folk to consult for a truly objective view of how much it would really cost to "kill" that person who is currently charging you $x.

Instead of calling it vendor lock-in, I would split the issue into two.
1. Poor architecture and initial choices.
2. Complacancy and laziness

Tapiwa
Sunday, August 17, 2003

Here's an internal memo from Microsoft on their conversion of Hotmail from FreeBSD to Windows NT. They had apparently made two previous attempts to convert Hotmail before this.

The main reasons they were able to switch were that they didn't have to pay for the software, and Microsoft had recently bought Softway Systems and thus was able to use Interix to run their existing software on UNIX hosted on NT.

If Microsoft wasn't locked in to their own products (for political and marketing reasons) they wouldn't have needed to perform this conversion.

http://www.securityoffice.net/mssecrets/hotmail.html

The section marked "Problems with Windows" is most interesting.

Peter da Silva
Sunday, August 17, 2003

Some of their issues with Windows are pretty spurious. 

There's no reason why you can't write a console app and why that console app can't be accessed using a remote secure shell.

There is no compulsion to have a GUI.

Simon Lucy
Sunday, August 17, 2003

"There is no compulsion to have a GUI"

I'm pretty sure he was talking about the management tools already in Windows - User mgmt, routing, AD mgmt, etc.

Also consider that until .Net, writing a Windows service was a nontrivial matter, and if it wasn't a service, then it wasn't going to run on boot.

Philo

Philo
Sunday, August 17, 2003

Those issues were serious enough for Microsoft themselves to have problems with them. So I think it's a little flip to dismiss them as "spurious".

Anyway, the real point is that vendor lock in has to be taken seriously when Microsoft had enough problems porting an application to Windows that they ended up using an implementation of UNIX on top of Windows to do the job.

Peter da Silva
Sunday, August 17, 2003

Well I think you'll find it wasn't core Microsoft engineers that did the port but Hotmail people.

I don't see the problem in creating console administrative applications, if anything it seems easier than bolting on a UI to do the same thing.

And there's nothing specifically difficult about writing a service, what the service does might be tricky but constructing a service in itself isn't that much of a problem.

Simon Lucy
Monday, August 18, 2003

Is vendor lockin a problem? Yes.
Is there a solution? Mid term: no, since every vendor that does not succeed in locking in their customers in some way will be price predated out of business.

Just me (Sir to you)
Monday, August 18, 2003

>"T. Norman, I would like to see a situation where the cost of an apache install ran into millions .... Skip specific web-apps, just the apache install running into millions."

The cost of an Apache install won't run into the millions... but the cost of porting a large web-app to Apache that was built heavily on brand-specific web server features could easily run into the millions.  Vendor lock-in involves the total cost of migration, not just the initial acquisition and installation cost of the new product.

T. Norman
Monday, August 18, 2003

It may have been *mostly* Hotmail people, but Microsoft has never been slow about providing plenty of hands-on on-site support for high profile jobs... and this was not only high profile but it was a Microsoft subsiduary.

Peter da Silva
Monday, August 18, 2003

You missed the point on the hotmail note: they *did* write their own tools to control things which normally need a GUI. But they're all undocumented hacks.

Another lockin issue where Microsoft is a prime (but not unique) example: a lot of MS documents are undocumented binary formats which work with specific versions of software (e.g. helper components which shipped with specific version of office). This is going to get real interesting in a few years, because people will have data locked into formats which are no longer supported at all. When this happens for normal business documents, that's when the real 'computer archeology' industry will get bigger. (Probably still not big. And many formats are now designed with a bit more openness because of this.)

mb
Monday, August 18, 2003

MB: Ah yes, file formats.

One of my pet peeves.

See the "Monoculture in Jeopardy" thread for more on that one. :P

Peter da Silva
Monday, August 18, 2003

*  Recent Topics

*  Fog Creek Home