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.
This is a great point and one we discussed at great length at last night’s Open Cloud Meetup here at Splunk HQ. One of the topics we covered was how open source seems less relevant in a cloud-y, saas-y world. Sure, everyone loves to participate in Open Source communities. While Splunk has never defined itself as an Open Source company or released an open source product, we are Open Source-friendly and participate in a few Open Source projects and communities. It seems that the Open Source Definition, created specifically to canonize the rights and expectations around software, has very little to say about movement of data in clouds and services created around that data. Furthermore, Open Source has always defined software distribution as sending the physical bits and bytes to your local media – with the exception of the more recent AGPL v3. In a world where most software interaction takes place on a local hard drive and with local data, this makes sense, and the sticky question of what happens to the data was easily deferred until some indeterminate date in the future.
That future is now, because with data and software indelibly fused together in a synthesis of services delivered over networks and between massive data centers, the relevance of open source and, specifically, access to source code, can only decrease over time. So yes, Savio has it exactly right that open source is not enough. However, I think it’s a bit more nuanced than his statement, which I think is a bit simplistic:
Open APIs — not open source — will protect future freedom of action in the cloud
Well… maybe? The problem with the concept of “Open API’s” is that it’s easily gamed and poorly defined – usually by design. If I publish my APIs and then change them often, thus breaking your implementations regularly, is that still really open? Does that actually protect you from lock-in? APIs have a tendency to creep. And some companies trademark their APIs just to get that extra lock-in zing, to prevent competitors from taking away customers. However, if that open API were accompanied by an open source project, giving the developer, end user, and customer advance notice of changes, lock-in might be prevented.
No one is suggesting that APIs must be locked in stone or that companies must release source code for their cloud products. However, I think it’s worth pointing out that the subject of vendor lock-in in the cloud is a bit more complicated than simply “Open Source is good” or “Open APIs are good.” The truth is, the use of both will play a role in the opening (or closing) of the cloud.