Clearly there are several vendors lining up to leverage open source software to build their SaaS business. Open source is most definitely going to be used in the cloud as scaffolding for service offerings. But how many of those business entities are going to attempt to lock-in users by turning their SaaS offering into a data jail of sorts by making it arbitrarily difficult to migrate away from that service to a competing service? Every single potential customer of services in the cloud needs to stop and think about that before buying into a service offering. Are businesses just going to fall into the trap of yet another lock-in situation?
I think Matt Assay is right
Sadly he's got a conflict of interest as he is an advisor for a SaaS provider.
So let me take a moment as just a crazy guy mumbling to himself on the street to re-iterate what he's saying. The answer for me as staunch advocate for open development is that the only way to have a sustainable and competitive marketplace for SaaS is for customers to demand source code access as part of the service agreement at the beginning of a service provider relationship.
There is absolutely no other way to ensure that if the quality of service degrades for whatever reason that you aren't stuck relying on that service provider to deal with your data to the detriment of your business. Push comes to shove, you take the source code and you implement the service internally to keep the critical process going to meet your needs until you can find a different provider of the same service. Of course you running the service locally isn't ideal...but it is a safety net to protect your business interest against quality of service problems with your SaaS provider.
If SaaS businesses in the cloud fail to provide access to source code, any business which engages in such a service for critical business operations is granting that service provider a defacto lock-in as the sole vendor who can provide you the service necessary to perform that business function. Even open network facing APIs do not guarantee service offering parity across service vendors. That is a recipe for cost inflation overtime, because once you are hooked...you may not be able to switch service providers without retooling your own business workflow. It would be an absolute travesty if businesses did not take this opportunity to demand that SaaS providers make their source code available as a hedge against service interruptions or quality of service issues.
The same sort of reasoning can be used to support the opening of end user oriented web services as well of course. And I am all for that. But I'm a practical zealot. As an end-user taking advantage of what are essential no-cost but closed-source service offerings I've got zero leverage to put access to sourcecode on the table as part of the service negotiation. Even as an individual who is willing to pay for a premium web service, I've got very little leverage to get a demand for sourcecode access heard. And lets face, as an end-user, the time and effort it would take me to migrate away from a proprietary web service to another service is most likely going to be smaller for me than re-implementing a service...even if it means I'm without services for a month. Twitter downtime for me is not the end of the world. No the argument for opening up end-user web services is going to have to be a much more subtle and nuanced argument about the how open development helps the service innovate to the benefit of the service provider.
But for businesses customers for SaaS..paying business customers who are relying on services for day to day business operations, the cost of a service interruption or even a service degradation become much more significant. Being able to switch to another provider quickly(even if that provider is yourself) could matter a lot more than it does to me as an end-user who has reached the end of the internet and wants to microblog about the trail I blazed to get there.