Open Core Ventures starts commercial open source software (COSS) companies and prefers the open core business model.
The open core business model is a method for monetizing open source software. It includes a “core” version of the software that is open source and a commercial version that includes additional features and functionality that are proprietary and source-available.
In contrast, support and services-based COSS companies (Red Hat) only produce open source code but charge subscriptions for support, training, and implementation services.
Open core companies are outcompeting closed software and will replace closed-source proprietary software as the default model.
Open core has an advantage over closed-source software because it enhances trust and R&D velocity. With open source software dominating more and more of the market, closed-source software companies will be at a disadvantage because more users will expect to be able to inspect, modify, and contribute to the software they use. Open core software will become the default because it’s more secure, modifiable, and benefits from faster R&D velocity. In the future, people won’t trust closed-source companies when there are open core alternatives
Andrew Lampitt coined the term in 2008 after he noticed there was confusion in the industry around dual licensing strategies, and as a result, they were getting a bad rap due to what was perceived as bait-and-switch tactics. The problem, he argued, was that dual licensing doesn’t accurately describe the approach as an emerging business model. Open core does not claim to be open source—it is a business model that builds alongside an open source project.
Characteristics of open core
- The open source version is actively developed alongside any proprietary code
- Proprietary code is source-available. Users can contribute to and modify the source code but must pay a licensing fee to use it.
- There’s a significant price difference between the open source version and the commercial version.
- Quicker adoption of the product because people can use it for free, and the free version works.
Deciding what is open source and what is proprietary has become a point of tension in open core. Segmenting features based on user instead of features is considered best practice.
Most companies do not pirate software.
There is a risk of increased piracy when making proprietary code source-available. The risk is generally low and outweighed by the community contributions and customer trust you will receive in exchange for providing access to the code. Those willing to pirate software are unlikely to pay for software regardless.
Buyer-based open core is a framework for determining which features are open source and which are proprietary. The BBOC method places features into tiers based on the most likely user. There are typically three tiers, and the order of increasing cost and tiers is based on the buyer. Features that appeal most to an individual contributor are open source and free. Features that appeal most to management or an executive are proprietary, and you charge the highest amount of money. It's no longer about "Where is that feature technically?" Or "How much more work was it to make?" Or "Where in the repo does it live?" It's about the end-user.
📹 Watch the full presentation on Commercial Open Source Business Models.
- Features are consistently added to the free and open source version.
- You can serve different users with a single use case by building propriety functionality on top of existing open source features. For example, you have a collaboration feature that is free to use, but approvals are paid.
- Executives are least likely to contribute to open source and have complicated use cases. They pay for features that meet their specific and possibly unique needs.
- Executives are the least price sensitive. You can charge a lot of money for the features an executive needs.
With buyer-based open core, the plan scales with the highest-tier user. Everyone within a company is on the same plan and gets the same features even if they don’t use them. The disadvantage of buyer-based open core is that it's harder to keep the open source and proprietary code separate.
The opposite of buyer-based open core is module-based open core, where features are separated based on functionality.
Module-based open core tends to have:
- Few proprietary features
- Features that are either open source or proprietary
- Price-sensitive buyers
- Frequent open source contributions from users
Module-based open core makes it harder to create proprietary features because functionality within the product is either solely open source or solely proprietary.
Many people agree that open source software has become the cornerstone for all software.
- Inspect the code. What does the software do?
- Get an opinion of how secure it is, inspect it for security
- Run it myself on a virtual private cloud; control the data
- Modify it. Technically and legally
- Access to the software if the company goes away. (It’s possible to access proprietary software after a company dissolves, but it requires a complicated escrow process.)
- Contribute an improvement.
- Benefit from other people’s improvements.
- Reduce the risk of lock-in
- Depend on software - important to our lives.
- Argument: The open core model exploits open source.
- Our take: Open core is a way to sustain open source by allowing passionate creators to monetize their efforts. Open source users benefit when a company backs an open source project via an open core business model because dedicated resources are allocated toward supporting the open source version. Contributors can get paid to work on the project.
- Argument: Open core companies are competing against themselves.
- Our take: Developing an open source version of the product accelerates adoption and acts as an on-ramp to the paid version.
- Argument: The threat of the hyperscalers has dampened open core success.
- Our take: Freedom to create and compete is part of the open source ethos. It’s true that an open core company opens itself to more competitive risk than a closed-source product. The benefit of building with open source is innovation speed and the tradeoff is allowing direct competition. In the end, the users determine which product is best.
Multi-product open source company (example: Red Hat)
Separating open source
- One way to organize things. The natural way to organize engineers is in the functional parts of the product. Within that, having the open source and proprietary people necessitates making the divisions smaller. Leave less room for specialization.
- INSTEAD a significant amount of contribution from everyone going toward the open source product.