tecosystems

You Can’t Stop Lock-In, You Can Only Hope to Contain It

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Seriously.

Following the recent conversations on the potential to be locked in to various and sundry cloud platforms, I’ve been forced to articulate my position somewhat less ambiguously. Lock-in, in my opinion, is nothing more or less than a fact of life. The best you can reasonably hope for is mitigation, and even that requires diligence and an uncommon attention to longer term details.

Reasonable minds may disagree, as is usual, but thus far I have yet to be disabused of this particular notion. Some have held up open source as a vaccine, and to be sure it can be of massive assistance in limiting the impact of lock-in, but it is no panacea.

Consider the case of an application built on, say, Linux (any flavor) and MySQL. Can you migrate this application from its infrastructure successfully to a competing operating system and database? Certainly. Well, almost certainly. What runtime have you chosen? Are their flavors available for your new target platform? With the correct version? As for the database: are you using custom bindings? MySQL specific application extensions? Can your dumped data be imported to the new database platform? Easily?

The answer to all of the above may well be yes. But you’re still going to run into problems, because every platform involves to some extent its own lock-in. It is the nature of technology, if not life.

Nor are standards a perfect solution: QWERTY, after all, is quite standard but something of a lock-in nonetheless.

Java advocates are probably set to champion the write once, run anywhere mantra at this point as they are wont to do. I trust that those who’ve had to migrate J2EE applications from, say, WebLogic to WebSphere will have some thoughts on that particular subject.

Even on a personal level, lock-in is impactful. I could stop using Firefox, as an example, just as I could stop drinking beer, but neither is a particularly attractive proposition. The former because I’ve heavily customized Firefox to my usage, and the latter because beer is good and proof that a deity of some sort loves us and wants us to be happy.

Every day, customers willingly lock themselves into platforms: Windows because of the market size, Google App Engine because of the scalability tradeoffs, and so on and so on. As a market, as a species, we are willing to lock ourselves in. For better, perhaps, but usually for worse.

In this context, it’s completely unsurprising that suppliers would question the benefit of minimizing their ability to lock-in their customers. After all, as Shapiro and Varian tell us, the NPV of a firm is at least in part a function of its ability to lock-in customers. If lock-in can only be mitigated, customers are typically less than concerned, and it affects the financial performance of the organization in question, what’s the point, really?

The point is that markets tend to seek equilibrium and competition. Not quickly, perhaps, but inevitably. Software markets that will tolerate high degrees of lock-in, and its extreme product – monopolies – are rare and less than permanent. Fortunately so. Eventually, markets – operating system, virtualization, and – in future – cloud, demand lower switching costs. Not zero lock-in, as discussed above, but as near it as possible.

If you’d be a long term player then – and really, who doesn’t want to be? – you need to consider what will make you sustainably competitive. Assuming that you don’t have the benefit of a monopoly that makes it possible for you to lock customers in, a reasonable assumption given the statistical improbability of this occuring, ensuring that switching costs are kept low is a good place to start.

Not because it’s the “right” thing to do, or even because it fosters innovation and breeds trust as Simon covers.

It’s a good place to start because people eventually do care. A lot. As I commented a long time ago, choice is like the vote. Offer it to the population, and a substantial portion will decline to exercise it. But deny it to them at your peril.

Even if you can’t stop lock-in, you’d best contain it as well as you’re able. Fight the good fight, and you’ll be rewarded.

3 comments

  1. Solid advice Stephen. I wrote an interesting little piece about lock-in earlier this year…specifcally about how lock-in is used by development teams as a bogeyman to gather support for internal development projects.

    But lock-in will only worsen with time. Systems tend to become more complex, not less, over time regardless the development platform, architecture or source (bought versus built).

    Decisions made today can and will have a long-lasting impact.

  2. timely piece stephen. i have been thinking about the cloud, and the “need for open source standards” as Simon Wardley puts it. I am not so sure. It seems to me we’ve never hard a computing wave where customers didn’t anoint a *hopefully* benign dictator (they never really are!) to package a set of standards and add extensions to create a computing experience that works for the mainstream. It seems to me deeply ironic that today many of those geeks who proclaim themselves to be holders of the the open flame are jumping straight into Apple’s warm, closed, embrace. The Apple experience is amazing, computer, iPod, phone – but its certainly not open.

  3. Seems to me that if a product A didn’t have any lock-in, it would have to be identical to a product B. (Otherwise there’d be a feature in A without an equivalent in B i.e. lock-in). Or a clean subset, in which case B would have lock-in.

    No lock-in’s would mean a fully commoditized market with no differentiators and innovation would be at a standstill, which would clearly be worse than lock-in. So limiting the amount of lock-in seems to be the only reasonable way out, as you suggest.

Leave a Reply

Your email address will not be published. Required fields are marked *