For many organisations, the key dilemma they face in procurement is not between closed source vs closed source software, but between deploying software and using online services – whether its infrastructure, platform, or shared services. However, open source plays a part in all these kinds services, but it can do so in two distinctly different ways, which carry different advantages and risks for providers and customers.
A fun diversion for computer scientists is something called a [quine]; a quine is a program that can print its own source code, including the code used to print the source code! However, there was something about this concept that attracted activists such as Bradley Kuhn, particularly as software was more often deployed as web services rather than distributed and run directly on users machines, and this wasn’t covered by existing licensing (the “ASP loophole”).
What if you could license software used to run a service, so that users could always download it, including any modifications the service provider had implemented?
This is the idea behind the Affero GPL (AGPL) license. If a piece of software uses the AGPL, when its deployed to run as a service – whether its to provide infrastructure-as-a-service or an application as a shared service – users can download the complete source code including all modifications used by the service provider.
So, for example, if you take an AGPL-licensed program such as StatusNet, a Twitter-likestatus-sharing system, and you deploy it and make some tweaks to the user interface and add a few features, anyone can download your modified version and run their own instance of it. Another example is ownCloud, which is offered as either AGPL or under a commercial license.
For customers this does offer some interesting risk mitigation; if for whatever reason you no longer which to use your existing service provider, you have the capability to switch to an identical service run either in-house or by another provider, as the complete source code for running the service is available. However, for a service provider it may be less attractive, as you have limited ability to differentiate your offering in the service itself – though you can still excel at customer service, reliability, pricing and other non-software services.
In this model, while the core software used for offering the service is open source, some of the “glue” code that binds it together, and typically the user experience offered for the service, is closed source.
For example, while most of the software used to run Github is open source, GitHub itself cannot be downloaded and run elsewhere as some of its code is closed source; a strategy that Tom Preston-Warner outlines in his post “Open Source (Almost) Everything“.
For service providers it does offer the capability to provide greater differentiation of their offering – whether its a better user experience, or extra features.
For customers, however, it does create more of a problem, as its less obvious how you might be able to migrate to another provider as, unlike in the AGPL world, you don’t have access to the complete platform. Its also possible for a service provider to fold without the services it ran being able to be recreated. This is a business risk; and is one reason why open standards for cloud services are such a critical (and highly contested) area.
However its also a question of degree – for some services there is very little provided above and beyond an open source software stack and the value added is in areas such as pricing, reliability and customer service. For example, a provider may offer CloudStack or OpenStack largely as-is, or provide hosting of largely unmodified open source applications such as Moodle.
For others, the service is largely proprietary with a few bits of open source software at a fairly low level, representing a more serious level of potential lock-in depending on how well the service supports open standards.
Each service provider can therefore present quite a complex picture in terms of risk mitigation.
Making a choice
Today, the “secret source” approach is by far the most common model for services – whether its infrastructure as a service or shared application services, and is also likely to be the model used by most of the shared service providers currently used by universities and colleges.
But are they aware of the pros and cons of this model? Or even that there might even be a choice of model? Would they have a preference of one model over the other for services offered by sector organisations such as JISC?
I think these are questions worth asking for the education sector. For the wider world, “secret source” is clearly dominant, but if we want to go down that route too, it would be better to do it through choice rather than ignorance.