As users or customers of Open Source software, we don't always see that there are different types of Open Source. The license is one key element of differentiation, since it gives the user different rights. I won't discuss the licensing per se in this post, but will discuss the different business models adopted by companies creating Open Source software.
It's been quite clear for any person analyzing the Open Source business, that releasing software as Open Source is a great way to gain traction and adoption, and that the more permissive your license is, the more adoption you can get. This is of course only true if your software is interesting in itself (I'll have another post on that).
When you create a company, you know you can't live just from creating software and releasing it for free. There will be a need to finance the development of the software, as well as the employees of the company. I'm separating these two because the development of Open Source software is not entirely funded by the company, and the bigger your community is, the bigger is the share of the software that's financed without relation to the company.
I will also look only at the business models of companies built around one software product, which is the sole business the company is in. However there are other business models built around working with multiple Open Source software products, which are different from having your sole revenue coming from one software product.
A few business models are available to companies that want to live based on the Open Source software they create:
- providing services and support on top of a fully open source software with a permissive license and that is downloadable for free
- providing a branded version of the open source software (not downloadable for free, but still open source) similar to the RedHat model
- providing a proprietary license of the open source software (called Dual License)
- providing an enhanced proprietary version of the open source software (called Open Core)
- or a combination of all
Each of these models have advantages and drawbacks when it comes to adoption and generating revenue streams.
In the Services model, all the software is open source, the source available on the net, and the software freely downloadable, while all the revenue is generated by services (including Cloud offerings).
In the RedHat model, the adoption is reduced, as there is no download (RedHat relies on the Fedora community for adoption), but it makes it more complicated for customers to use the full RedHat software for free, which generates more revenue streams.
The principle of the dual license is to limit the usage rights of the software by opting for a less permissive license (GPL or AGPL), use the traction of the Open Source community (so there is still adoption), while generating revenue streams when the user wants to combine the software with proprietary software. This solution also reduces competition by limiting the ability for competitors to add proprietary modules to the software, while the copyright owner can do it. This is why often this model is combined with the Open Core model explained below.
The Open Core model is about having a less featured version that is Open Source on any license, including very permissive ones, while the main developer of the software has an enhanced version of the software, which is proprietary. The enhanced version can also be serviced on the cloud.
All these models are Open Source in the sense that at least a share of the software is Open Source. A little analysis of the history of Open Source companies show that there is a tendency to start with the most open model, so that traction and adoption are high, and then later move to one of the subsequent models. This is not very different from web services being offered for free, without ads, and then offering a choice of ads, additional services or even stripping the free service all together.
So if you are a user planning to invest in installing an Open Source software, or even decide to participate in the community and help the development of the Open Source software, you need to make sure that you are investing in the right solution, namely a solution where your investments are protected. This means you hope the software will still exist, still be open source, will be actively developed and that the community will still be thriving.
There is nothing wrong in itself for a company to make its model evolve. What is wrong however is to mislead the users in thinking that the "open" model will be sustained. Users need to be informed what options are considered to monetize the open source software in the future. Businesses are not non profits, and it's normal that they look for profit, but it's not ethical to look for optimization of the revenue stream at any cost, and particularly at the cost of having mislead the users. Note that if it's a survival issue it's another story, but in most cases it is not, it is purely optimization and that was often the plan since the beginning.
Moreover, I believe that the Open Core and Dual Licensing models hold in very high risks themselves of progressively having the company direct most of its investments towards the proprietary business. With the Open Core business model the maximization of profits will mean pushing more and more to undermine the Open Core component and make it less ready to use, so that the relative value of the non open source version will look better. Even if the proprietary modules are small in size and additions on top of the base product, there are risks of slipping towards more and more proprietary. With the Dual Licensing model, there are revenue streams from OEMs and this can create significant revenue streams, like the MySQL business has shown. Unfortunately the slip towards Open Core is easy. This is visible in Oracle's latest move of creating proprietary extensions (http://monty-says.blogspot.com/2011/09/oracle-adding-close-source-extensions.html). Interestingly in this case MySQL used to have a shareholder agreement forbidding it, but this agreement didn't survive the takeover. With this model, since the rights are fully owned by the Dual License holder, the non Open Source version is not even a creation on top of the Open Source version, but it's merely a fork, for which the copyright holder is the only creator, thus reducing competition.
Moreover, what is really bad, is that when the company starts to slip it's model towards a more closed approach, the contributors either move away from the software for another more open software, or fork the code base into a competitive software. A more open approach will always bring more contributors.
The other two models I described don't have this issue of slipping to proprietary as long as the license used does not allow closing the software later on (GPL and LGPL without Dual Licensing are such licenses, while BSD or ASL type licenses allow to close the software later on). I like to say that these models are "Real Open Source", although in this case the "Real" is more about sustainability.
As I said there is nothing wrong with deciding to opt for these business models, but what is wrong is to change and close progressively the model. This is why users should be aware of the model used by companies, of their commitment to these models and of the possibilities the companies have to close the software. This won't fully guarantee the sustainability, as the company can also fail, but at least they won't be disappointed when seeing the company close-source a software which was perfectly sustainable. Unfortunately many companies use the buzzword "Open-Source" to make themselves look "Open" whatever the amount of Open Source code and whatever the long term intentions are. It would be interesting for the level of commitment to be disclosed.
This has motivated XWiki SAS to publish its code using the LGPL license, without Dual Licensing, to have binary downloads of our software that are fully usable in production with a very simple installation process, to commit to our model in our Manifesto, and to support the reversibility of our cloud offering, allowing to install the same version locally as open source software. These commitments put XWiki SAS in the first category of the described business models. However, we don't exclude using part of the RedHat model for some additional modules or to package a branded version of our software, but we are committed to having this software fully open source.
Ludovic DUBOST
XWiki Founder and XWiki SAS CEO
