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.

Related:
1 2 Page 1
Page 1 of 2