Commercial Open Source Business Models
A post on the 451 Group blog made me think about commercial Open Source business models, and the consequences.
The growth of Open Source has convinced a lot of companies to open their software, but you cannot make money by giving stuff away. Red Hat was one of the first companies to create a viable business model based on support licenses. This model has now branched into several variants.
This is not the whole story. Open Source strategy also depends on environment and infrastructure. Does a company provide a place for community support? Do the developers answer questions there? Does the company give back to the projects it uses? The license used for the code also influences things. Sometimes a combination of GPL and a commercial license is used with the specific goal of making the Open Source version less attractive.
Why licenses
Let’s start with a short answer to the question why you, as a customer, need a license for a product that is essentially free: the gist is that Open Source software comes with no guarantees.
Say you hire company B to implement a solution on top of Open Source product A. Company B will only be able to guarantee their code that was written to adapt product A to your needs; essentially configuration and customization. You’re left with a large chunk of unsupported code.
Because it’s Open Source, you can hire your own developer to look at the code and fix bugs for you, but this usually doesn’t work, and isn’t recommended (in enterprise environments/for longer periods of time). Instead you buy commercial support from company C who are, not surprisingly, usually a company that invested a lot of development time into product A. Got it?
These are some common ways this takes place:
Support License
Taking the ’software is a service, not a product’ paradigm literally, your software is free (the product), but you charge for the support licenses (the service).
There’s a lot of education involved here: you have to sell the necessity of the support license to your customers, and basically leave it up to them to ‘do the right thing’. This is sometimes combined with partnerships that disallow work on unlicensed installation, but also obfuscates why a customer needs to buy a license.
Community/Enterprise
There is a free Community version with an Open Source license that is unsupported. The Enterprise version is functionally the same or similar, but it’s considered tested and supported, and comes with a commercial license.
This dual licensing setup is often used with GPL because it is more restrictive on commercial use. I wonder, if you share the code base, how you contain the viral aspects of GPL to just the community version though.
Freemium
The free version has limited functionality. If you want to extend this, you get the paid version. This sounds worse than the previous option, but in a lot of cases it’s more transparent. It hinges on the definition of ‘limited functionality’: don’t expect old school nag screens or timers. Usually what you get in the free version is good enough for most users, and the enterprise features you do have to pay for actually are features you would only use in an enterprise. So this is dual licensing with functional differences.
Open Core
There is an open source project that provides the core of the software, but the actual project doesn’t provide a free version. In the patron model of the 451 blog, the company provides developer time and infrastructure to the Open Source project, adds proprietary features to the Open Source core, and sells the result commercially. There are caveats, though: there is no direct link between the Open Source project and the company, so the company doesn’t have to provide anything. Also the money you pay for the commercial product might not end up benefiting the Open Source project. This lack of transparency is troubling.
This has been a quick write-up outlining several commercial Open Source business models. Note that there is no preferred model, and that there are many other factors you should consider when picking Open Source software, an implementation partner and a support license.