sorted by: recent | see :
popular
Content Tagged dixon
The vocabulary of open source development models
James Dixon has given the thumbs-up to my stretching his Bee Keeper analogy to explain open source development models (which is nice) and in doing so has suggested a new term to help quickly explain the difference between vendor- and community- dominated development projects.
The debate about the difference between the two approaches, and the language used to describe them, has been simmering for some time. For some background on it, and an explanation about why it matters, see Ted Ts’o’s post from April.
While the debate may seem like a matter of semantics I agree with Ted that it is important in terms of framing a user’s expectation and understanding of an open source project/product and its potential relationship with the vendor.
This is not to say that one approach is better than the other, but that for some adopters (both corporates and individuals) it is important to know that MySQL is the majority contributer to the development of its database and has the rights that go along with that, while other adopters may be more comforted in knowing that PostgreSQL has a broad and vibrant community.
My perspective is that it is important for (some) customers to be able to understand the distinction, and for that an agreed vocabulary is essential. For an example of why vocabulary is important, consider the role of Cathedral and the Bazaar in providing the industry a vocabulary with which to explain open versus closed development models.
It has occurred to me recently that open source is missing an agreed vocabulary for discussing both development and business models (I’ll leave the business models for another time). The problem, of course, is coming to an agreement.
In his initial post on the subject Ted used the terminology “organic” and “non-organic”, which does work, although as he discovered, some found the term non-organic a little pejorative.
An alternative, suggested by Alex Leverington and originally used in a Harvard business school paper (PDF) is “organic” versus “synthetic”.
While that terminology is probably more accurate it too has some potentially negative connotations. I personally have used the phrases “captive” and “community”, of which the former has obvious negative connotations as far as vendor-led projects are concerned.
In his post referenced above based on my stretching of the Bee Keeper analogy, James Dixon suggests “wild” versus “domestic” could potentially be considered derogatory as far as the community-led approach is concerned. Meanwhile, Ted’s request for suggestions generated a number of possibilities.
Here’s a list of the potential candidates I’ve identified. Take your pick, or feel free to suggest any others:
Applying the Bee Keeper model beyond captive open source projects
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.