Let there be no doubt, open source projects are hard. Balancing central control while still allowing individual members a degree of autonomy is like walking a tightrope – too much control and it looks like a dictatorship, too little and the initiative risks spiraling out of control in the face of multiple individual stakeholders and interest groups.
Nowhere is this more the case than when the open source project is initiated or rests largely with one entity – while Linux worked exceptionally well because there was a benign dictator in Linus Torvalds, someone who asserted strong control, but was unquestionably “pure” in his motivations, the same can’t be said of the to highest profile cloud open source initiatives, OpenStack and Cloud Foundry. Both projects have gained significant exposure, industry support and uptake, but both have also come with a healthy dose of tension.
There’s significant concern within the Cloud Foundry ecosystem and has been for quite some time. While this has almost exclusively been in the form of quiet under-the-breath mutterings, I’m sensing a page is slowly being turned and the Cloud Foundry ecosystem is in for some public airing of dirty laundry. In recent days I’ve had some confidential discussions with people inside the Cloud Foundry community, and the concerns are growing.
It seems inevitable that public announcements of Cloud Foundry forks are imminent and so it is important to do some crystal ball gazing into what this might actually mean for the project. In a well reasoned and articulate post, Stephen O’Grady of Redmonk fame (who, it needs to be admitted is contracted by many of the vendors concerned). O’Grady’s post largely focused on the legal ramifications of open source licensing, and the technical impacts of a fork, his bottom line however is that a fork (or several for that matter) isn’t necessarily a bad thing:
It’s worth mentioning, however, that from a customer perspective, forks or variants are not universally bad. While the various Android versions may represent unfortunate design decisions on the part of the vendors responsible for them, applications are in the overwhelming majority of cases compatible from device to device, assuming version equivalency.
Compatibility, ultimately, is the key to determining whether the forks which are so beneficial to development are a problem for customers. Java, for example, had multiple distinct implementations, which ensured competition and thus continued innovation to benefit customers. Compatibility, meanwhile, was tested regularly by a set of tests known as the TCK, or Technology Compatibility Kit. Without a passing grade, in fact, a given implementation could not use the name Java, and thus would not be acceptable to customers. This seems to be similar to the path Cloud Foundry, for one, is pursuing with its Cloud Foundry Core compatibility test.
While forking is then an unquestionable benefit to developers, its implications for customers – at least for projects that permit competing, non-shared implementations – are as yet unclear. Much of the success or failure of permissively licensed open source platform projects, then, will depend on how well they do or do not address compatibility questions for customers.
In doing so he rightly looked at the two issues of technical compatibility and permissive licensing. However I believe that the issue around forking specifically of Cloud Foundry is more nuanced than that and relies on two things – ecosystem maturity (and by extension customer’s willingness to adopt the platform) and validity of Cloud Foundry’s “Core” concept. The concept, according to the Cloud Foundry website aims to:
…define a baseline of common capabilities to promote cloud portability across different instances of Cloud Foundry. Further, it provides an open mechanism that lets anyone instantly validate and confirm the specific frameworks and applications supported by a particular instance of Cloud Foundry and determine whether it supports Cloud Foundry Core.
So let’s look at these two issues in turn.
Platform Maturity and Market Acceptance
Let’s not beat around the bush, PaaS is a nascent concept with very limited awareness. As such we are very much in the Wild West when lots of industry insiders talk about the promise of a technological development, but few organizations really utilize it. In my discussions with enterprises, there is a real desire to explore using PaaS, but also a real concern around interoperability, stability and lock in. Clearly VMware (when it was still running the Cloud Foundry initiative) understood this and introduced core as a way to allay these concerns of organizations Essentially they saw forks coming and decided that core was the best way to put a positive spin on a somewhat fractured ecosystem.
Quite simply a fork, or even worse multiple forks, too early in a project is a sign of bad governance and questions the validity of the entire initiative. Let me reiterate – these are very early days and any doubt that factions in the community sow in end users minds are wildly damaging to the community. This is especially the case since, from what I’m hearing, some of the conversation around forking is happening for all the wrong reasons – it comes down to vendors making the right decisions for the right reasons. As Krishnan Subramanian so rightly said:
@benkepes There is also the issue of mature CloudFoundry fork. If not, it will backfire.
— Krish (@krishnan) February 27, 2013
It’s all about maturity – which gets us to the second issue, as a foil to the risks of forks and their impacts on the project as a whole, Cloud Foundry Core is a masterful defensive move. So, does it do what it needs to?
Is Core Enough?
As is often the case around such a sensitive issue, despite many insiders expressing concern about Core, none would do so on record, citing fears about reactions. It’s fair to say however that there was a fairly strong opinion expressed by many that Core compatibility is, at best, fairly shallow. Some insiders went on to comment that Core is an example of the Pivotal Initiative (the new home of the Cloud Foundry project) being duplicitous and only testing the core functionality within Core that suite its own purposes.
Bottom Line
Cloud Foundry is a fantastic initiative but one which may, sadly, be hampered by the way it was set up and factions within the ecosystem. We need to remember that it’s not the only open source platform, waiting in the wings is Red Hat’s Open Shift platform that has an arguably more open governance model and a history of successful projects. I’d never write the project off, but perhaps it’s time to stop playing politics and make the right decisions for the right reasons.
