<aside>

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. Buyer-based open core is a transparent feature segmentation framework to determine which features are open source and which are proprietary.

The buyer-based open core framework segments features based on the most likely user: Features that managers and up want are proprietary, and features that individual contributors want are open source. 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.

Consider the user persona rather than the technical implementation. Management features like access controls, audit logs, and compliance tools naturally fall into the proprietary category, while individual contributor features often belong in open source.

Persona Individual Contributor Management/Executive
License Open source Proprietary
Billing Free Paid
Features Core functionality, sharing, API access Access controls, audit logs, compliance, etc.

List of enterprise features. |

Advantages of buyer-based open core

  1. Features are consistently added to the free and open source version.
  2. 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.
  3. 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.
  4. Executives are the least price-sensitive. You can charge a lot of money for the features an executive needs.

With buyer-based segmentation, 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 segmentation is that it's harder to keep the open source and proprietary code separate.

Features that drive growth are free

Don't put barriers around fundamental behaviors that drive growth. For example, sharing is a viral thing. Keep that free. But after sharing comes the complications. Managers will ask, "Can we limit public sharing? Can we get an overview of what documents are shared with whom? Can we prevent people from sharing documents outside of our organization?" Make sharing wide open by default, but charge for the governance and control features that managers and executives need.

Feature placement decisions are sticky

Feature placement decisions are sticky. Once something is proprietary, internal reluctance to open source it grows over time. When in doubt, don't default to making a feature proprietary, thinking you can open source it later. Likewise, resist the urge 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 worst-case scenario is giving too much away for free, and the business can’t sustain itself. The second-worst-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. The buyer-based model provides guardrails 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.

Module-based open core

The opposite of buyer-based open core is module-based open core, where features are separated based on functionality. Products segmented this way tend to have