Open Core Business Model
Open Core Ventures Handbook/Open Core Business Model

Open Core Business Model

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 by default

Many people agree that open source software has become the cornerstone of all software. 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
Video preview
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

  1. The open source version is actively developed alongside any proprietary code
  1. Proprietary code is source-available. Users can contribute to and modify the source code but must pay a licensing fee to use it.
  1. There’s a significant price difference between the open source version and the commercial version.
  1. 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. Buyer-Based Open Core, where features are segmented based on users instead of features, is considered best practice.

Buyer-Based Open Core (BBOC)

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.

Advantages of Buyer-Based Open Core

  1. Features are consistently added to the free and open source version.
  1. 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.
  1. 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.
  1. 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.

Module-based Open Core

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.

Managing Open Core

Some people believe the open core model exploits open source. At OCV, believe 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.
Another common concern is that open core companies are competing against themselves. In our experience, the opposite happens: developing an open source version of the product accelerates adoption and acts as an on-ramp to the paid version.
Pirating
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. Most companies do not pirate software.
Hyperscalers service-wrapping
Open core companies do face the risk of service-wrapping from the hyper clouds. Freedom to create and compete is part of the open source ethos. An open core company indeed 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.
The best way to manage this risk includes developing application software and adopting a buyer-based pricing model.
Infrastructure software (MongoDB, Confluent, Redis)
Application Software (Wordpress, GitLab)
Fork & Commoditize Resistance
Application Programming Interface (API)
Graphical User Interface (GUI)
GUI is more complex to replicate than API
Single-tenancy
Multi-tenancy
Hyper clouds are better at running single-tenant software
Needs lots of compute power
Needs little compute power
Hyper clouds are in the business of selling compute and storage. Applicaiton software tends to drive less compute.