Understanding the differences between community open source, open core, and commercial open source software is important when making choices that lay the foundation for systems and applications, as these decisions can have cascading effects on costs and flexibility for internal users and/or downstream customers.
In this blog, we break down the key differences between these three categories of open source software, and we’ll share some important considerations for teams deploying OSS both internal and external to the enterprise.
Editor’s Note: This blog was originally published in 2019 and was substantially updated and revised in 2024.
Community open source software, also known as Free and Open Source Software (FOSS), is source code owned by a group of volunteers that have organized around a shared problem. Community open source projects are free and open to the public, and they’re bound by a permissive or restrictive license.
Related resource:How Does Open Source Licensing Work?
Open source communities bring people with shared interests together to collaboratively build something. Some of the most popular and widely used community open source projects are backed by nonprofit foundations such as the Apache Foundation, Linux Foundation, or Cloud Native Computing Foundation. Foundations add an air of legitimacy and garner inherent trust among users who might otherwise worry about adopting software built by a disparate cohort of individual contributors.
There are millions of FOSS projects but in the 2024 State of Open Source Report, respondents mentioned Linux, Jakarta EE, Apache Server, Docker, Kubernetes, PHP, WordPress, Python, PostgreSQL, MySQL, Kafka, and Eclipse IDE as among the most business-critical for enterprise.
Back to top
What Is Open Core Software?
Open core is a commercial model of software delivery where a company creates (or contributes heavily) to a “core” version of open source software, allowing users to freely adopt, adapt, and distribute it under an open source license, and then wraps that core version with advanced features, extensions, or enterprise-level scaling and availability under a proprietary license.
This approach allows a company to leverage the collaborative nature of open source to build a community around the free version, which benefits from diverse contributions and widespread adoption. At the same time, they generate revenue by monetizing premium features aimed at larger organizations. This sometimes quickens time-to-market for a more commercially sustainable product.
Examples of open core software include Cloudera Data Platform, Oracle Linux, SUSE Linux, Redis, Grafana, Confluent Kafka, MongoDB, and GitLab.
Back to top
What Is Commercial Open Source Software?
Commercial open source vendors provide professional services for fully open source software. All features and functionality of that software remain open and freely available, and the company generates revenue through consulting, hosting, and support.
Like open core, the commercial open source software approach benefits from the community-built software as a foundation. Although COSS companies likely contribute to the software, they don’t license their contributions separately. Instead, they provide value to their customers by professionalizing the implementation and adoption phases.
RHEL and Rancher by SUSE are examples of COSS.
Get the Latest State of Open Source Report
The State of Open Source Report includes insights, analysis, and trends from a global survey of OSS users working in industries like finance, technology, retail, manufacturing, government, and more.
Download
Back to top
A Note About Open Source Definitions
The above definitions draw clean lines for the purposes of comparing and contrasting open source models; however, some companies employ multiple models across their portfolio. As companies grow and add products, this gets more prolific. In some cases, the lines drawn between these models (particularly COSS and open core) become progressively more gray.
A good example would be Red Hat Enterprise Linux, which is sold under a proprietary license; however, it is made up of code from two upstream open source products (Fedora and CentOS Stream). In this case, it borrows from the open core model, but there isn’t a true single free version that it extends.
Back to top
How to Choose Between Community Open Source, Open Core, and COSS
All these options are based on the open source model, so they all have the potential to benefit from the power of a collaborative and transparent development process. When compared to proprietary internal development or purchased vendor software, all these OSS models can fundamentally reduce cost and time-to-market, while increasing security, stability, and innovation.
With each of these open models, there are costs. The cost of commercial options, either open core or COSS, are more obvious, and come in the form of license fees, maintenance contracts, hosting costs, support subscriptions, and consulting services. However, Free and Open Source Software (FOSS) also has associated costs that are more hidden. Adopting FOSS requires organizations to dedicate internal staff and infrastructure to hiring, acquiring, and maintaining the skills necessary to install, configure, upgrade, and contribute to sustainable development of the free-to-use software. It’s important to not forget about these shadow costs when considering FOSS for enterprise use cases.
The “F” in FOSS stands for free as in freedom, not absence of cost.
Knowing there are costs associated with all options may help organizations focus on the value and predictability of each of those costs.
Here are some questions that can help steer an organization toward a defensible return on the investment:
- What features are included in the commercial edition? Do I need those features? Are there alternatives that can achieve the same result?
- What license(s) are associated with the software? Are they permissive, restrictive, or proprietary?
- Does my organization have the skill and bandwidth to implement, maintain, and support the product?
- How mature is the product and the backing community or commercial support vendor?
- Is there a single commercial vendor that can serve all my open source software needs?
The table below illustrates, at a high level, some of the benefits and drawbacks worth considering:
Type of Software | Benefits | Drawbacks |
FOSS | - Ability to try various solutions without vendor lock-in, thus a low-stakes entry
- Information is shared readily within the community
- Responsiveness of the community for patches and potential vulnerabilities
| - OSS can lack funding to maintain the software and fix security vulnerabilities
- It may only provide a partial solution for your requirements
- Integrating multiple OSS products can be challenging
|
Open Core | - Often more regular updates and patches
- SLA-backed support options, up to 24/7 for mission-critical services
- Legal indemnification and liability during crises
| - Vendor lock-in can happen based on reliance on enterprise features
- License changes could restrict your use
- Restricted contribution models can diminish the value of the community
- Could encounter a liability risk if the product is not upgraded
- Enterprise features, hosting, and monitoring can be costly
|
COSS | - SLA-backed support options, up to 24/7 for mission-critical services
- Legal indemnification and liability during crises
- Maintain full value of the community model
- Value of expert knowledge when you need it, without the associated cost when you don’t
| - Adoption of additional complimentary FOSS packages may be required to achieve Open Core equivalent feature sets
|
Back to top
Final Thoughts
The decision to choose community open source software vs. open core or commercial open source software comes down to the depth and breadth of the projects, budgets, and use cases, as well as the scale of the environment(s). There are situations where it makes sense to invest in commercial backing for open source development and other times when it might be better to implement a community-based solution. The three models outlined in this article layout a spectrum options that cover most needs.
Perhaps the most fundamental consideration is whether to:
- Spend valuable internal staff time on the installation, configuration, troubleshooting, training, maintenance, and support of the OSS that lays the foundation for the applications needed to deliver value to the business or downstream customers
or - Engage a vendor to ensure the organization has a secure, stable, and performant platform that enables internal staff to focus their time and energy on developing and maintaining domain expertise in delivering top quality applications needed to drive value for the business or downstream customers.
:format(avif))
:format(avif))
:format(avif))
:format(avif))
:format(avif))
:format(avif))
:format(avif))
:format(avif))
