 |
 |
 |
|
05.18.10 Determining The Value Of Open Source SaaS And PaaS  By
Savio Rodrigues
Open source has been promoted as, amongst other things, a means of minimizing vendor lock-in. However, it's unclear that this value proposition holds when utilizing software as a service (SaaS) or platform as a service (PaaS) in the cloud. Open source helps, but isn't sufficient to provide future freedom of action Access to a product's source code can increase the freedom of customer choice and minimize the risk of vendor lock-in. Conventional open source wisdom suggests that the risk of forking an open source project, or simply shifting from paying customer of commercial open source product to a free user of the related open source code are two important risks that keep open source vendor motivations in check. This is theoretically true. However, unless the open source project has a strong community of third party developers, a fork isn't a credible option. Additionally, finding third party support isn't always easy, nor the best long term approach. It may be easier to migrate to an alternative product with a roadmap 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 instance, 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 protect future freedom of action Earlier this week @swardley tweeted: "Looking for a good speaker to argue that "Open APIs are enough to prevent lock-in". MSFT 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 PaaS cloud deployment is just asking for trouble. The very same reasons that open source doesn't protect against vendor lock-in to the degree proponents would hope apply to SaaS or PaaS offerings based on open source as they do to open source products deployed in one's data center. On the other hand, if 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 delineates between theoretical and actual freedom of action. Whenever possible, always put more weight on actual freedom of action when making purchasing decisions. Open source vs. open APIs, a test case A few weeks ago Salesforce.com and VMware jointly announced VMforce, a PaaS 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. tc Server is essentially Tomcat, which has also been shown running in various environments, including Microsoft's Azure cloud. In essence, VMforce offers a PaaS with a set of proprietary APIs and an open source runtime platform. As such, VMforce is a great test of whether "OSS 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 - when these APIs become open and implemented. This is true even while the underlying application server platform is open source and is portable to other cloud environments. As your company begins making SaaS and PaaS cloud selections, remember to ask whether APIs provided are open and which third party have implemented the APIs in question. Think of open APIs as you do about open standards today; 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. Comments About the Author: Savio Rodrigues is a product manager with IBM's WebSphere Software division. He envisions a day when open source and traditional software live in harmony. This site contains Savio's personal views. IBM does not necessarily agree with the views expressed here. |
|
| ||
|
CTOupdate is brought to you by: