There are many different mechanisms behind OSS adoption, and understanding the differences makes it easier to help companies in using them efficiently – after all, word of mouth may be sufficient to get visibility, but it may be not enough to guarantee adoption, and then converting this adoption into paid services.
In fact, monetization may require a large number of “adopters” to get a small percentage of “paid users” – in many domains, only 0.05% of adopters pays for services, a percentage that we call “unconstrained monetization percentage” or UMP to make it sound more academic.
While it is true that the incremental cost for the OSS company of having a new adopter is zero (or extremely small), the increased adopters base also increments the probability that the community or some competitor will start to address the same monetization path, thus further reducing the UMP. So, to take the example of MySQL, instead of asking services or training to Sun, an adopter may opt for a local consulting firm that effectively leverage the free availability of the code and ancillary material to create a competitive entry.
Of course, the business model adopted by the OSS firm also has a positive or negative effect on the growth process in the number of adopters; this especially affects firms offering what we called “split OSS/commercial” or “open core” licensing that are forced to constantly adapt the features of the OSS and commercial parts; as we wrote:
“The model has the intrinsic downside that the FLOSS product must be valuable to be attractive for the users, but must also be not complete enough to prevent competition with the commercial one. This balance is difficult to achieve and maintain over time; also, if the software is of large interest, developers may try to complete the missing functionality in a purely open source way, thus reducing the attractiveness of the commercial version. ”
In other words, if the OSS product is too good, few will be interested in getting the commercial part, while if the OSS product is useless, the number of “adopters” will be too low to increase visibility of the product. This balance changes with time, and for this reason companies adopting this model need to constantly update their offering, and evaluate with time how to split the development effort across paid and OSS branches.
As I wrote in the beginning, there are many different adoption processes in open source software; some of those mechanisms are:
- diffusion/dissemination
- cluster propagation
- directed incentives
- enforcement
In the following posts I will try to provide some insight into each, and how to help an OSS company in leveraging the relevant process to help in both adoption and monetization.
#1 by Sandro Groganz - February 24th, 2009 at 11:46
The balance between what is often called an Enterprise Edition (EE) vs. Community Edition (CE) is indeed delicate and a constant process. But it’s worth it, because it allows a FOSS vendor to gradually move Enterprise functionality to the CE once they become commodity features and further disrupt the market by making its CE more attractive.
May I recommend to also label a CE as commercial software, because although a FOSS vendor might not directly earn revenues from it, there are system integrators who use it for customer projects and who might at least buy e.g. training from a vendor?
#2 by admin - February 24th, 2009 at 11:58
Thanks for your comment!
I absolutely agree that open-core is an effective model; I am just not sure about its long-term sustainability. Also, the labelling of CE as commercial software is appropriate, but should be extended to most of OSS: after all, there is no objection on OSS to be commercialized (outside the fringe fanatics).
#3 by Sandro Groganz - February 24th, 2009 at 12:54
Concerning sustainability, Jahia has an interesting business model labeled “sustainable dual licensing”. Basically, when EE customers ask them to develop a generic solution, they recommend to them to make it part of the CE version which allows the customer to save maintenance costs, because Jahia will at no cost take care of any related issues in a production environment. More here: http://www.jahia.com/licensing
#4 by cdaffara - February 24th, 2009 at 13:40
That’s an interesting approach (even as something similar is usually done by other “open core” projects too). I especially appreciated the part in the licensing white paper that says “The idea can be simply stated as: request improvements and we’ll maintain them at no cost within a standard
subscription.” Go tell this to all the ERP vendors that derive a substantial margin from exactly this kind of forced lock-in…