A standard pricing model for open core
Open core has been hotly debated since before Andrew Lampitt coined the term in 2008. Before then, it was called dual licensing, described as when a vendor owns a codebase and licenses it under both an open source and commercial license. Adam argues that the name change was “to remove confusion and promote a great business model for open source communities, paying customers, and vendors alike.”
“If you rename what it is called,” he wrote, “you help to remove the ‘bait and switch’ controversy by openly recognizing it as an emerging standard business model with specific attributes associated to it (i.e. GPL core, with commercial extensions).” Adam also explains that the emergence of a standard business model for open source was welcome and necessary. However, he acknowledges that these perspectives often result in a “religious open source war” and it was only a couple years later that the Open Source Initiative (OSI) shared its definitive stance on “open core.”
Objections to open core
According to the OSI’s statement on open core, the fundamental problem is that open core is just a nickname for proprietary software and shares no advantages with the user. The blog post lists six scathing declarations on open core: “‘Open core’ has NOTHING to do with ‘Open Source’. At this point, nearly every proprietary software product has various degrees of open source-licensed source code in its core.” The statement declares that open core puts the software user at a disadvantage in the same way that all proprietary software does and calls open core companies that claim the advantages of open source deceitful.
I agree that open core ≠ open source and that open source software is eating the world. The difference between open core and proprietary software is that open core produces a substantial amount of open source software, whereas solely proprietary software produces none. They both offer open source maintainers a way to get paid for their work, but open core contributes back to open source. Source available carries more advantages to the user than closed source. Most open core companies put a lot of effort toward maintaining the core. Therefore, open core is better than proprietary software for all of these reasons. The argument isn’t open core over open source, it’s open core instead of proprietary.
A framework for feature segmentation
The perception of open core as faux open source is perpetuated when companies aren’t transparent about pricing models. While most open core companies will have a statement of intent regarding their relationship to the open source project, they usually don’t disclose how they place features and functionality. When open core companies aren’t explicit about their pricing model it causes confusion and mistrust.
One of the questions I get asked most frequently about starting a new open core business is, “What features do I make open source, and which should be proprietary?” Yet, Adam Lampitt gave us the framework in 2008: “Some say that this dual license strategy is OK, but as long as you follow the spirit of segmenting by user base, not features.” I call this buyer-based open core and have been using this model to build GitLab since 2015. It’s the model we strongly encourage at OCV.
Buyer-based open core is a framework for determining which features are made to be open source and which are proprietary, based on who cares most about the feature. Features that appeal most to an individual contributor are open source and free. Features that appeal most to management or executives are proprietary and not free. 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.
For example, the merge request feature in GitLab is free and open source, but the merge request approvals function is not. The rationale is that managers are more likely to care about approvals than individual contributors. While it’s not a completely objective framework, it provides a baseline that any company can adopt. It positions the question of open source or proprietary around which type of user gets the most value and begins to negate the bait-and-switch arguments.
Deciding which features to monetize can make or break a business: The worst-case scenario is giving too much away for free, and the business can’t sustain itself. The second-worst-case case scenario is to build a company on top of an open source project and never contribute back. This is a balancing act and companies are bound to get it wrong sometimes. Resist the urge the to move features from the open source version into the licensed version. Doing this completely erodes trust. Use feedback from the community and users to refine where you place features as you build.
The buyer-based model provides guard rails for companies so they don’t overcorrect in either direction. It’s a monetization strategy that enables business growth while furthering the open source movement.
Good for business ≠ bad for open source
An open core business that builds on an open source project unlocks resources for the project that it may not get access to otherwise, allowing the project to grow and innovate more quickly. The business meanwhile gets a return on investment in the core project, with the benefits of a community and their contributions that improve the core. Where they make money is by charging users who are also using the project for financial gain.
Founder and CTO of Authentik Security Jens Langhammer commented in the announcement about forming the company built on his open source project: “There are many things I wanted to do but couldn’t because I didn’t have the time. I’m excited about the opportunity for people to work full-time on the project. Both the future enterprise and open source versions will benefit.”
While open core may produce proprietary code, it does so alongside a fully operational and maintained open source core. It sustains open source and the contributors who pour their time and effort into creating it.