Turning a parking lot conversation with my friend Rob Phipps into a blog post.
The conversation took place after Oracle’s Cloud Computing event here in Pittsford. Rob observed that only very little open source software featured in the 6 hour event: Xen (the underpinnings of Oracle VM), OpenSolaris (just a mention, didn’t appear to feature in the strategy) and Linux. For the rest, or for all practical purposes the whole software stack, is Oracle’s own. Enter a philosophical discussion whether open source software decreases vendor lock-in, whether open standards do that, and whether open source software supports or hinders the emergence and adoption of open standards.
Let me state upfront the conclusions we reached and then follow up with the argumentation that got us there:
- Open Standards decrease vendor lock-in;
- Open Source Software does not diminish customers’ lock-in to the products of the big vendors;
- Open Source Software is damaging to the adoption of Open Standards.
And thus, customers should demand that their vendors collaborate on Open Standards first rather than Open Source Software.
Open Source Software (OSS) is software where the source code is licensed so that anyone can see that source code, make modifications, and redistribute the result. Roughly speaking there are two main families of OSS licenses: GPL-style and BSD-style licenses. GPL-style licenses require that you make your modifications available under a similar license including any software that you bundle with the software when you redistribute it. BSD-style licenses allow to redistribute the software under a different license including proprietary ones. Some BSD-style licenses require that you made modifications to the code before gaining that right while others don’t. Examples of OSS are Linux, OpenOffice, Eclipse and Netbeans.
The proclaimed benefits of OSS are many:
- better quality as more eyes are looking (or can look) at the software
- increases security, for the same reason
- levels the playing field
- protects against monopolies
- purchase price is low: $0
- lower development costs
- and, avoids vendor lock-in
Then there are ideological principles such as “software wants to be free.”
This is all great so where is the kink?
It is the key aspect of OSS regardless of the license you pick: it enables your competition. The specific license makes this more so or less so but it is always there. For most businesses it is true that recurring sales from existing customers is king. A vendor must find ways to tie its customers to itself. If the competitor has access to the same source code then the vendor must find a different way to achieve this. Many vendors achieve this by either limiting the use of OSS to supporting components or to commodity layers (eg the operating system) and keeping the core proprietary, or by so heavily modifying the open source software that the effect is the same: very expensive for the customer to switch vendors.
A new term is emerging in the industry to capture the presence of OSS within the software stack a vendor offers to customers: Open Core. This term attempts to communicate open-sourcy goodness to potential customers and to allow the vendor to present itself in a positive light. Of course it is the vendor who decides what in the core or rather in the stack is open source and what is available only under a proprietary license. I don’t know of any vendor-led open source project that delegates that decision to its community. As Simon Phipps notes in his ComputerWorld blog while this is a valid business, it has little to do with software freedom anymore. The Open Core model significantly differs from a dual-licensing model: in the latter the same code is offered under different licenses.
What surprises me in the ongoing discussion on Open Core is the absence of “Standards”. Phipps and others argue that open source software enables software freedom. I believe this is at best only part of the story. Many OSS licenses as well as communities like the Apache Software Foundation are constructed as such at least in part to enable Open Core business models.
To move Software Freedom (to use, study, modify, and distribute the software without restriction) from often a theoretical freedom to practical ability for customers Open Standards or Open Interfaces are required. Let me give a brief definition of an Open Standard: a well-defined, publicly available specification together with a publicly available test suite which implementers are required to pass. And these need to be managed by an independent organization.
In the absence of Open Standards, open source software just functions as another means for vendors to lock in their customers and making it very expensive for customers to replace one vendor’s implementation with another.
In the computer and software industry the Java Community Process (http://JCP.org) was going in the right direction for a while but ultimately still falls short. The JCP was the first to recognize that a meaningful standard needed three pieces: the specification, a reference implementation showing that the specification can be implemented, and a test suite proving the correct and complete implementation of the specification. Requiring these three pieces also positively impacts the quality of the standard: the spec is tested by the effort to create the reference implementation and the test suite, and the test suite and the reference implementation test each other. A positive feedback loopback.
For a while things worked quite well and successfully: the JCP’s presence contributed to the success of Java EE. But eventually its shortcomings are weighing it down. JCP.org is not an independent non-profit but owned and managed by Sun and now Oracle: the fortunes of the standards effort are tied to the (mis)fortunes of the corporate owner. And while the JCP requires a test suite for each specification, it does not require that this test is publicly and freely accessible. This creates two problems. First, vendor claims of compliance can’t be independently verified leading to a nontransparent trust-based system between the vendor and the owner of the test suite. Second, certain parties can be precluded from certifying their implementation (eg the years-long standoff over Apache’s Harmony project).
I don’t believe the magical “truly independent standards body” can be created. If nothing else a standard must leave certain areas unspecified in order for that standard to be commercially interesting in other words protect some ability for differentiation among implementing products. In addition creating standards is expensive especially when requiring a meaningful test suite. Some form of direct or indirect ability to recoup that investment needs to be available.
If the perfect one can’t be done then what’s the best we can do?
First of all, customer or end-user involvement is mandated. Vendors have no need to implement standards and adhere to them if their prospective and existing customers don’t require it. Without customer pull no meaningful standard will emerge. Most standards organizations are weak on this point. Even the heralded ISO and ANSI organizations are dominated by the vendors.
Open Source vs Open Standards
Collaborate on standards, compete on implementations