Stay on Top of Enterprise Technology Trends
Get updates impacting your industry from our GigaOm Research Community
The rumblings have been around for weeks but now they’re breaking the surface: Cloud Foundry, the open source platform-as-a-service framework faces a bit of an insurrection. Several vendors, such as AppFog, ActiveState, Tier 3, Uhuru, etc. — have built PaaSes atop the framework and some have quietly been mulling forking the Cloud Foundry code, citing lack of clarity about the project’s future.
The attraction of the multi-vendor Cloud Foundry effort is that, in theory, it would provide customers an array of compatible PaaSes from different vendors. If they don’t like their experience with one, they can move their code elsewhere. But now the prospect of a “fork” looms with some other vendors thinking of splitting off and doing their own iterations. Worst case scenario: that could negate any promise of compatibility. And that raises the old bugaboo of vendor lock-in which even PaaS providers say has restricted business demand for PaaSes.
Some background: late last year, VMware(s vmw) turned over the Cloud Foundry effort and related projects to the Pivotal Initiative spinoff. Since then some of the third-party Cloud Foundry crowd have complained that they have not gotten information they need from Pivotal. And, they worry that Pivotal or VMware will push its own commercial, competitive version of Cloud Foundry. And so they privately discussed forking the Cloud Foundry code. Any fork or forks raises the specter of a fractured standard.
Sinclair Schuller, CEO of Apprenda, a non-Cloud Foundry PaaS, raised a ruckus last week when he posted his take on the impact of any fork or forks on Cloud Foundry. (Long story short: it will be bad for customers, Schuller wrote.) That caused a kerfuffle which Redmonk analyst Stephen O’Grady addressed in his blog post. O’Grady tried to downplay the negative impact of forks, writing:
“We reject the notion that forking is an undesirable outcome. Forking is, to the contrary, provably beneficial to modern open source projects – at least from a developmental perspective.”
But O’Grady also conceded that, because Cloud Foundry is not licensed under the General Public License (GPL) — as Linux was — it faces different issues;
“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.”
In his own blog post, cloud pundit Ben Kepes cites “tensions in the Cloud Foundry world, ” and maintains the possibility of a fork should concern customers.
“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.”
I’ve asked Cloud Foundry and some of the third-party PaaS providers for comment and will update this when they get back to me.