Three cloud evangelists walk up to the bar, one asked the bartender for a martini shaken not stirred, the other asked for a glass of tap water and the third asks for bottle of evian. Which one is working on Open Source?
The simplistic answer is “all of three” as there isn’t a cloud software initiative on the planet that doesn’t have some Open Source ingredients baked into it at multiple layers.
But the real answer is much more complex and it’s one I’ve been mulling over for the past few months.
Going Open Source (again)
The cat’s out of the bag now and if you hadn’t heard about it, I’ve made the move to Red Hat to work in the Open Source world again. Spending energies on building & supporting a closed source or proprietary Cloud initiatives no longer makes any sense to me. There’s been alot of good healthy writing going on this past month about the debate Open Source vs. Free which I highly recommend reading but that’s not a debate I’m wading into at the moment.
When it comes to Cloud initiatives, whatever the layer or part of the tool chain being discussed, there’s an Open Source project out there for it. From IaaS, PaaS to SaaS: all the layers and the tool chains for managing and deploying Cloud have a growing contingent of Open Source options. Many of the initiatives are better than anything any one entity could have ever built on their own. That’s the power of community collaboration.
Whatever the excuse for going closed source in the cloud: closed custom forks, tight-fisted governance models, protecting secret sauces, or bowing to the whims of VCs and “angel” investors to secure funding - the proprietary model doesn’t work anymore. The “OpenCloud” will “win” in the end as just as Linux has “won” the enterprise.
Bottled Water Model is “Broken”
I always loved (and still do espouse) the “Bottled Water” business model of Quality Assured & Supported Open Source in which the “bottler” contributed heavily to the project that was being sanitized, extended and wrapped in fancy bottles. Don’t get me wrong, I still like to make money and I still think this model “works”. But for the model to work, the “bottler” needs to be a truly engaged participant in the project and active in the community.
It’s always been the key to the success of the “Bottle Water” model is that the “bottler” be able to contribute back in a meaningful way to the project they are bottling. These days this not always possible for the bottler as the variety of licenses that need to be adhered to, the supposedly benevolent dictatorships that tightly monitor who has design & commit privileges to projects, and corporate infighting that goes along with today’s heavily corporate sponsored open source bazaar - simply makes meaningful participation in some “Open Source” difficult, if not impossible
Some of “bottlers” are simply end up redistributing tap water with the packaging that makes it easy to consume. Great packaging is awesome, but there’s still an obligation (IMHO) to give back to the community that’s filling the tap.
When it’s not possible to do this, that’s when the “Bottle Water” business model fails. It’s a failure of both the bottler & the project’s community .
Innovation is more than a Flavor
Just look at the actual bottled water industry, with it’s bad rap for being less than eco-friendly, with bottled water being sold by corporate giants like Coca-Cola and Nestle pumped up with sugars, vitamins, fizz, color and energy supplements and marketed as something that will make you more powerful than a speeding bullet and able to leap tall buildings in a single bound.
The same sort of explosion of flavors threatens to splinter the cloud into an inter-operablity nightmare as the PaaS marketplace enters the next stage.
Innovation that simply “flavors” the waters causing developers to choose the most “popular” PaaS with the best marketing campaigns, deploying their apps without understanding the ingredients that are being added will cause addictions and lock them into services & practices that will stunt their growth and fail to help them scale those tall buildings.
The RapGenius fiasco at Heroku is a good example of the collisions that arise when great hipster vibe early adopter marketing for decent proprietary product offering from a company with good intentions and great corporate values enabled a application development team to set aside the responsibility for truly understanding what’s under the hood, reading the label, understanding the ingredients and knowing what their application was running on. Once the collision occurred, there was no venue other than twitter and the blog-o-sphere for the conversation between aggrieved parties to resolve their differences. No way to collaborate on a solution together.
Contributing to an open source project is more than just packaging and adding flavors, it’s being able to contribute at the core design and architectural level. It’s creating the next generation of the project together and in consultation with the community not in a vacuum. Building communities that work is hard, creating eco-systems that support them and thrive takes lots of experience, communication, openness - and it’s not a popularity contest.
So why Red Hat?
History. Red Hat knows Open Source. Red Hat has an exceptional history of supporting and building communities around Open Source projects like Linux, JBoss, Fedora, Gluster and a myriad of others. As Red Hat steps up to the cloud with OpenShift Origin & OpenStack cloud initiatives, the Cloud shifts again to a more “Open” playing field.
So when thinking about getting into the bottled water business, be sure to read the label, understand the ingredients, and learn everything you can about the community process that stands behind the tap - before you turn it on.
And that’s why I’m drinking the Red Hat Kool-aid these days and the occasional martini.