Open source is a distribution and collaboration model, not a business model. Sustainable companies usually sell convenience, risk reduction, or proprietary extensions around a free core. Understanding those patterns helps you evaluate lock-in and roadmap risk.
The failure mode for buyers is assuming the word “open” removes vendor risk. It does not: several well-known projects have relicensed from permissive to source-available terms after building an adoption base, moved key features behind paid editions, or restricted who may offer competing hosted services. None of that was illegal or even unusual—it was the business model working as designed. Buyers who never asked where the money came from were the ones surprised.
“Free” still costs money—either seats, usage, or operator time. Before standardizing on any commercial open-source product, identify which of the models below funds it, read the paid feature boundary, and keep an exit path tested, not theoretical.
Key takeaways
- Common models: hosted SaaS, open-core, support/services, dual licensing, and marketplaces.
- Self-hosting shifts spend to people, monitoring, backups, and upgrades—not zero cost.
- Ask which features are open today and what you lose if you cancel the paid edition.
- License and trademark stability signal roadmap risk as clearly as feature lists.
- Relicensing events follow adoption: the more critical a project becomes, the more its terms are worth re-reading.
- Prefer vendors whose paid value is operations or specialized features you can name.
Common revenue models
- Hosted SaaS: the company runs the open-source product for you (many analytics hosts, forge clouds). You pay for operations, uptime, and upgrades you never see.
- Open-core: advanced security, SSO, compliance, or scale features are proprietary. The health question is whether the free core stays genuinely usable alone.
- Support and services: paid SLAs, training, and implementation. Low lock-in for you, but hard to scale for the vendor—check their runway.
- Dual licensing: community copyleft vs commercial license for embedding. Common for databases and embedded libraries.
- Source-available pivots: formerly permissive projects adopting licenses that restrict competing hosts—technically a licensing model, practically a defensive move worth tracking.
- Marketplace / cloud credits: paid extensions, connectors, or cloud marketplace listings.
- Donations and foundations: common for infrastructure projects, rarely sufficient alone for product companies.
What each model predicts about vendor behavior
The point of identifying the model is prediction. A hosted-SaaS vendor competes on operations, so expect the self-hosting docs to lag the cloud product and the hardest features—scaling, high availability—to be best supported on their infrastructure. An open-core vendor guards the paid boundary, so expect SSO, audit logs, and compliance features to live behind the enterprise edition and occasionally migrate upward. A dual-license vendor cares about embedding, so expect strict contributor agreements that keep relicensing possible. A support-and-services vendor has the least lock-in but also the thinnest margins—check their runway, because the risk there is disappearance, not squeeze.
The most instructive pattern of the past decade is the source-available pivot. MongoDB's move to SSPL, Elastic's license change (later partially reversed), HashiCorp's shift to BUSL, and Redis's relicensing all followed the same arc: build adoption under permissive terms, then restrict competing cloud hosts once the project became infrastructure. Each triggered forks—OpenSearch, OpenTofu, Valkey—which is the other half of the lesson: when a project is important enough, the community's exit option is real, and its existence disciplines the vendor. Neither the pivots nor the forks were aberrations; both are the economics of open source working in public.
What “free” usually still costs
Self-hosting shifts spend from seats to people, monitoring, backups, and upgrades. Hosted free tiers shift spend into usage limits and future upgrades. Neither is wrong—just account for the full operating cost and the skills your team already has. A concrete way to do this: estimate the engineer-hours per month the self-hosted deployment will consume (upgrades, monitoring, incident response), multiply by loaded cost, and put that number next to the SaaS invoice. For a small team the SaaS often wins; for usage-billed products at scale, self-hosting often wins decisively. The mistake is comparing a price to zero.
Common buyer mistakes
- Comparing SaaS pricing against zero instead of against your own operator payroll—“free” software still consumes salaried hours.
- Reading the paid-feature boundary once at adoption and never again; the boundary moves, usually upward, and renewals are when to re-read it.
- Trusting that an export feature exists without ever running it—untested exit paths have a way of being broken exactly when needed.
- Assuming a foundation logo means safety: foundations resist unilateral relicensing, but they do not guarantee maintenance or roadmap velocity.
- Ignoring contributor agreements: a project whose vendor holds a CLA from every contributor can relicense at will; one without cannot.
- Treating a relicensing event elsewhere in the ecosystem as gossip rather than a prompt to re-check your own vendors' terms.
Buyer checklist
- Which features are open today, and which require a paid edition? Write the boundary down—it moves.
- Can you export data and run the community edition if you cancel? Test the export, not the documentation claim.
- Is the trademark/license set stable, or has the project relicensed recently? A recent change predicts more changes.
- Who stewards the roadmap—company, foundation, or mixed governance? Foundation-held projects resist unilateral pivots better.
- What happens to security fixes if the company pivots? Check whether the community edition receives patches on the same schedule.
- Does a healthy fork or independent distribution exist? Its mere existence disciplines the vendor and protects you.
Healthy skepticism without cynicism
Commercial open source can be excellent. The failure mode is assuming “open” means “no vendor risk.” Read the license, the contributor agreements, and the paid feature boundary before you standardize.
Frequently asked questions
- How do open-source companies make money?
- Most sell hosted SaaS, open-core proprietary features, support/SLAs, dual licenses for embedding, or marketplace extensions—not the public core alone. The core builds adoption and trust; revenue comes from convenience (someone else operates it), risk reduction (SLAs, compliance features), or exclusivity (commercial licenses for embedding). Knowing which lever funds your vendor tells you where the paid boundary will move next.
- Is open-core still “open source”?
- The core under an OSI-approved license is; paid modules may be proprietary, and that combination is legitimate. The practical question is not purity but usability: can you run the community edition in production without the paid features, or is it a demo? Treat the open/paid boundary as a product decision that can shift each release, and re-read it when you renew—vendors under revenue pressure tend to move features upward, not downward.
- Does self-hosting mean free?
- No. You pay with infrastructure and operator time: upgrades, monitoring, backups, security response, and incident handling. A realistic comparison puts engineer-hours per month next to the SaaS invoice—for small teams the SaaS is often cheaper, and for large usage-billed deployments self-hosting often wins. The mistake is comparing SaaS pricing to zero instead of to your own payroll.
- What should buyers watch for?
- Exportability you have actually tested, community-edition parity, recent relicensing events, governance structure, and whether security fixes continue if you leave the paid plan. Watch trailing indicators too: a vendor that moves previously free features into paid tiers, restricts competing hosts, or tightens trademark policy is signaling strategy. None of these are dealbreakers alone—but each one should trigger a re-read of your exit plan.
- What happens when a project relicenses?
- Historically, one of two things. If the project is important enough, the community forks it under the old terms—OpenSearch from Elasticsearch, OpenTofu from Terraform, Valkey from Redis—and the fork often attracts foundation backing and major-cloud support quickly. If it is not, users quietly absorb the new terms or migrate away over years. As a buyer, the actionable point is timing: relicensing announcements usually grandfather existing versions, so you have a window to decide between the fork, the commercial terms, or an exit—but only if your export path already works.
- Where can I check licenses and evaluate projects?
- Use the catalog license browser and the evaluation checklist article before you standardize on a vendor or community project.
Conclusion
Commercial open source is not a contradiction—it is how most of the infrastructure you rely on gets funded. The buyer's job is to understand which model funds each vendor and what that model predicts: SaaS vendors compete on operations, open-core vendors will guard the paid boundary, and dual-license vendors care most about embedding. Prefer vendors whose paid value is operations or specialized features you can clearly describe in one sentence—and keep an exit path tested, not theoretical. A vendor relationship where you could leave, but choose not to, is exactly what open source is supposed to buy you.
Build a stack for this use case.
Answer nine practical questions and compare three transparent architectures with costs, free limits, lock-in, and migration paths.
Build my stack
