If there is a constant in this research area, is the fact that everything is constantly changing. While we debate about whether mixed models are really that important or not, or while free software experts are fighting against brand pollution, I still find amusing the fact that most of what we debate will be probably not relevant in the future at all. Exactly like the initial car models, that resembled the horse-driven carriages that were planning to supplant, some actual OSS business models are half-hearted attempts at bridge the gap between two different worlds, with some advantages and disadvantages of each.

All OSS business models are based on the idea of monetization of a code base, and this monetization can happen in many different steps of the acquisition or use process. Monetization of services, for example, usually happens in the initial adoption step through training and set-up fees, while support monetization happens in the long-term use phase (and in large scale companies tend to be limited in time, as the internal IT staff becomes more and more expert at the infrastructure, and the need for external supports reduces with time); sometimes monetization happens elsewhere (like Mozilla and Google).

Mixed models try to leverage the R&D cost reduction that is inherent in the OSS process, while at the same time maintain the easy and clear proprietary licensing model, where there is a token-based monetization (per CPU, per user, per server, and so on) that is not related to an inherent limitation of the software, but is an artificial barrier introduced to prevent free riding. This, however, introduces the disadvantages of both models into the equation: developers working for a commercial company are reluctant to participate in a project that has a clear potential for third party exploitation, while non-employed developers may be more interested in contributing to more “libre” projects. On the adopter side, the user is not allowed to experiment with the full version of the software, and may not be interested enough in trying the OSS version if the difference in terms of stability and features is too high.

That explains why mixed-model vendors claim that basically no one contributes code to their project (thus neglecting all the non-code contributions, that in some cases are significant), while vendors that select alternative monetization approaches seem to fare better. Pure OSS products are in fact more efficient (and tend to allow for higher company competitiveness), and even vendor-backed projects like Eclipse receive significant external contributions (IBM has only 25% of the active committers, for example).

About the claims that mixed models or open core approaches are the norm, I still stand on my numbers, that shows that less than 25% of the companies use this approach to monetization. Also, the companies are adopting a more softer stance on open core; while a few years ago the code available under the non-OSS license was a substantial part of the functionality of the full product, now the vendors are using many separate non-functional product areas and put them together to create the proprietary product, like certification, stability assurance, official support and sometimes additional code for ancillary activities like monitoring and high-end features like clustering (Alfresco recently announced such a change).

As the horse, carriage and cars example I made at the beginning of this post, I believe that these are steps taken in trying to approach and adopt the optimal model; in this sense, I believe that a better approach is to clearly divide the “core” and “non-core” groups into separate legal entities, with differentiated governance models. In particular, I believe that a more efficient approach is:

• To have a core, Eclipse-like consortia that provide clear, public, transparent management of the central open source part of the project. As for Eclipse, while initially the vendor dominates in terms of contribution, after a while (and in the presence of a healthy external ecosystem) contributions start to reduce the R&D cost – in the case of Eclipse, over 75% of the code commits are from outside IBM.
• To have a separate, independent unit/company that provides, under a traditional proprietary license, the stabilized/extended software without any confusion about what is open source and what is not. It will not be “mixed model”, “commercial OSS” or whatever – just proprietary software. Or, if the offer is service-based, it will be a pure service contract.

I strongly believe that this model can not only put on a rest the entire “mixed model” or open core debate, but can also provide significant productization benefits, by reducing the contribution barrier that so many OSS vendors are experiencing right now. By creating an ecosystem of “development consortia” it will also be possible to increase coordination opportunities, that are sometimes stifled by OSS vendors that pursue independent agendas; it will also reduce customer confusion about what actually they buy when they receive an offer from such a vendor.