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.