Why open source won't prevent cloud lock-in

Open APIs, not open source, will protect future freedom of action -- so beware so-called open source cloud offerings

One of open source's promises is to minimize vendor lock-in. However, it's not so apparent that this value proposition holds when using software as a service (SaaS) or cloud-based platform services. The implication is clear: So-called open source cloud platforms, like the recently announced VMforce, are no more open than proprietary clouds -- and believing otherwise will trap you into unintended lock-in.

Open source helps, but isn't sufficient to provide future freedom of action

The VMforce offering reveals specific issues about open source's relationship to cloud lock-in. But before I get to those, I need to remind you that even in on-premise deployments, open source doesn't necessarily prevent vendor lock-in.

[ Keep up on the current open source news and insights with InfoWorld's Technology: Open source newsletter. ]

It's true that access to a product's source code can increase the freedom of customer choice and minimize the risk of vendor lock-in. Conventional wisdom suggests that two factors can keep open source vendors' lock-in ability in check: the risk of forking an open source project and the threat of clients shifting from being a paying customer of a commercial open source product to becoming a free user of the related open source code.

But this conventional wisdom is often not correct. After all, unless the open source project has a strong community of third-party developers, a fork isn't a credible option. Likewise, finding third-party support for the free version isn't always easy, nor is it the best long-term approach. Still, there's some risk for open source vendors who alienate customers of their paid versions; it may be easier to migrate to an alternative commercial open source product with a road map and community support that your enterprise can rely on.

I've argued that open standards have a much larger impact on minimizing vendor lock-in than open source alone. For example, reducing the risk of vendor lock-in through open standards, implemented by a plurality of vendors, regardless of the product's source code availability, has been a major driver of Java EE adoption.

Open APIs -- not open source -- will protect future freedom of action in the cloud

Now let's get back to the cloud issue. Earlier this week @swardley tweeted: "Looking for a good speaker to argue that 'open APIs are enough to prevent lock-in'. Microsoft bailed on me. Recommendations welcomed."

I tend not to like discussions that paint the world as black and white, which is why I responded that open APIs matter a lot more than open source in cloud deployments. Relying solely on open source to minimize lock-in within a SaaS or cloud platform deployment is just asking for trouble. Just as open source doesn't protect against vendor lock-in to the degree proponents would hope, the same reasons apply to SaaS and cloud platform offerings based on open source, as well as open source products deployed in one's data center.

1 2 Page 1
Page 1 of 2