Open Core vs Source Available: Business Models 2026

The 2020s have been a decade of reckoning for open source business models. The naive version—build something free, hope someone pays you—doesn't work at scale. What has emerged is a more nuanced landscape of models, each with distinct trade-offs between openness, community, and revenue. Here's where it stands in 2026.

TL;DR

Open core: Free and open source core (often AGPL) + proprietary enterprise features. The dominant model for infrastructure software.
Source available (BSL, SSPL): Source is viewable but commercial use is restricted. Not open source by OSI definition.
The 2023-2024 "relicensing wave" (HashiCorp, Redis, Elasticsearch) moved major projects from permissive/AGPL to source-available BSL/SSPL.
Every major relicensing triggered a community fork (OpenTofu, Valkey, OpenSearch), often endorsed by the Linux Foundation.
For enterprise buyers: source-available projects carry supply chain risk. Today's MIT can be tomorrow's BSL.
For builders: AGPL + commercial dual licensing is the proven model. The complexity is in pricing and packaging, not licensing.

Key Takeaways

Open core has produced billion-dollar companies (GitLab, HashiCorp before acquisition, MongoDB, Elastic). It's the validated path.
Source-available licenses are a symptom of a real problem: cloud providers profiting from open source without contributing back. But they solve that problem by abandoning the community, not protecting it.
The AGPL + cloud exclusion approach is increasingly used: AGPL for everyone except cloud providers, who need a commercial license.
Community forks of source-available projects are healthy and increasingly well-resourced (Linux Foundation, CNCF backing).
Enterprise procurement is becoming more sophisticated: legal teams now audit license history and relicensing risk.
The "FAANG problem"—big tech hosting open source without contributing—is real but has better solutions than BSL.

The Business Model Taxonomy

1. Open Core

What it is: The core product is fully open source (typically AGPL or Apache). Enterprise features—SSO, advanced RBAC, audit logging, compliance features, dedicated support—are proprietary.

How revenue works:

Free tier: Community edition (OSS license)
Paid tier: Enterprise edition (commercial license, adds proprietary features)
Hosted: Managed cloud offering (often called "Cloud" or SaaS edition)

Examples:

GitLab: CE is MIT/EE is proprietary. GitLab the company IPO'd at $15B valuation.
Grafana: Core is AGPL. Grafana Cloud and Enterprise add managed hosting and enterprise features.
Mattermost: CE is MIT. Enterprise edition adds compliance, LDAP, SSO.
Nextcloud: Core is AGPL. Enterprise subscription adds support, apps, and compliance tooling.
Gitea/Forgejo: Community editions are free; Gitea Inc. offers commercial Gitea.

Why it works:

Community builds the core, creating adoption and evangelism
Enterprise buyers need features that require security, compliance, and support investment
AGPL prevents AWS-style free-riding on the core without contributing back
Clear commercial path: enterprise features are worth paying for

Risks:

Feature cannibalization: if you put too much in the free tier, conversion to paid is low
Open source perception risk: community gets upset if popular features are moved to enterprise edition
AGPL can be a blocker for some enterprise legal teams (dual licensing can address this)

2. Dual Licensing (GPL/Commercial)

What it is: The same codebase is available under two licenses: an open source license (typically GPL or AGPL) and a commercial license. Commercial license removes copyleft obligations and may add commercial support.

How revenue works:

Open source users: use under GPL/AGPL terms (must share modifications)
Commercial users: pay for a commercial license that allows proprietary use

Examples:

MySQL/MariaDB: GPL for open source projects; commercial license for proprietary use. This is why WordPress uses GPL (compatible with MySQL GPL), but Oracle gets commercial license revenue from enterprises.
Qt: LGPL for open source; commercial license for proprietary embedded/desktop applications.
WooCommerce: GPL core; paid extensions ecosystem.

Why it works:

Captures revenue from commercial users who would otherwise use the software without paying
Maintains genuine open source status for the community
Clear legal separation between community use and commercial use

Risks:

Requires CLA (Contributor License Agreement) from all contributors so you can relicense their contributions
GPL is still scary for many enterprise legal teams
Commercial license terms must be attractive enough relative to just using the open source version

3. Open Source + Hosted Service (SaaS)

What it is: The software is fully open source (any license), but the company makes money by operating it as a managed service.

How revenue works:

Free: Run it yourself (open source)
Paid: Let us run it for you (convenience, SLA, support)

Examples:

Plausible Analytics: AGPL self-hosted; Plausible Cloud is paid
Metabase: Source available self-hosted; managed cloud is paid
Sentry: Self-hosted (BSL now); Sentry.io is the hosted service

Why it works:

Captures revenue from users who value convenience over cost savings
Cloud deployment expertise is genuinely valuable, even when you can run it yourself
Often not in direct competition with cloud giants because the target audience prefers convenience

Risks:

Before the relicensing wave, big cloud providers could compete directly by offering managed versions
Support burden from self-hosted community users
Conversion rate from free to paid is typically low (1-5%)

4. Source-Available (BSL, SSPL, SSPL)

What it is: Source code is publicly viewable and may be usable with restrictions. Specifically restricts certain commercial uses (often: offering the product as a competing service).

Not open source: BSL and SSPL are not approved by the Open Source Initiative and violate the Open Source Definition.

Examples:

HashiCorp → BSL (2023): Terraform, Vault, Consul, Nomad moved from MPL-2.0 to BSL. You can view, use, and contribute—but you can't offer these products as a competing managed service without a commercial license.
Redis modules → SSPL (2019): Redis Labs moved its enterprise modules from Apache to SSPL. Redis OSS remained BSD.
Elasticsearch → SSPL (2021): Elastic moved from Apache 2.0 to SSPL after AWS launched Amazon OpenSearch. AWS forked the last Apache-licensed version and continued it as OpenSearch.
Sentry → BSL (2019): Early adopter of BSL.

Why companies choose it:

Prevents cloud provider competition (the core motivation in every case)
Maintains source visibility and self-hosting rights for most users
Preserves contribution workflow

Why it's controversial:

It's not open source. OSS projects built on these tools may need to change their approach.
It breaks the implicit contract: companies and communities invested in these tools expecting open source.
It triggers forks: every major source-available relicensing has produced a well-resourced community fork.

The Relicensing Wave: 2019-2024

The period from 2019 to 2024 saw the most dramatic series of OSS relicensings in history. The trigger: cloud providers (primarily AWS) were building profitable managed services on open source software without contributing meaningfully to the projects.

The Pattern

Company builds widely-adopted open source tool (MIT, Apache, MPL)
Tool becomes popular enough that AWS/Azure/GCP build managed versions
Cloud providers capture majority of commercial value without contributing code
Company relicenses to restrict competing managed services (BSL or SSPL)
Community forks the last open source version
Fork gets foundation backing; company gets legal protection but loses some community trust

The Major Events

Redis (2019): Redis Labs added SSPL to Redis modules. Redis core remained BSD. Limited impact because modules were separate.

Elasticsearch/Kibana (2021): Elastic moved from Apache 2.0 to SSPL after Amazon launched OpenSearch/Kibana. AWS forked Apache-licensed version; created the OpenSearch project under Apache 2.0. Both projects are now actively maintained.

Terraform/HashiCorp (2023): HashiCorp moved Terraform, Vault, Consul, and Nomad from MPL to BSL. Within weeks, the community—led by Gruntwork and others—launched OpenTofu, which was adopted by the Linux Foundation. OpenTofu reached feature parity quickly and is now a viable alternative.

Redis (2024): Redis (the company, now just "Redis") relicensed Redis OSS itself from BSD to dual RSALv2/SSPLv1. This was more significant than the 2019 modules change. Result: Valkey fork, created by Linux Foundation and backed by AWS, Google, Oracle, and Snap. Within months, Valkey was outpacing Redis in community activity.

Lessons for Enterprise Buyers

Every relicensing created supply chain risk for organizations that had built on these tools. Key takeaways:

License history matters: Check whether a project has ever changed its license. A project with stable open source licensing is lower risk than one with relicensing history.
Forks are viable alternatives: OpenTofu, Valkey, OpenSearch, and MariaDB are all production-ready forks of relicensed tools. Foundation backing provides long-term stability.
Diversify where possible: Single-vendor dependencies on any infrastructure component carry business risk regardless of license.
Read the license carefully: BSL has an "Additional Use Grant" and a "Change Date" after which it converts to an open source license (typically 4 years). Some BSL restrictions are narrower than others.

What's Working: The Validated Models

Based on publicly available information about revenue, funding, and community health:

Open core + AGPL + dual licensing: GitLab, Grafana, Mattermost, Nextcloud, Bitwarden. These companies have achieved real scale while maintaining genuine open source communities.

Open source + managed hosting: Plausible, Fathom, Sentry (pre-BSL), various others. Works best when the self-hosted setup is genuinely difficult and the hosted service has strong operational characteristics.

Open core with Apache/MIT core: Elastic (post-SSPL controversy), Confluent (Apache Kafka core), Databricks (Apache Spark core). The commercial layer adds enterprise features, managed services, and support.

The AGPL + Cloud Exception Approach

An emerging model tries to preserve open source community while specifically addressing the AWS problem:

AGPL with cloud provider exception: Code is AGPL (preventing SaaS use without releasing modifications) but includes an explicit exception for users who aren't competing with the original company's hosted service.

Some projects use a tiered approach:

Individual use: AGPL, free
Non-competing commercial: AGPL, free (or commercial license for non-copyleft rights)
Competing cloud service: Commercial license required

This is more nuanced than BSL and maintains stronger community trust.

Choosing a Model

For founders building open source infrastructure:

Priority	Recommended Model
Maximum adoption	MIT/Apache (accept loss on cloud hosting)
Community + revenue	AGPL + commercial license (open core)
Prevent cloud competition	AGPL + dual licensing (or AGPL + cloud exception)
Source visibility only	BSL (but expect fork pressure and community friction)
Maximum control	Proprietary with source available for reference

The typical open core free-to-paid conversion rate is 0.5-2% of the user base — much lower than traditional software, but the sheer scale of open source distribution means even a fraction of a percent of millions of users can generate substantial revenue. GitLab's IPO demonstrated that an open core company can reach public markets with a genuine community edition; Grafana Labs raising $240M at a $6B valuation showed the same for developer observability tooling. The model works when the free tier is genuinely useful and the enterprise features serve specific organizational-scale needs that don't apply to individual developers or small teams.

For more background on how AGPL specifically prevents cloud provider free-riding, see why OSS companies are choosing AGPL. For a deep dive into the mechanics of open core model monetization, see how the open core model works. And for context on where source-available fits in the OSS definition debate, read the rise of source-available vs true open source.

Methodology

This analysis draws from public company statements, IPO filings, and press releases around licensing decisions, OSI license approval records, Linux Foundation and CNCF project announcements, documented fork activity on GitHub, and analyst coverage of the open source business model landscape. Revenue estimates and company valuations are based on publicly available funding announcements and financial reports through early 2026.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)