As I was running through my RSS feeds this morning, Roberto Galoppini pointed me to a post by James Dixon (the CTO of Pentaho) on the Beekeeper Model for Commercial Open Source (PDF).
It references Geoffrey Moore’s Crossing the Chasm which I’ve used for years to drive our OpenNMS business, so it caught my attention. I haven’t blogged much about open core for awhile, but I thought this article deserved a closer look.
Since I’ve been labeled a hippy open-source purist, let me state again my contention that companies that label themselves “open source”, including “commercial open source,” need to produce products where 100% of the software code is available under the OSI Open Source Definition via an OSI approved license. If the business model involves generating the majority of revenue by selling “enterprise” software via traditional closed licenses, that software doesn’t meet the definition of open source and should not be called such. I’m perfectly happy with “Commercial Open Core” but let’s not confuse a neo-proprietary software model with open source.
My bullshit meter jumped slightly when I read his list of open core companies:
Companies using the single-vendor or open-core commercial open source models include MySQL, Ingres, Compiere, Open Bravo, Liferay, SugarCRM, Mule, Alfresco, JBoss, Digium, and Zimbra.
The meter only jumped a little because he used the term “or” instead of “and”, but on reading the rest of the article it seems like they are equivalent, so I need to point out that not all of these companies are open core.
Everyone who calls their company “open source” likes to be compared to JBoss since they were purchased for so much money, but I want to stress that JBoss isn’t open core. From their website
you can see that there is no code differences between JBoss Community and JBoss Enterprise. Sure, you get patches, and hot fixes and gobs of benefits by being an Enterprise customer, but special code is not one of them.
Digium is very similar. We love the gang over Digium as they strive to make sure their code is 100% open, and we use their software in-house as well.
It is also my understanding that MySQL, another successful open source company, made 100% of its code available until a year or so before their acquisition by Sun. In that last year I believe that “enterprise” customers got to see code six months or so before it was released into the wild, which while unfortunate, still resulted in all of the code being open. Prior to that you could get MySQL under an open license or you could purchase a proprietary license and imbed it in your commercial product. As long as the open and proprietary version are basically the same code I think this is a legitimate way for an open source company to generate revenue from software licenses.
Someone please correct me if I have my MySQL facts wrong.
In two if not all three cases they pass the CentOS test, and thus I don’t consider these companies to be open core.
Mr. Dixon did score points with his statement on open source software vs. free software:
Open source is not free. In 1998 the term ‘open source’ was coined to replace the term ‘free software’ because many people assumed ‘free’ to mean ‘zero cost’ whereas it was always intended to mean ‘freedom’.
That’s it in a nutshell. Open source requires a different kind of cost, but you don’t get a free (gratis) solution. However, people have taken it a step further to mean that commercial software can be called open source since commercial software is not free, too. “Syllogisms are only partially convertable. While Alma Cogen is dead … only some of the class of dead people are Alma Cogen”.
His entire section on The Principles of Open Source is pretty spot-on. I found myself warming to Mr. Dixon.
Then we get to the meat of his document, his four models of software development:
- The Wild Hive Model for Open Source Projects
- The Maple Syrup Farm Model for Proprietary Software Companies
- The Beekeeper Model for Single-Vendor Commercial Open Source
- The Honey Gatherer Model for Services/Support commercial Open Source
This is interesting stuff, so please read it for yourself. It is so elegant and comes with nice little drawings that it took me awhile to understand why my bullshit meter was pegged.
Then it dawned on me. Instead of the Beekeeper model it should be called the Sharecropper model. The single vendor controls everything while benefitting from the community, while the community only exists to serve the single vendor. When he writes “In the Beekeeper Model the bee farm provides land, hives, and flowers etc.” it is just like a plantation owner in the old South owning all the land and means of production. The bees are not in control of their destiny, much like some sharecroppers were told when, where and what to plant.
This is at the heart of my problem with open core software. In a vibrant open source community it is the community that controls the product, not the vendor. Mr. Dixon states:
This explains the common practice of the Beekeeper companies to offer some kind of ‘Enterprise Edition’ that includes features not available to the community. These are high-end features that only larger organizations find of value.
Who decides what features are of what value? As I mentioned in my Hyperic post awhile ago their community is screaming for a feature that only exists in the “enterprise” version, yet their needs go unmet. It is obvious that Joe User needs the feature but because it drives software revenue it will never be open. According to Dixon is necessary because
It is clear that the single-vendor model is more costly to set up and operate than the services/support model. It is logical that companies using the Beekeeper Model need to generate more revenue to recoup these costs than a company using the Honey Gatherer Model
No, it is logical that if the only way you can meet your revenue needs is by selling commercial software then your open source business model is broken. Don’t say “pure” open source doesn’t work if the problem is you can’t run your business properly.
There are several other things that just slapped me upside the head:
The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a ‘pure’ open source project could provide. In this way the community profits directly from the company and its customers.
If he means that an open source project with a commercial backer has more functionality, then I’d say “well, duh, of course”. But there is no reason that making money on an open source project is in conflict with being “pure”.
The customers gain higher quality software at a better price. The customers profit from the open source community’s ability to produce high quality software.
In the first statement he implies that in order to produce high quality software you have to have a commercial entity producing it, but then here he states it is the community that produces the high quality software. Which is it?
As far as price, nothing could be better than free, I agree. But if he is talking about customers having to buy enterprise versions of “open source” software the math gets a little hazy.
For example, in our space OpenNMS provides unlimited Standard Support for US$14,995 a year. Zenoss, an open core company, charges US$150/device for a minimum of 250 devices for its “enterprise” software, or US$37,500 a year, over twice as much as we do and limited to 250 devices.
However, if you take our average commercial install of 2000 devices, the Zenoss price would be US$300,000 per year. That is insane – you might as well buy OpenView or Tivoli. Over 5 years the cost will be must less than the US$1.5 million Zenoss will charge. Of course, no one should be paying list price for their software, but it is so wrong to call it open source even if you can haggle it down.
A prospective customer should not have to learn about open source in order to become a customer. The sales and marketing materials should neither hide their open source model nor require understanding of it by the market.
Why shouldn’t a prospective customer “not have to learn about open source”? Aren’t there some serious advantages to open source? That’s like saying Toyota shouldn’t educate its clients on the hybrid synergy drive on its cars. True, the customer shouldn’t have to be able to build one or understand exactly how it works, but I would think the basics of why you would want one should be explained early and often.
Educating the market will be the downfall of the open core business model once people realize that there may be “pure” open source offerings that do it better. After listing the benefits of open source so well in The Principles of Open Source why does Dixon feel it is not important to the buying decision?
Customers are not bees, bees are not customers, and you cannot convert one to another.
With OpenNMS a good portion of our clients are also actively involved in the community. In fact we encourage this. Many, if not all of our customers came to us from the community. With our commercial support offerings, however, there isn’t a requirement of community involvement. What I get out of this statement is that the single vendor company sees the community (the bees) and their customers as separate things, and will focus on the needs of the customer, in order to generate revenue, versus the needs of the community.
Some people assume that all commercial open source models are flawed because the company does not have direct control over the direction of, and development of, the software … The services/support model does suffer from this. The company might pay for full-time developers to work on some of the open source projects that it utilizes but it does not have the same level of influence that the single-vendor model provides.
This has not been my experience. The statement that single-vendor (open core) models have more influence goes back to my plantation owner analogy – the sharecroppers/bees/community are told what to do since the plantation owner controls everything. At the OpenNMS project, influence is based on merit. We have a number of full time developers who both create code and help integrate the contributions of the people outside of our company. Since we get to work on it full time we produce more code which earns us influence. However, every major project decision is governed by the Order of the Green Polo, which got there also on merit (and not always by writing code).
It seems like in the Beekeeper model influence is bought. You, the community, do what I say since I pay for everything. And, by the way, I have to sell software in order to pay for it. It seems to be the antithesis of the open source communities I’ve known.
In summary, I do think the need for a “whole product” is valid, but I don’t think it is necessary to sell commercial software licenses in order to deliver it. The “Honey Gatherer” can deliver the whole product without resorting to commercial software licenses.
Part of my antagonism toward the model comes from the fact that Pentaho sells an “enterprise edition” and thus is an open core/neo-proprietary company, and since those companies have co-opted the term “open source” I am naturally distrustful. It’s like saying “we love the bees, we need the bees, but no royal jelly for you” and I think that is wrong within an open source environment.
But this model is slick and well written and it did make me think, which is always welcome.