Crossing Cloud and Open Source Business Models

I am working with two other people on launching a new company in a couple of months.  I've been thinking a lot over the past several years on taking some of the lessons learned in open source and implementing them with a cloud based model.  We are going to try something that is a bit new...

The Old Open Source Business Model.  Red Hat spawned the basic idea that most open source companies have used.  Come out with a great open source project that gets used by a lot of people.  Then develop some proprietary value-add, wrap a service layer with that and sell it as a subscription.  A percentage of the free users will find the value-add useful and pay you for it.  

Freemium Model.  This is a slight deviation on the open source model.  Don't share the code, but offer up a free version with a for pay version with higher value and a service offering of support.

Enter the Cloud.  So far the Cloud has been viewed as a simple extension of the computing environment that Open Source and Freemium projects and business models have gone into.  The two variations are:
  1. Run this code in your cloud.  Of course all open source projects can do this, and some have packaged it with an AMI to make it simpler.  In the PaaS space this is what the CloudFoundry open source project enables.  There are countless examples.
  2. Run this as a service on my cloud.  This takes advantage of the power of the cloud and multi-tenancy and efficiency, while making the code easier to use because there is no management burden to it.  In the PaaS space, this is what Heroku and CloudBees enable since they are pure services and are cloud versions of the freemium model.  Most PaaS and SaaS have this since the costs are low to start and it is a good "on-ramping" tool.

The New Idea - Part 1.  We are going to be offering an (Almost) Free Service.  The way it works is that our central service is free and will coordinate resources in our customer's Amazon Accounts.  We are using the AWS IAM capabilities so that we can manage the starting and stopping of resources in the most cost efficient manner.  Instead of us bearing the costs of starting up what might be a couple hundred servers, that cost is charged directly from Amazon to the customer.  All we really have to absorb is our central service, which will cost less than $5,000 per year.

There are two cool things about Part 1 of the idea.  First, it is very cost efficient for us and for customers - in fact the raw costs are the absolute lowest that anyone could get.  Second, they are apportioned fairly.  Customer A is not paying for Customer B's costs or vice-versa.

It correlates to the old open source and freemium models since customers run the software on their own environment - except it is drastically easier because there is no installation or management of servers.  We do all that for you (and it only costs us $5K per year!).

The New Idea - Part 2.  We will open up our Github account to paying customers.  So we are not going to be open source for free.  But if you pay us, you have access to the source and can run the central service yourself and fork the code.  This gives other cloud and software vendors the ability to create their own version of this service that works particularly well for their environment.  It gives enterprises the confidence that they will not be stuck with the features or bugs that we have and puts them in control just like open source.

What this Model is Not.  This is clearly not open source as not everyone will have access to the source code.  But as the cloud proliferates, people care less and less about open source.  They care about cost and control.  This model gives them both.

This model is also not for every project.  The service we will be coming out with is perfect for this as it is really fairly simple. Yet today there are either very costly enterprise solutions (even in the cloud), or there are open source projects that are really not taking advantage of the ease of use of the cloud for this problem domain.

We will see what people think once we release.  In the mean time, let us know your thoughts.  And of course any suggestions for names for this methodology.

Comments

Curated Source? BYOC (Bring your own cloud?)
Bob said…
Actually I kind of like Curated Source as well. Were you an English major????
Anonymous said…
I like BYOC, very nice.
Anonymous said…
I like BYOC, very nice.
Not a teacher, just a speaker.
Mark Little said…
Whatever you do, good luck Bob!
Chris Benedetto said…
Will forked code instances be partitioned off in a multi-tenant capacity thus allowing that instance to be isolated?

"This gives other cloud and software vendors the ability to create their own version of this service that works particularly well for their environment."

Bob said…
Chris, This is one of the beautiful things about Git. Linus invented it to solve his issue of source code going to many distributions. So RedLine will "Curate" the root source, but others who license the cod from us will be free to fork it and do whatever they want to with it.

We expect that IaaS vendors who covet a development oriented market will want to offer a service like this themselves, so they are likely licensees and stand up their own cost effective load testing services for their customers.

Popular posts from this blog

Ringside Winding Down

Capitalism vs. the Three Legged Stool

Galbraith Revisited