Open Source Business Models: Open Core, Dual License, and Support Contracts

Open source has produced some of the most successful software companies of the past decade — HashiCorp, Elastic, MongoDB, Grafana, GitLab, Databricks. But "make it open source and the enterprise deals will follow" is not a business model. The companies that succeed have specific monetization strategies layered on top of their open source projects.

This guide breaks down the four main open source business models, with real examples, revenue benchmarks where available, and the licensing decisions that determine which model is viable.

---

Why Open Source as a Business Strategy?

Open source provides several unfair advantages over purely proprietary software:

The challenge: open source requires giving the core value away, which creates a free-rider problem. The business models below are different solutions to that problem.

---

Model 1: Open Core

The model: Core product is open source (MIT/Apache). Enterprise features are proprietary (closed source), available via paid subscription.

Examples: GitLab, Grafana, Metabase, PostHog, Plane, Flagsmith

The line between free and paid is the critical decision. If you put too much in the paid tier, the open source project gets little adoption. If you put too little, enterprises can run it free without ever paying.

Features typically behind the paid tier:

• SSO / SAML authentication
• Role-based access control (RBAC)
• Audit logs
• Advanced compliance (HIPAA, SOC 2 tooling)
• SLA and dedicated support
• Multi-tenant or multi-region deployment
• Advanced analytics

GitLab's approach (the best-documented example):

• Community Edition (CE): free, open source, self-hosted
• Enterprise Edition (EE): paid, adds SSO, compliance, advanced security
• GitLab.com (SaaS): hosted version with free and paid tiers

GitLab's 2024 revenue: ~$580M ARR. The CE project drives adoption; EE captures enterprise value.

Licensing for open core:

Core repository: Apache 2.0 or MIT (permissive)
Enterprise features: Custom commercial license ("Enterprise Edition License")
  - Prohibits self-hosting without a paid subscription
  - Typically allows evaluation (30 days)
  - Restricts white-labeling and competing hosted services

The trap to avoid: Putting core functionality in the enterprise tier. Engineers who adopted the tool will feel betrayed when features they relied on move behind a paywall ("bait and switch"). The enterprise tier should add to the open source version, not subtract from it.

---

Model 2: Dual Licensing

The model: The same codebase is available under two licenses — an open source license (GPL/AGPL) that requires derived works to also be open source, and a commercial license for companies that don't want to comply with the copyleft requirement.

Examples: MySQL (GPL + commercial), Qt, MongoDB (SSPL + commercial), Elastic (SSPL on Elasticsearch)

How it works: The copyleft clause in GPL/AGPL forces companies that embed your software in commercial products to either open-source their product or buy a commercial license. This is effectively a tax on commercial use without the cost of building enterprise features.

Open source users: Use under AGPL — must open source their application too
Commercial users: Pay for commercial license — no open source requirement

MongoDB's business model evolution: MongoDB started with AGPL, then switched to SSPL (Server Side Public License) in 2018 — a stricter copyleft that requires companies running MongoDB as a cloud service to open source their entire hosting platform. This was specifically designed to force AWS (which was offering MongoDB as a managed service without paying MongoDB) to either pay or stop.

Revenue math for dual licensing:

• 98% of users: open source (GPL) — pay nothing, contribute bugfixes
• 2% of users: commercial license — pay $20K–$500K/year per deployment
• The 2% funds the 98%

Risks:

• Must own all copyright (requires CLA — Contributor License Agreement)
• Cannot accept community contributions without CLA (contributors must sign over rights)
• SSPL/AGPL can reduce enterprise adoption (legal teams sometimes ban AGPL)

---

Model 3: Hosted SaaS on Open Source

The model: The software is open source; the business is the managed cloud version. You self-host for free; they host it for you for a subscription.

Examples: WordPress.com (WordPress.org is open source), Sentry, Cal.com, Supabase, PocketBase

Why it works: Most companies don't want to run open source software themselves. They want the software's benefits without the operational overhead. Hosting, updates, backups, scaling, security patches — the managed service is worth paying for even if the software is free.

Supabase as a case study:

• supabase/supabase on GitHub: fully open source (Apache 2.0), self-hostable
• supabase.com: managed version — free tier up to 2 projects, $25–$599/month for production
• Revenue: ~$50M ARR (2024 estimate)
• The open source community builds integrations, creates tutorials, and drives adoption
• Supabase captures the value of not running it yourself

Pricing structure for SaaS-on-OSS:

Free tier: Self-host or small cloud usage (community growth tool)
Pro tier: $25–100/month — small teams, production SLAs
Business tier: $100–500/month — larger teams, support
Enterprise: $1,000–10,000+/month — dedicated infra, compliance, SLAs

The cloud commons problem: AWS, GCP, Azure can offer your open source software as a managed service (and often do). Amazon's ElastiCache competes with Redis; Amazon DocumentDB competes with MongoDB. This prompted both MongoDB and Redis to change their licenses. For permissively-licensed projects, this is a real risk.

---

Model 4: Support and Professional Services

The model: Software is open source; revenue comes from support contracts, training, consulting, and implementation services.

Examples: Red Hat (acquired by IBM for $34B), SUSE, Canonical (Ubuntu)

Red Hat's model (the definitive example):

• RHEL source code is available (GPL) — anyone can compile and use it
• Red Hat charges for: certified binaries, subscriptions with support SLAs, consulting
• CentOS was the "free RHEL" — Red Hat eventually changed the strategy (CentOS Stream)
• Revenue at acquisition: ~$3B/year

When this works:

• Enterprises need certified, tested, supported deployments (not raw open source)
• The software is infrastructure-level (OS, database, middleware)
• Compliance requires vendor support (many enterprises can't use unsupported software)

When it doesn't:

• Application-level software (engineers prefer cloud SaaS over self-hosted + support)
• SMB market (can't afford enterprise support contracts)
• Fast-changing software (support contracts don't scale with rapid iteration)

---

Choosing Your License

HashiCorp's BUSL move (2023): HashiCorp switched Terraform, Vault, and Consul from MPL to BUSL (Business Source License). The change restricts competitors from offering HashiCorp products as managed services. After 4 years, the code converts to MPL (open source). The community forked Terraform as OpenTofu. This illustrates the reputational risk of license changes.

---

Revenue Benchmarks

Median time from open source launch to $1M ARR: 3–5 years. The community-building phase is slow, but the sales motion is efficient (inbound, self-service).

---

Working With Viprasol

We help developer tools companies and infrastructure startups structure their open source strategy — licensing decisions, open core feature line, pricing, and the technical implementation of the hosted SaaS layer on top of an open source core.

→ Talk to our team about your open source business model.

---

See Also

• SaaS Pricing Strategy — pricing models for SaaS-on-OSS
• Software Architecture Patterns — multi-tenant architecture for hosted OSS
• Product-Led Growth — open source as a PLG motion
• Technical Writing for Developers — documentation that drives OSS adoption
• Web Development Services — building your SaaS layer