CXO

Is vendor lock-in universally bad?

Is tying your application or your company to a single vendor a bad move, or do you gain efficiency in place of the lost flexibility? Join our discussion and share your opinion.


A recent discussion on Builder.com raised some interesting questions about vendor lock-in, the situation that arises when an entire application (or organization) becomes dependent on a single vendor’s implementation of a technology. Changing vendors then becomes difficult and sometimes cost-prohibitive. Encouraging vendor lock-in is a criticism most often leveled against Microsoft, although there are other vendors accused of this practice.

Member Chadd boiled the issue down to its most basic form by asking if vendor lock-in, specifically when it comes to Microsoft products, is really bad at all?

"For a small to medium sized shop, is it worth the added complexity (e.g., mixing OSs, [application server] vendor, etc.) and cost to run non-MS products? Yeah we know there are problems, but heck; we know what they are too! There are many good examples of successful [Microsoft] based e-commerce sites out there ... obviously the stuff can work.

"Are we all trying to get away from [Microsoft] because it makes sense to do so? Or are we emotionally tied to just not letting them win?”

Just don’t let “them” win?
I think Chadd’s final question is an interesting one. There’s a lot of knee-jerk Microsoft bashing that takes place in today’s development world, and I myself am guilty of it occasionally. However, does that attitude really boil down to being averse to vendor lock-in? It’s easy to imagine a nightmare world like that described by the folks at Antipatterns.com where one day your computer demands money from you to allow you access to your data and applications. But I, for one, could just as easily imagine an IBM or Sun behind such an act as a Microsoft.

You have to remember, it’s in any business’s best interest to secure return customers, and therefore future income. If by getting you to take advantage of their proprietary features, they ensure you’ll come back to them to meet future needs, you’d better believe that’s exactly what they will do. Also, if a vendor can secure your future patronage by making their products work a bit better among themselves than they would with a competitor’s equivalent product, it’s in that vendor’s best business interest to do that, as well.

Is it really bad?
Member rdean believes it to be a customer’s right to have the flexibility to change vendors at a moment’s notice, and that providing that flexibility helps keep everyone honest.

“This gives the customer power at the negotiating table. If the customer can rip and replace your products easily, the vendors are going to be more fair in their pricing structure (at least for the replaceable components). Microsoft lock-in doesn't offer this opportunity for customers.”

Member ianbren seems to hold the opposite opinion, that vendor lock-in is nothing more than an emotional reaction to the business of providing development software. He said:

“Do we agree that an IT professional's job is to deliver business value on time and on budget? If so, then that includes managing risk. If your project risk document (one gets written—right?) identifies that an [Microsoft]-based solution is too much of a risk, then you have to mitigate that risk with other options (e.g., supplement, replace, etc).

"If your organization believes passionate words like ‘escape,’ ‘lock-in,’ ‘stranglehold,’ are valid descriptions of this risk, then go ahead. But not everyone feels that way.

"Is Linux a lock-in technology? What if I want to move to OS2? Am I locked in? What about OS400/ZOS? What about Java lock-in? … By 2007, the leading high-end J2EE-certified application servers will contain more than 40 percent non-J2EE extension functionality. That is vendor lock-in by the experts.”

It’s about risk management
I think that, as ianbren pointed out, managing vendor lock-in involves risk management. The central question being, is it more risky for you to tie your system to a single vendor’s solution than it is for you to trust in pieces from multiple vendors to work and play nice together? Will you take the risk that your project will fail due to incompatibilities between multiple vendors' systems?

I’ve worked on projects where this risk was not even considered, much less managed well, and a large portion of developers’ time was spent overcoming the incompatibilities of multiple vendor systems. It wasn’t fun for the developers, the business managers, or the customers.

It’s been my experience that many smaller organizations simply aren’t prepared to deal with the potential problems that can arise from a multiple vendor solution. Add to that the fact that taking advantage of a vendor’s proprietary features will often lead to improved efficiencies in your system, and you have another reason to stick with just that one vendor.

Let me know how you feel about this matter. Post to the discussion below.

Editor's Picks