Three Open Source Business Models

Any developer considering releasing open source software needs to have a plan to monetize it. Likewise, any organization thinking about deploying open source software needs to know how the vendor is monetizing it. The reason for the first is obvious, bills and expenses being what they are. As for the later, knowing exactly how developers of code you're thinking of using are funding their efforts will not only help you determine whether the project will remain supported for years to come, but will help keep you from walking into traps such as vendor lock-in.

There are three primary business models being used by open source vendors. However, before making a decision on what model is right for you, seek legal counsel. Not only is the law complex, IT easily crosses jurisdictions that the law does not.

Dual-licensing: This model is based on the premise that it's your code and you can release it under as many licenses as you like. With dual licensing, an application is released under an open source license but is also made available under a separate proprietary license. The free version is used both to get potential customers in the door and to get the word out about a product. The proprietary release might contain extra features, include a service contract, or offer the right to embed the application within another proprietary product.

It's important to note that to use this model, all of the code within an application should either be owned by you, or be covered under a "permissive" license that allows the code to be made proprietary. Also, developers taking this route would probably be best advised to license the free version under the GPL or another so-called "copyleft" license to avoid the unintended consequence of another developer creating a competitive proprietary product on the back of your code.

Support and services: (Also called Professional open source.) This is the method that Red Hat has perfected to become the world's most successful open source company. It's also widely employed by IBM. With this model, the software generally remains free, with the project being monetized through avenues such as technical support, training, and/or customization. In some cases, a company might only make the source code freely available (as required by most open source licenses) and include the installable binaries as part of a service contract.

This model typically works best with software designed for mission critical business deployments.

Open core: Users of this model offer free open source software with limited functionality that requires the use of paid proprietary extensions or plugins to make the product useful. Although this model is used successfully by some vendors, most open source developers find it unsustainable in the long run because of its "back door proprietary" nature that usually comes complete with vendor lock-in.

In the first decade of the 21st century, many open core products were being marketed, mostly as a way of bringing new life to long in the tooth proprietary products (hence the derisive alternate term "proprietary relicensing"). In recent years, the model is not very pervasive.

There are other ways of monetizing open source, most being variations on the three models listed here and others depending on crowdsourcing or other donation methods. With the current focus on IoT and the Cloud, it's inevitable that new models will be developed, so stay tuned.