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.