Cloud Foundry: How Enterprises Could Get Forked
NOTE: We updated this post here.
Cloud Foundry is taking an unorthodox approach to getting product innovation and community evolution engagement that is ultimately bad for enterprise customers looking for a private PaaS.
We see two main issues:
1.) Cloud Foundry promoting a provably broken “distro” model and trying to wrap that in a “compatibility standard” named Cloud Foundry core
2.) Cloud Foundry encouraging open source forks, dividing its developer and product community and creating product confusion
Both of these are flawed strategies with historical precedent that allows us to predict nothing but heartburn for enterprises. Let me explain.
The distro discussion
First, let’s remember that Cloud Foundry itself, at least in the context of an on-premises private PaaS, is hardly a product that runs out of the box. It’s a framework for building a PaaS. In fact, I recently heard a key Cloud Foundry community lead (CEO, in fact) refer to Cloud Foundry as an “open source library they use for building their PaaS” in a semi-private presentation in front of a crowd of technologists. This means that other companies are expected to build a productized offering for enterprises to consume, and that each “distribution” has the potential to deviate from the core PaaS from a functionality and compatibility point of view.
In an attempt to remedy this, Cloud Foundry released “Cloud Foundry Core” with the tagline “Preserving Cloud Application Portability.” They really should have been honest and used the tagline “Ensuring Our Distros Don’t End Up Too Fractured.”
Cloud Foundry core has nothing to do with “Cloud Application Portability” and everything to do with distro control – not to mention that Cloud Foundry actually doesn’t do anything to help programmers develop cloud apps, and is merely a web application deployment tool (akin to “InstallShield for web apps”). Lastly, telling people something is incompatible doesn’t prevent it from being incompatible, so Cloud Foundry core’s utility is questionable.
The burden of productization falls on the “distro”, meaning we have a bunch of companies all providing their flavor of Cloud Foundry. To differentiate they will either produce blatant incompatibilities with Cloud Foundry core, or produce “unique” value above the waterline that, should an enterprise use it, would be locked to that distribution. This is already broken – most Cloud Foundry partners have a website or sales material that shows how they differentiate from Cloud Foundry like this. How on earth can they be “compatible” with that laundry list of differentiation which is only going to get longer? Remember the “Write Once, Run Anywhere” of Java? That’s what they’re trying to do. Funny that we now call that “Write Once, Debug Everywhere” standard.
What about forking?
The right to fork an open source project is core tenet of open source. It gives community members the ability to change the destiny of a project if they don’t like its direction, people or practices. Generally speaking, however, forks are bad news for open source projects. They fracture the developer community supporting a project, reduce the effectiveness of the project, and worst of all, create confusion and huge risk for customers of open source projects.
This is not what customers are looking for – people want to use a PaaS, not be confused by one. It would seem that to “bait and switch” a customer with the promise of ‘openness’ only to ensnare them in a model that can’t facilitate that reality is a huge failure, especially for a project that is still so young.
I know some will take issue with that statement, but it also gets lots of support. Don’t believe me? Just ask around:
- Popular cloud projects like OpenStack try to discourage forks because of the negative impact on the community.
- Famed OSS advocate Eric Raymond stated that “Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking.” ESR knows this because its negative impact on OSS projects is obvious.
- David Wheeler shows that there are four possible outcomes to forking, two of which are generally considered unfavorable outcomes and wasted effort.
- Kerry Ancheta, Apprenda’s VP of Sales, ran Enterprise Sales for MySQL. He regularly talks about how one of MySQL’s greatest fears was forking. It fractured the developer community, made it hard to deal with irreconcilable R&D differences, and ultimately, was bad for the customer.
Given general agreement from the experts on the topic of forking and a historical context that demonstrates forking as a harmful pursuit, then what is going on with Cloud Foundry? They are actively encouraging forking.
Their idea of building a community is that you should start the evolution process early and fork the source, and produce an even deeper level of irreconcilable incompatibility that goes beyond distros. Some of the distros like Iron Foundry and ActiveState are also forks, and to make things worse, they are trusted “community leads” who built support for things like .NET and python, which Cloud Foundry hasn’t brought into the core project yet.
It’s unclear whether these forks are up to date given that their websites still refer to Cloud Foundry as a VMware offering given a spinout to the “Pivotal Initiative” months ago.
With such a haphazardly thought out model mired in the complexities of distros and encouraged forking, enterprises thinking about private PaaS will find their heads spinning. Do I need this distro for this feature or do I need this other distro? Is it a fork or the real thing? What’s compatible with what?
It feels like I’m the only one asking the right forking questions at this point.