The Open Source Honey Blender

Thanks to the thoughtful posts of Roberto Galoppini About the Open Source Whole Product Concept, I’ve just finished reading the latest, version 2 of James Dixon’s The Bees and the Trees.

Over a great dinner at the Water Bar with Roberto after the Open Source Think Tank last March, I remarked to him that the creation of open source taxonomies can turn into an intellectual game that is mostly followed by pundits, becomes a bit silly if taken to extremes, and is of questionable relevance to customers.

So now, after reading The Bees and the Trees, I’m going to do the very thing I was skeptical about last month and sketch out another open source business model taxonomical distinction. (I’m sure there will be those among the readership who think we need this about as much as we need yet another Linux distro).

I think there is another model between James’ Beekeeper (single vendor) model of commercial open source and the Dixon/Aslett Honey-Gatherer (services/support) model of commercial open source.

I call it the Honey Blender.

[Warning: the commentary below assumes you've read The Bees and the Trees.]

Like a blended scotch whiskey, a “whole product” offering can be made by combining the honey made by domesticated bees (a la the Beekeeper model) and by gathering wild honey (a la the Honey Gatherer).

GroundWork follows this model, although we’ve tended to call it the ‘amalgamation strategy’, while Roberto has referred to it as a ‘hybrid production model‘.

Red Hat is also a Honey Blender, combining code made in their own beehive with code developed in the GNOME, GNU, etc beehives into a whole product.

In this model, the customer still gets honey and the honey ‘comes in a jar’ (per Dixon). However, because the honey comes from many different sets of bees (domesticated and multiple wild beehives), the Honey Blender needs to be able to interface with and nurture many different bee populations.

This is definitely more complicated than the Beekeeper approach, but it does yield a wider mix of honey/code flavors that can be combined to make the whole product.

Also, because not all of the bees are domesticated, it allows for leaner business operations and more efficient engineering, the savings of which can be passed along to the commercial customers. In fact, in the monitoring space, one can argue that a single vendor approach is going to have a hard time reinventing the wheel from scratch in a way that can compete cost-effectively with the sunk costs of code and breadth of features already written (often over decades) by the likes of HP OpenView, IBM Tivoli, and the other ‘Big 4′ systems management vendors.

For complex categories like enterprise data center management (encompassing monitoring, asset management, trouble ticketing, provisioning, etc) the Honey Blender approach may be the only realistic option.

Feedback? In addition to the comments below, you can tweet me @davidpdennis or mail me at ddennis at gwos dot com.

David