Tuesday, April 30, 2013

Carrot or Stick?

We were so lucky to have Peter, Kesuma and Saingiore visit us from Tanzania last night.  Peter founded the Orkeeswa School in a rural Maasai village.  My daughter, Allison, taught at the school last year.  It is an incredible place, filled with smart, enthusiastic students.

The big discussion topic last night was people's rights in primary school (Orkeeswa is a Secondary School - only 7% of Tanzanians get to go to secondary school).  Kesuma holds the belief that it is OK for the teachers to cane students.  This is a very common practice in Tanzania, and reminded me of stories of my Catholic School friends.  It sounds a bit harsher and more frequent in Tanzania.  Kesuma believed that it was the right of the teacher, and it made the students do better.

Saingiore held deep reservations about this practice.  He has started to help as a teacher in a primary school, and he does not use the stick.  He did say there was some peer pressure from his colleagues to use the stick and so he put one on his desk in the classroom.  He said the students seemed more attentive when the stick was on the desk.

Peter did a great job in drawing out their feelings and thoughts on this issue.  His core thought was that it totally changes the student-teacher relationship.  Orkeeswa does not allow this practice.  He talked about the need to respect your teacher and not fear your teacher so that you could learn more.  He also pointed out that there was often trouble upon graduation from primary school as there was retribution from students.

I brought up the story we have heard (they had not) of the carrot and the stick as ways to move a donkey forward.  I side with Saingiore in this debate and suggest the carrot is far better than the stick.

Sunday, April 7, 2013

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.