CloudBees Open Source Choice


CloudBees is made up of Open Source veterans.  Sacha Labourey was the CTO of JBoss, Kohsuke Kawaguchi is the Founder of Jenkins and Hudson, Michael Neale, Adrian Brock, Ryan Campbell, Paul Sandoz, Harpreet Singh Vivek Pandey, and many others have spent most of their careers developing open source software.  On the business side, David Skok and I are two well known advocates for the open source business model.

It begs the question, why is CloudBees not open source?

The fundamental reason is that our goal is to create a new type of software – that is really consumed as a service.  We feel strongly that open source brought a whole new cost efficiency to using software in the enterprise.  JBoss and Jenkins greatly reduce the cost as compared to previous enterprise software models.  The new Cloud era ushers in new levels of cost savings and increased flexibility.

In short it required a different model, one that is more hybrid in nature.  Still using and contributing to open source projects that can be used in enterprises – we do plenty of this with Jenkins, Tomcat, JBoss, Glassfish, etc.

The Cloud is Different
The Cloud affords the opportunity to drastically reduce operational costs and increase the flexibility.  To get at those, we need to eliminate the overhead of installing, configuring, testing and maintaining many layers of software for each application, department and enterprise.  Eliminating the overhead of multiple versions of infrastructure.  Eliminating costly support contracts with vendors.  Eliminating capital requirements.

In the perfect world of effectiveness, application developers build apps and just deploy them to the Cloud.  No need to have any of the old overhead.

We felt strongly that the open source business model did not fit this new world.  Open source fits well when lots of people will be running lots of versions of the software and making lots of changes to it for their own environment.  This use case is kind of the polar opposite of the Cloud.

Open is Different with the Cloud
The lock-in for Java app servers was not because the application was unable to move, but the investments made in the infrastructure.  Companies had to buy servers, expensive licenses, expensive maintenance contracts, pay high powered people to design the architecture, install and configure the systems.  Create a process for testing, staging, deploying.  The tooling, scripting and environment around this became BEA and IBM's lock-in.  Even JBoss and Spring use EAP, JBoss Network, and tcServer, to lock in the operational aspects.

By outsourcing much of that to the Cloud, companies can step up to a new level of openness.  eXo Cloud-IDE demonstrates how it can do a git deploy to CloudBees, CloudFoundry, OpenShift, Heroku with a simple menu option.  The core competency and investment is in the code.  So if users don't like a Cloud provider, they just point and click and are done moving.

The reduction in operational overhead reduces costs, and the ease of migration ensures competitive costs between Cloud alternatives.

This is a radical departure from the past.  And will take a couple of years for the market to truly understand.  But this new approach will cause companies to look more at the functionality provided than how it is done.

Not to channel Steve Jobs inappropriately, but some of the thoughts of simplicity he brought to the consumer market are being brought to the Enterprise market by new companies with new approaches like CloudBees.

Comments

Anonymous said…
I had the impression CloudBees was assembling a running stack of all open source software, and that your differentiator was the know-how to perform and sustain that assembly rather than the creation of proprietary code.

If that is indeed the case, it would seem to me that CloudBees is as close to open source as the cloud will ever be. So does this mean you have some proprietary secret sauce, or just that you're modest?
Bob said…
Being a Cloud PaaS is a lot more than just putting together a bunch of open source code. All those moving parts are tough to open source and sustain multiple versions across many, many environments. So we do not open source those or the whole thing combined because it would be impractical for anyone to really use or maintain it...
Jens said…
Labourey's former colleagues at RedHat seem to disagree - even though we IRL have not yet seen the OpenShift code.

I'll be interesting to see/hear if this is due to actual technical reasons or simply different business models.

What do you think, Bob?

br,
Jens
Bob said…
Jens,

I think it is both technical and business model. I include what users are interested in as the key part of the business model. In the case of Cloud, people are interested in having stuff run.

I think you see both VMWare with Cloud Foundry and Red Hat with OpenShift as having difficulty with the typical open source model. CF is obviously not sharing their full stack, or the code they are using to run cloudfoundry.com.

Part of it may be protecting secret sauce from competitors, but I think a bigger part is the focus is on having a big operation running smoothly rather than community building and having parts of the community make things run smoothly.

For example with JBoss tens of thousands of ITOperation shops have to make it run efficiently for them and train their people, and manage the hardware and network and do upgrades, so forth. In the case of the cloud, there are just a few big production instances of the software that are maintained and run.

Popular posts from this blog

Ringside Winding Down

Facebook Open Sources Platform

CRM Version 6 – This time for Races