carlodaffara.conecta.it

It is now time to write the closing part of our long multi-part look at open source business models. After all the discussion on how to look at the various parts of a model and how to improve it, I will try to summarize a bit on how to look at an OSS business model, and what implications can be made from a specific choice (for once, without mentioning open core).

The basic idea behind business models is quite simple: I have something or can do something – the “value proposition” – and it is more economical to pay me to do or get this “something” instead of doing it yourself (sometimes it may even be impossible to find alternatives, as in natural or man-made monopolies, so the idea of doing it myself may not be applicable)

There are two possible sources for the value: a property (something that can be transferred) and efficiency (something that is inherent in what the company do, and how they do it). With Open Source, usually “property” is non-exclusive (with the exception of Open Core, where part of the code is not open at all). Other examples of property are trademarks, patents, licenses… anything that may be transferred to another entity through a contract or legal transaction.

Efficiency is the ability to perform an action with a lower cost (both tangible and intangible), and is something that follows the specialization in a work area or appears thanks to a new technology. Examples of the first are simply the decrease in time necessary to perform an action when you increase your expertise in it; the first time you install a complex system may require lots of effort, and this effort is reduced the more you experience the tasks necessary to perform the installation itself.

Examples of the second may be the introduction of a tool that simplifies the process (for example, through image cloning) and it introduces a huge discontinuity, a “jump” in the graph of efficiency versus time.

These two aspects are the basis of all the business models that we have analysed in the past; it is possible to show that all of them fall in a continuum between properties and efficiency:

Among the results of our past research project, one thing that we found is that property-based projects tend to have lower contributions from the outside, because it requires a legal transaction to become part of the company’s properties; think for example at dual licensing: to become part of the product source code, an external contributor needs to sign off his rights to the code, to allow the company to sell the enterprise version alongside the open one.

On the other hand, right-handed models based purely on efficiency tends to have higher contributions and visibility, but lower monetization rates. As I wrote many times, there is no ideal business model, but a spectrum of possible models, and companies should adapt themselves to changing market conditions and adapt their model as well. Some companies start as pure efficiency based, and build an internal property with time; some others may start as property based, and move to the other side to increase contributions and reducing the engineering effort (or enlarging the user base, to create alternative ways of monetizing users).

This is the last post in our little mini-serie on OSS business models; I hope that my archetypal three readers will have enjoyed it as much as I enjoyed writing them. Of course, I will be happy to read and respond to any comment – even negative ones.