Business Models
Open core, SaaS, support, dual licensing — and how sustainability actually works (or doesn't).
Business Models & Sustainability
Nobody has ever made money from the licence itself. They make money from support, hosting, scarcity and services wrapped around software that happens to be free. Understanding which of those a project depends on tells you how stable it is — and when it is likely to change its licence.
The models
| Model | How money is made | Examples | Tension |
|---|---|---|---|
| Support & subscription | Certified binaries, patches, SLAs, indemnity, backports | Red Hat, SUSE, Canonical | Revenue scales with sales, not code quality |
| Open core | Core is open; SSO, audit logs, governance, scaling are paid | GitLab, Mattermost | Constant pressure to move features behind the paywall |
| Hosted / managed service | Run the software for customers | Confluent, MongoDB Atlas, Databricks | Hyperscalers can offer the same; triggers relicensing |
| Dual / commercial licensing | Copyleft for those who share; paid licence for those who won't | Qt, MySQL (historically) | Requires copyright ownership of all contributions |
| Paid package / delayed open source | New work proprietary for a period, then released | FSL / BUSL users | Community cannot contribute to current work |
| Sponsorship & donations | GitHub Sponsors, Open Collective, Tidelift | Most small libraries | Unpredictable; rarely enough for rent |
| Grants & public funding | Philanthropy and sovereign programmes fund maintenance | Germany's Sovereign Tech Fund (2022), EU, NL, US | Time-limited; political |
| Consortium / cost-sharing | Competitors jointly fund shared infrastructure | LF, CNCF, Eclipse, OpenSSF memberships | Funding follows member priorities |
| Employment | Companies pay engineers to work on what they depend on | Google/Chrome, Meta/React, Microsoft/VS Code | Ends when the strategic rationale ends |
| Services, training, certification | Consulting, courses, badges | LF training, Elastic, Canonical | Marginal; needs brand strength |
| Marketplace / extensions | Paid plugins and themes around a free core | WordPress/Automattic, VS Code | Platform risk for sellers |
| Hardware & ancillary products | Sell the device or the data | Raspberry Pi, Arduino, Android OEMs | Only works with a hardware story |
The honest summary: open source monetises adjacent scarcity — support, trust, scale, convenience or hardware. Any model that tries to monetise the bits themselves stops being open source.
Who actually pays for maintenance
The funded minority — engineers employed by dependent companies, foundation staff, contracted maintainers, a handful of full-time sponsored maintainers. These carry the load: the kernel, systemd, OpenSSL, curl, Kubernetes, most language runtimes.
The unfunded majority — volunteer-run libraries with one or two maintainers, deep transitive dependencies nobody recognises. Surveys of maintainers repeatedly find most are unpaid for their OSS work, which is the structural risk behind supply-chain security.
Three incidents make the cost concrete:
- 2014 — Heartbleed (CVE-2014-0160). OpenSSL, running much of the internet's TLS, was reported at the time to be living on donations in the low thousands of dollars a year.
- 2021 — Log4Shell (CVE-2021-44228). A volunteer-maintained logging library triggered a global incident; every CISO discovered their dependency list at once.
- 2024 — xz backdoor (CVE-2024-3094). An attacker spent years cultivating trust around an unpaid maintainer of a critical compression library and nearly shipped a backdoor into sshd. The failure was economic, not cryptographic.
Relicensing as a business lever
| Project | Move | Community response | Net effect |
|---|---|---|---|
| MongoDB | AGPLv3 → SSPL (Oct 2018) | Dropped by Debian and Red Hat; AWS built DocumentDB | Revenue protected, trust damaged |
| Elastic | Apache-2.0 → ELv2/SSPL (Jan 2021) | AWS forked OpenSearch | Ecosystem split in two |
| HashiCorp | MPL-2.0 → BUSL 1.1 (Aug 2023) | OpenTofu fork within weeks; LF then CNCF | Terraform is now one of two products |
| Redis | BSD-3 → RSAL/SSPL (Mar 2024), then AGPLv3 (May 2025) | Valkey fork under the LF; distros switched | A rare reversal — an admission the first move backfired |
| Sentry | → FSL 1.1 | Little conflict; honest framing | Accepted because the restriction is narrow and time-limited |
For users the lesson is operational: pin your critical dependencies, know their licence, and know whether a fork exists. Licence risk is now a routine part of architecture review, and an SBOM is how you make it auditable.
Picking a model for your project
- Does the software need an operator? Yes → hosting or support. Complex infrastructure nearly always monetises as a service.
- Do enterprises need compliance guarantees? Yes → subscription with indemnity and long-term support.
- Do you have a defensible enterprise feature set? Yes → open core, but define the boundary in public and keep it stable.
- Is it a library or developer tool? Most likely sponsorship plus adjacent products. Do not expect donations to cover salaries.
- Do you need to block cloud resellers? Understand the cost: AGPL-3.0 keeps you OSI-approved; SSPL/ELv2/BUSL do not, and history shows they invite a well-funded fork.
What companies that depend on OSS should do
- Run an OSPO (Open Source Program Office) — policy, licence approval, contribution workflow, a single owner for dependency risk.
- Upstream-first: fix it upstream rather than maintaining a private patch. Private forks are a permanent tax.
- Fund what you depend on — foundation membership, GitHub Sponsors, Tidelift, or paying maintainers directly. Budget it as infrastructure, not charity.
- Know your critical dependencies. Generate an SBOM, then rank by usage, blast radius and bus factor.
- Contribute engineering time, not just money. Maintainers value a competent reviewer more than a logo.
- Have a licence-change playbook: what happens if a BUSL/SSPL change lands tomorrow? Which fork would you adopt?
How to decide what to fund
| Signal | Why it matters |
|---|---|
| Dependency depth — is it in your critical path? | Direct impact of its failure |
| Bus factor — number of active maintainers | One maintainer means one point of failure |
| Release cadence and issue latency | Proxy for maintainer capacity |
| Security track record — CNA, disclosure policy, response time | Whether a CVE will be handled |
| OpenSSF Scorecard result | Branch protection, MFA, pinned deps, fuzzing |
| Licence and its stability | Whether you can keep shipping |
See also: Governance · Foundations · Licenses · Security & supply chain