I’ve been reading The Bee Keeper (also here in PDF), an explanation of the relationship between professional open source software (POSS) vendors and their communities, written by Pentaho’s CTO James Dixon. It is a very elegant explanation of the development/business model employed by the POSS vendors such as MySQL, Pentaho, JBoss and Alfresco.

James uses the analogy of the Bee Keeper to explain the model. It’s worth reading the paper in its entirety to understand just how appropriate this is but to put it very simply: the vendor is the bee keeper; the community is the bees; the open source project is the honey; and the customer is after processed honey (supported open source software). In order to be successful the bee keeper must satisfy the customers but also the bees, to ensure that they do not leave the hive, or sting him.

The analogy goes much deeper than that but you get the idea. One of the limitations of the Bee Keeper model, as admitted in the paper, is that it applies only to vendor-dominated (some would say captive) open source projects. As James writes: “This model does not apply to POSS companies with service/certification models such as Optaros, SpikeSource.”

I’ve been thinking about that, and while the Bee Keeper model does not apply, I think the analogy of bees and honey can be adapted to fit both the service/certification models and hybrid/proprietary extension models, as well as explain the approach taken by vendors that support or build on community-led projects such as Apache or PostgreSQL.

The answer comes from the fact that, as well as man-made hives, wild bees also produce honey in bee nests, from which the honey is available to everyone who fancies trying to extract it.

If we assume that there is an abundance of bee nests (and I would describe 179,979 SourceForge projects as an abundance) and that many of these nests are both mature and highly productive (like PostgreSQL and Apache) then we begin to see how a business model could develop based on the collection and processing of wild honey, rather than man-made hives.

There are some consumers (adopters) that might prefer the taste (and low cost) of wild honey and are happy to go to the effort of collecting it and processing it for themselves. However, if they do not want to take the time or the risk to do so instead they might pay a honey collector (support provider) to do the job for them.

While the honey collector does not have responsibility to look after the bees that a bee keeper has he will have to take care not to disrupt the nest and may well choose to make an effort to nurture the nest and encourage honey production. Of course, as these are wild bees there is also always a risk that the bees will leave the nest or production will dry up.

The collector is also aware that any improvements resulting from his efforts are available to everyone and rivals can easily set up alternative honey collection businesses. A solution to this problem is to add more value beyond the pure honey and/or use the honey to create something else, with the honey collector adding some proprietary know how of his own to create a related product.

If we accept the accuracy of Wikipedia’s statement “most commercially available honey is blended, meaning that it is a mixture of two or more honeys” then we begin to see how there is a role for honey collectors to become blenders (service/certification providers) that pick and choose honey from a variety of freely available bee nests and blend it together to produce a more palatable product.

Taking this a step further there is also an opportunity to create a completely different product. An example would be a brewer of mead. A brewer could of course choose to develop his own honey using man-made hives or acquire honey from a bee keeper, but by exploiting wild honey he lowers production costs and focuses on the additional value he brings to the production process.

EnterpriseDB is a great example of these models in action. The company is a honey collector - offering technical support for existing PostgreSQL deployments for those that want some extra peace of mind, while its Postgres Plus and Postgres Plus Advanced Server products are based on the community-developed PostgreSQL database.

EnterpriseDB is also a blender. Postgres Plus includes the core PostgreSQL database, as well as additional free and open source packages, such as open source database migration tools, grid capabilities and geo-spatial support. These technologies are also available for free, but customers are prepared to pay a fee to have the company combine and support them. Other examples of open source blender companies would include Optaros, OpenLogic and SpringSource/Covalent, or even larger services providers.

Meanwhile it is also a brewer – adding proprietary extensions such as migration tools, Oracle compatibility and dynamic tuning to create Postgres Plus Advanced Server. These technologies are only available from EnterpriseDB and come at a price. Other open source brewer companies include IBM, Greenplum, Netezza, and Datallegro.

As EnterpriseDB shows, it is possible to follow more than one model at the same time.

Does that make sense or have I stretched the analogy too far? I am really thinking aloud here so it is quite possible I’m talking out of my a―nyway, let me know what you think.

By the way, in The Bee Keeper, James also writes: “I don’t know how applicable it is to POSS companies with distro models such as Red Hat Linux and SuSE Linux.” I’m with him on that one. The Linux kernel/Fedora/RHEL model introduces a two-tier hive/nest and whichever way I think about it, the analogy doesn’t seem to fit.