The Honey-Gatherer Model for Service/Support Commercial Open Source
The first version of this paper did not include a model to describe companies that use a services or support commercial open source business model. Matthew Aslett of the 451 Group wrote a blog about extending the Beekeeper Model to include these companies.
He suggested that these companies can be likened to honey gatherers that collect their raw material from wild or organic hives.
These honey gatherers produce the same products as the Bee Farm but their involvement with, and contribution to, the bee community is different. Notice that there is no bee farm in this model.
In diagram form the workings of a services / support commercial open source model is similar.
When compared with the Beekeeper Model it is obvious that the resources provided to the bees by the gatherer are different. In the Beekeeper Model the bee farm provides land, hives, and flowers etc. In the Honey Gatherer Model the gatherer goes into the ‘wild’ and finds existing hives from which to obtain raw materials. Likewise the single-vendor commercial open source business provides resources to the community that a services/support business does not. These resources include:
- Initial or ‘seed’ code. This can take millions of dollars to create.
- A sizable team of full-time engineers
- Product managers
- Graphic designers and usability experts
- Development tools such as continuous integration servers
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. 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 valuable.
Since the ‘gatherer’ does writes little (or none) of the software they are not in a good position to effectively control intellectual property and patent-related issues. They also have little or no influence over the direction that the software goes in. These facts can limit the company’s ability to get funding.
In support of this observation, in his OpenGEO blog (http://theopenplanningproject.org/2009/03/the-beekeeper/) Paul Ramsey of The Open Planning Project points out that many potential customers do not perceive enough value in the whole product features alone to convince them to become customers.
Alfresco provides another data point. Prior to March 2007 Alfresco had enterprise features that were only available to customers. They then switched to a services/support model. As of March 2009 it looks, from John Newton’s blog (http://newton.typepad.com/content/2009/03/building-a-stronger-open-source-product.html) like Alfresco is switching back to the open-core model used by many single-vendor commercial open source companies. Newton ends his post with this message:
“We are making these changes in a way that is based on a set of principles that are fair and accountable. We believe in open source and making it freely available and providing choice of not just proprietary systems, but between enterprise and open source. We think the rest of the open source world is heading in a similar direction, because this is what makes open source stronger in the long run.”
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:
- This is not true with the single-vendor model. The only resources that cannot directly be influenced are the community who perform software-oriented roles at a scale and capacity that is orders of magnitude higher than any proprietary organization could do on its own. The core developers and product managers are under the direct influence of the company.
- 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.