Update: I’m actually writing this update before posting this entry. I wrote this a couple of weeks back, but today VMware announced at VMworld that CloudFoundry.com (the service) will be production in Q4 of this year, and that private CloudFoundry will be available some time in 2013. It looks like some the pre-requisites for what I predicted was going to happen in this post will now be fulfilled. I do not think this is good news for the CloudFoundry ecosystem. Ultimately, it means that VMware will be competing with it’s key CloudFoundry “partners” that either offer a CF public or private PaaS. Read on…
Historically, middleware and infrastructure software comes in two flavors:
In commercial models, a technology provider has direct control over the approach. Is there inconsistency in the market message? Clean-up messaging and positioning so you are saying the right things to the customer. Are there product gaps? Gather requirements and write new code right away. There is little debate or political wrangling (OK, that’s a lie – there is always a bit of that internally), and the focus is on execution.
Community and ecosystem models have no centralized “command & control.” They are amorphous, distributed entities that can be amazingly good at driving adoption and quite resilient to general market pressures and execution failures. But what happens when community members and ecosystem partners go from being cooperative to being in direct conflict with one another? Looking at the CloudFoundry ecosystem, we can see some interesting cracks in the foundation and might soon find out what a community and ecosystem collapse looks like.
VMWare garnered some attention last year when it launched an open-source PaaS provider. Much like Apprenda, CloudFoundry can be used to create a PaaS out of public or private datacenter resources. Part of VMware’s strategy for market adoption was building a community around CloudFoundry with three prongs:
On the surface, this seems like a legitimate model that *should* work. CloudFoundry expands and third parties participate in a meaningful and presumably commercially beneficial fashion. This analysis overlooks any commercial desires from VMware that can severely limit the actual power of the community members.
Let’s start with the likely assumption that at some point, VMware would like to make money off of CloudFoundry. There are only two vehicles for VMware to do this:
I believe both will happen. If I’m right, what will this mean to the CloudFoundry community and partner ecosystem?
The first step to answering that question is to plot some of the key CloudFoundry partners and their relationships to one another:
If you notice VMware has a lot of red; nearly every ecosystem partner would be in conflict with a commercial CloudFoundry. Why? By attempting to equip partners with technology to build a PaaS, and releasing a commercial offering, CloudFoundry is attempting to be the arms dealer and a participant in the war at the same time. This model engenders conflict and mistrust, and suggests CloudFoundry will find it hard to sustain a meaningful ecosystem. Even among the ecosystem partners we find conflict. For example, ActiveState recently snubbed Uhuru by choosing IronFoundry as an embedded extension for .NET support in its flavor of CloudFoundry.
One way to illustrate how relationships might become strained is a conflict map. A conflict map is a diagram that outlines individual actors in a system and their relationships to one another. Below are the same actors listed in the matrix above:
Notice anything? Much like the matrix, you’ll see a good number of lines indicating “open conflict” going from ecosystem partners to VMware. Not only is it awkwardly early in CloudFoundry’s existence to experience these sorts of odd rifts, but such a state kneecaps the open model and VMware’s ability to scale CloudFoundry over time. And the apparent conflict isn’t just noticeable from the outside. Recently, at OSCON, popular cloud blogger and analyst Ben Kepes overheard chatter from some of these CloudFoundry partners about forking the project if VMware continues down the path of not being a good steward of the project. Hypothetically, what happens to an HP/VMware relationship if both are offering CloudFoundry public PaaS? It’s alarming to think that a project that has barely gotten off the ground is already experiencing this level of friction.
There’s at least one big open issue VMware needs to resolve in the near future that could sour things even further. VMware hasn’t chosen community leads for .NET and Java yet. It’s likely that it sees those stacks – the enterprise money makers – as its birthright. Refusing to name external community leads will hurt companies like Tier3 and Uhuru who may be forced to fork in order to compete head on with VMware. On the other hand, ifVMware chooses Uhuru for Community Lead on .NET, Tier3 will experience a soured relationship with VMware. Furthermore, ActiveState will have to choose to adopt Uhuru and stay with the project core, or follow Tier 3 down a forked path (given that embedded IronFoundry is the ActiveState supported solution for .NET).
The partners themselves have direct conflict models they have to deal with. Presumably, one of the advantages of an open PaaS would be that service providers could adopt it and build public PaaS offerings. Would a hoster choose something like IronFoundry as a foundation for a public PaaS? Probably not, given that it is built and supported by a competing hoster.
It is my belief that this relationship complexity is what is driving the rumored spin-out of CloudFoundry. By spinning out CloudFoundry, the arms dealer can become independent of all parties in the war and the conflict can be nullified. If we redraw our conflict map with a new entity, the CloudFoundry spinout, we notice something different:
VMware becomes just another entity using CloudFoundry and can pursue its vision as a PaaS vendor (including merging SpringSource and vFabric into a commercial version of CloudFoundry) while deflecting all political conflict away from CloudFoundry. VMware would just be another ecosystem partner rather than the owner: “Hey, we’re just like you! There is no unfair advantage whatsoever <chuckle>”
In my opinion, this would be a smart move for CloudFoundry. That said, I don’t think it will resolve these conflicts long term – they’ll simply reduce the rate at which the tension builds. The unfortunate fact is that most commercial business will ultimately turn to the trusted VMware brand – much like most anything JBoss related hits Red Hat’s P&L, and they likely won’t source their public or private PaaS from one of the “partners.”
Is it too early for this amount of friction, or is this an ecosystem’s natural selection at work? Does this scare customer’s since there is little clarity as to what flavor of CloudFoundry to choose? What are your thoughts?