Open core is a monetization strategy for open source, where in addition to the open source version, often called “community,” there is an extended version, often called the “enterprise” version, with additional features. There is a lot of value for users of the open source version when this model is used, as it tends to be the base for the proprietary open source version that is maintained well with prompt bug fixes and security updates as well as innovation in the areas which a vendor chose not to reserve for their proprietary open core version.
There is a potential for conflict, though: what if members of the community want to contribute features implementing similar functionality to what is only available in the open core enterprise edition? Well… they are likely to be rejected. At Percona, we have seen it in the MySQL space, having developed a lot of MySQL Enterprise functionality equivalents for Percona Server for MySQL, which we would love to have been merged upstream (MySQL Community) but which Oracle, not surprisingly, has no interest in.
Recently there was another public rejection by Hoppscotch of a community-contributed feature, causing much dislike by the community.
While refusing to include high-quality, community-developed features because they reduce differentiation of your open core version expectedly pits you against your community, it is also quite expected. If you choose to use open core for monetization, you need to create and maintain the difference between open source and proprietary product versions. It is also very natural for members of the community to wish for full-featured, well-maintained software that they can use for free.
It is worth noting that “the community” unhappy with the decisions by the project maintainer to reject any contributions has the fundamental right to fork. This happened with a number of products, including MySQL (MariaDB), Open Office (LibreOffice), ElasticSearch (Open Search), and Terraform (OpenTofu), to name a few. I consider this a fantastic defense from the project owner not serving the interests of the community well.
Note, though, that creating a fork is a major undertaking, and very often, you see members of the community complaining about the actions of the project owner but not really willing to put in the time, effort, and money needed to create such a fork.
If you’re a business employing an open core strategy, you would have another question: How do I avoid community blowback and a potential fork? First, you need to be reasonable and understand the needs of your community well and ensure the open source, community version indeed serves the community well, especially those members who can’t afford the enterprise software. Second, it is a good idea to have a clear position on what kind of features you intend to reserve for the proprietary version so community members are not surprised that the feature they put their heart and soul into working on for many months is suddenly rejected for inclusion.
Having said all of this, I think the open core approach is better for the user compared to “Eventual Open Source” licenses such as Business Source License (BSL/BUSL) The reason is simple; with open core software, you have immediate rights to fork the community version if you find irreconcilable differences with the project maintainer, where with BSL, you only can fork outdated and unsecured versions a few years old, where it is practically impossible to “catch up.”
Is there a better choice than open core when it comes to the needs of the community and software users? Yes! Take a look at PostgreSQL, Linux, or Kubernetes. These are open source projects governed by a vendor-independent organization. Then, multiple vendors can create their flavors, and the user is free to choose which one would best fulfill their needs. This ensures that the decision about whether to merge specific community contributions will not be based on the interests of a single business but rather on the ecosystem as a whole. Furthermore, features that do not have consensus about their inclusion can be “incubated” in one of the flavors to prove their worth.
