Blog Post

Cloud Foundry faces fear of forking

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the 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.

cloudfoundrylogoThe 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.

Photo courtesy of  Flickr user Marshall Astor – Food Fetishist

11 Responses to “Cloud Foundry faces fear of forking”

  1. Sinclair Schuller

    I think Barb nailed it. There is a fork in the context of a mechanism for branching code and merging contributions back, and then there is a fork in the context of a purposeful community schism. Confusing the two is not helpful, and the CF discussion is in the context a non-productive solution split that confuses the customer.

  2. Guesticle

    Remember AIX, HP-UX, Solaris, etc. etc.? Did all those different UNIX flavors do a thing to protect against lock in? Not by a long shot. And speaking of open source, did anyone else notice that Pivotal is saying that the future of Hadoop is 100% proprietary with their announcement this week? CloudFoundry is only open source until EMC can find a way to screw you.

  3. To the anonymous Guest post, she/he has a good point in that VMWare cares mostly about the likes of vCenter/vSphere and it was never clear if Cloud Foundry would get the “oomph” it really needed from VMware given that it doesn’t have a longer term “north star” to follow. So for now its pretty much all about vCenter/vSphere with a sprinkle of VMware Workstation and Fusion here and there.

  4. Here is the truth: Which customer needs PaaS? No one! Its all about applications running on software driven data centers. This PaaS is pure-nonsense.

    Take a look at how AWS is succeeding compared to PaaS like Azure. You get the point. Let the kids play/fork/eat Cloud Foundry. No one cares about it. Talk to VMWare folks(hint: vCenter/vSphere) who actually makes $ for their company! They will tell you the real story about Cloud Foundry.

    • Sacha Labourey


      I think your knowledge of what’s a PaaS could benefit from an upgrade :) . While Azure argues they are a PaaS and a IaaS, they are clearly “just” a IaaS (which until recently couldn’t even run anything else than Windows). They pitched it as a PaaS solely because Windows, by default, has .Net installed. Which is relatively short…

      If you ever need to implement a new custom application, I’d suggest you try on a IaaS directly (managing your servers, provisioning them, automatically handling what happens when those servers suddenly go down, handle clustering, session replication and failover, elasticity, OS/JVM/Middleware patching, automate deployment of new versions of your app transparently, rollback automatically if something goes wrong, monitoring, etc.) and then try it on a PaaS, a real one, not Azure. You’ll certainly never go back to using a IaaS directly. Just look at some of the case studies out there ( for example, but other PaaS vendors certainly have very good ones as well): you simply couldn’t do something as efficiently, as reliably and with as little staff by using a IaaS directly.


      Sacha Labourey
      CloudBees, Inc.

      • Sacha,
        My comments are based on my direct experience of building/deploying/managing a custom app (aka SaaS) on AWS directly for last several years. We are now operating 2 production pods and starting to generate $ from real enterprise customers. I looked hard and deep at CF and is not much useful! I do not about your solution…will check out.

        Yes, those problem exists but not at the scale you think… reality is much different when you run an app on AWS.


  5. Reblogged this on Virtualized Geek and commented:
    Let me get out my “I wonder where EMC/VMware is going” drum and beat it a little more. I still believe PaaS is the long term future of Cloud in the enterprise which is what I care about. As us traditional enterprise types start to hire talent from the start-up world they will bring their cloud first approach to the projects they work in the enterprise.

    This will push those of us that are use to IaaS to offer PaaS type solutions (Developers ultimately call the shots in the enterprise). Who will we turn to for API’s. Will it be VMware, OpenStack, CloudFoundry etc and who will influence the decision more the Developers of Infrastructure geeks? My bet is on the developers.

    That’s why this stuff is important even like me you are an enterprise infrastructure SME and why vendors need to get out in front of developers while keeping infrastructure managers happy. IMO VMware had the best chance of getting out in front of both developers and infrastructure management with CloudFoundry. I can’t say I see that same potential but I don’t get paid to be a product manager.