Why open source won’t prevent cloud lock-in

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.

On the other hand, if an application relies on an open API that has been implemented by another vendor, you now have the hope of moving your application elsewhere. The distinction between an open API and an open API that has been implemented by another vendor comes down to theoretical and actual freedom of action. Whenever possible, always put more weight on actual freedom of action when making purchasing decisions.

Open source versus open APIs: The VMforce test case

A few weeks ago Salesforce.com and VMware jointly announced VMforce, a cloud platform for Java developers. It’s interesting to note that the VMforce marketing highlighted two seemingly conflicting value propositions. First, Java developers could build richer applications by leveraging the Salesforce.com APIs that are already available on Force.com. Second, companies could expect application portability from Force.com infrastructure to other cloud environments. The portability claim is based on the fact that VMforce applications will run on the Spring framework on tc Server, two Java open source offerings. The Spring framework is well known to run on multiple application servers, and tc Server is essentially Tomcat, which has also been shown running in various environments, including Microsoft’s Azure cloud.

In essence, VMforce offers a cloud platform with a set of proprietary APIs and an open source runtime platform. As such, VMforce is a great test of whether open source is enough to minimize vendor lock-in in the cloud. The blunt answer is no, it is not. Any applications that want to leverage the Salesforce.com APIs, which, frankly are interesting and could help deliver richer user experiences, are tied to one and only one cloud infrastructure: Force.com from Salesforce.com. This will remain true until a third-party implementation of the Salesforce.com APIs is available — that is, when these APIs become open and implemented. This is true even while the underlying application server platform is open source and portable to other cloud environments.

As your company begins making SaaS and cloud platform selections, remember to ask whether APIs provided are open and which third parties have implemented the APIs in question. Think of open APIs as you do about open standards today: as necessary purchasing criteria when seeking to minimize vendor lock-in. Think of open source in the cloud as you do in your data center: a contributor to future freedom of action, but not sufficient to guarantee it.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

This article, “Why open source won’t prevent cloud lock-in,” was originally published at InfoWorld.com. Read more of Rodrigues et al.’s Open Sources blog and follow the latest developments in open source and cloud computing at InfoWorld.com.