by Andy Oram
Dec. 18, 2010
THE CASE FOR FREE WEB SERVICE SOFTWARE
CAMBRIDGE, Mass. -- Let's put together a pitch for cloud and web service providers. We have two hurdles to leap: one persuading them how they'll benefit by releasing the source code to their software, and one addressing their fear of releasing the source code.
I'll handle both tasks in this section, which will then give us the foundation to look at a world of free clouds and web services.
Reasons for developing software as open source have been told and retold many times; popular treatments include Eric S. Raymond's essays in the collection http://www.catb.org/~esr/writings/cathedral-bazaar/">The Cathedral and the Bazaar (which O'Reilly puts out in print), and Yochai Benkler's Wealth of Networks (available online as a PDF and the basis for a wiki">http://cyber.law.harvard.edu/wealth_of_networks/Main_Page">wiki, and published by Yale University Press).
But cloud and web service companies don't have to be sold on free software - they use it all the time.
The cornucopia of tools and libraries produced by projects such as the open source Ruby on Rails make it the first stop on many services' search for software. Lots of them still code pages in other open source tools and languages such as PHP and jQuery.
Cloud providers universally base their offerings on Linux, and many use open source tools to create their customers' virtual systems. (Amazon.com currently bases its cloud offerings on Xen; and KVM">http://www.linux-kvm.org/page/Main_Page">KVM, heavily backed by Red Hat, is also a contender.)
The best monitoring tools are also free software. In general, free software is sweeping through the cloud. (See also Open Source Projects for Cloud on Rise, According to Black Duck Software Analysis).
So cloud and web service providers live the benefits of free software every day. They know the value of communities who collaborate to improve and add new layers to software. They groove on the convenience of loading as much software they want on any systems without struggling with a license server. They take advantage of frequent releases with sparkling new features. And they know that there are thousands of programmers out in the field familiar with the software, so hiring is easier.
And they give back to open source communities too: they contribute money, developer time, and valuable information about performance issues and other real-life data about the operation of the software.
But what if we ask them to open their own code? We can suggest that they can have better software by letting their own clients - the best experts in how their software is used - try it out and look over the source for problems. Web service developers also realize that mash-ups and extensions are crucial in bringing them more traffic, so one can argue that opening their source code will make it easier for third-party developers to understand it and write to it.
Web and cloud services are always trying to hire top-notch programmers too, and it's a well-established phenomenon that releasing the source code to a popular product produces a cadre of experts out in the field. Many volunteers submit bug fixes and enhancements in order to prove their fitness for employment - and the vendors can pick up the best coders.
These arguments might not suffice to assail the ramparts of vendors' resistance. We really need to present a vision of open cloud computing and persuade vendors that their clients will be happier with services based on free software. But first we can dismantle some of the fear around making source code open.
Some cloud and web providers, even though they make heavy use of free software internally, may never have considered releasing their own code because they saw no advantages to it (there are certainly administrative and maintenance tasks associated with opening source code). Others are embarrassed about the poor structure and coding style of their fast-changing source code.
Popular methodologies for creating Web software can also raise a barrier to change. Companies have chosen over the past decade to feature small, tight-knit teams who communicate with each other and stakeholders informally and issue frequent software releases to try out in the field and then refine. Companies find this process more "agile" than the distributed, open-source practice of putting everything in writing online, drawing in as broad a range of contributors as possible, and encouraging experiments on the side.
The agile process can produce impressive results quickly, but it places an enormous burden on a small group of people to understand what clients want and massage it into a working product.
We can't move cloud and SaaS sites to free software, in any case, till we address the fundamental fear some of these sites share with traditional proprietary software developers: that someone will take their code, improve it, and launch a competing service. Let's turn to that concern.
If a service releases its code under the GNU Affero General Public License, as mentioned in the previous section, anyone who improves it and runs a web site with the improved code is legally required to release their improvements. So we can chip away at the resistance with several arguments.
First, web services win visitors through traits that are unrelated to the code they run. Traits that win repeat visits include: