Open Core & SaaS

When sponsorships and donations are not enough to sustain a project, maintainers turn to business models. The three most common are open core, SaaS, and dual licensing. Each creates a tension: charge too much and you kill adoption, charge too little and you kill the business. Getting this balance right is the central challenge of commercializing open source.

Open Core

Open core means the project has a free, open source core and paid proprietary features on top. The open source version is fully functional. The paid version adds features that primarily matter to enterprises: single sign-on, audit logs, advanced analytics, role-based access control, compliance features.

How Open Core Works

Open Core structure:
  Open Source (free)          Paid (proprietary)
  -------------------------   -------------------------
  Core functionality          SSO / SAML integration
  API                         Audit logging
  Basic auth                  Advanced RBAC
  Community support           Priority support
  Self-hosted                 High availability
  Standard features           Enterprise features

The key decision is where to draw the line between free and paid. This is not a technical decision. It is a business strategy decision that determines adoption rate, conversion rate, and revenue.

Real-World Examples

GitLab is the canonical open core success story. GitLab Community Edition is fully open source under the MIT license. GitLab Premium and Ultimate add features like advanced CI/CD, security scanning, compliance pipelines, and portfolio management. GitLab went public in 2021 with a valuation over $10 billion.

Elastic started as open core with Elasticsearch. The open source core handled search and analytics. The paid X-Pack added security, alerting, monitoring, and machine learning features. Elastic later changed its license (a controversial move covered in the next subtopic).

Grafana Labs offers Grafana as open source for visualization and dashboards. Grafana Cloud and Grafana Enterprise add hosted infrastructure, enterprise plugins, advanced authentication, and SLAs. Grafana Labs reached $1 billion in annual recurring revenue in 2024.

The Line Problem

Drawing the line wrong kills the business in one of two ways:

Too much in the paid tier:
- Developers cannot evaluate the product properly
- Community does not form around the free version
- Competitors fork the open source core and add the missing features
- Adoption stalls

Too little in the paid tier:
- Everyone uses the free version
- No reason to upgrade
- Revenue never materializes
- Company runs out of funding

The general principle: features that individual developers need should be free. Features that enterprises need when deploying at scale should be paid. This works because the people who evaluate and adopt the tool are developers (who need the free version to be good), while the people who pay are enterprises (who need compliance, security, and support).

SaaS (Hosted Open Source)

SaaS means running the open source project as a hosted service. Users pay for convenience: they do not have to install, configure, maintain, scale, or secure the software themselves.

How SaaS Works

SaaS model:
  Self-hosted (free)          Hosted (paid)
  -------------------------   -------------------------
  You install it              We install it
  You configure it            We configure it
  You maintain it             We maintain it
  You scale it                We scale it
  You secure it               We secure it
  You back it up              We back it up
  Your servers, your cost     Our servers, our margin

The value proposition is operational: the software is the same, but the operational burden shifts to the vendor.

Real-World Examples

Supabase is an open source Firebase alternative. The core is open source: a Postgres database, authentication, storage, and edge functions. Supabase's business is the hosted version, where teams pay based on usage. Developers can self-host everything, but most choose the hosted version because managing Postgres, auth, and storage is operational overhead they would rather avoid.

PlanetScale built a hosted MySQL-compatible database on top of Vitess, an open source database clustering system originally built at YouTube. PlanetScale added branching, deployment workflows, and a developer-friendly interface on top of the open source foundation. (PlanetScale later pivoted its pricing model, illustrating the difficulty of SaaS economics.)

Vercel hosts Next.js applications. Next.js is fully open source under the MIT license. Vercel's business is making Next.js deployment effortless, with edge functions, preview deployments, and analytics.

The Cloud Provider Threat

The biggest risk for SaaS-based open source businesses is cloud providers. AWS, Google Cloud, and Azure can take any open source project and offer it as a managed service, often with better infrastructure than the original creators can provide.

The cloud provider problem:
1. Company creates open source database
2. Company builds hosted version as business
3. AWS launches managed version of the same database
4. AWS has better infrastructure, more customers, deeper pockets
5. Company's hosted version struggles to compete

This happened to Elasticsearch (AWS OpenSearch), Redis (Amazon ElastiCache), and MongoDB (Amazon DocumentDB). It is the primary reason several open source companies changed their licenses.

Dual Licensing

Dual licensing means the project is available under two licenses: an open source license for open source use, and a commercial license for proprietary use.

How Dual Licensing Works

Dual licensing model:
  Open source license           Commercial license
  ----------------------------  ----------------------------
  Free for open source use      Paid for proprietary use
  Copyleft (usually GPL/AGPL)   Permissive (no copyleft)
  Must share modifications      No sharing requirement
  Community can contribute      Company retains all rights

The copyleft license is the enforcement mechanism. If you use the software in a proprietary product, the copyleft license requires you to open source your product. Most companies do not want to do that, so they buy the commercial license instead.

Real-World Examples

MySQL pioneered dual licensing in the database world. MySQL was available under the GPL for open source use and under a commercial license from MySQL AB (later Oracle) for proprietary use. This model funded MySQL's development for years before the Sun/Oracle acquisition.

MongoDB used the Server Side Public License (SSPL), a copyleft license specifically designed to prevent cloud providers from offering MongoDB as a service without contributing back. Companies that wanted to offer MongoDB as a hosted service had to either open source their entire stack or buy a commercial license.

Qt uses dual licensing for its UI framework. The open source version is available under LGPL or GPL. The commercial version allows proprietary use without copyleft obligations and includes additional tools, support, and features.

Requirements for Dual Licensing

Dual licensing only works when the company owns or controls all the copyrights:

Dual licensing requirements:
1. Company must own copyright to all code
2. Contributors must sign a CLA (Contributor License Agreement)
3. The CLA must assign copyright or grant sufficient rights
4. The open source license must be copyleft (to create the "buy" incentive)

The CLA requirement is controversial. Some contributors refuse to sign CLAs because they feel it gives the company too much power over code they contributed for free. This can reduce community contributions.

The Open Source to Business Pipeline

The modern playbook for building a business on open source follows a predictable pattern:

The pipeline:
1. Build open source project
2. Build community and adoption
3. Identify enterprise needs
4. Add paid features or hosted service
5. Convert enterprises to paying customers
6. Reinvest revenue into the open source project

Metrics at each stage:
- Stars, forks, contributors (awareness)
- Downloads, active users (adoption)
- Enterprise evaluations (interest)
- Paid conversions (revenue)
- Expansion within accounts (growth)

The critical insight is that open source is a distribution mechanism. Traditional software companies spend millions on sales and marketing. Open source companies let developers adopt the tool for free, then sell to the enterprise when the tool becomes critical to operations.

Comparing the Models

Model          Revenue Source       Risk                Best For
-----------    -----------------    -----------------   ------------------
Open Core      Paid features        Line problem        Developer tools
SaaS           Hosted service       Cloud providers     Infrastructure
Dual License   Commercial license   CLA friction        Libraries/engines

No model is universally best. Many successful companies combine them. GitLab uses open core with a SaaS offering. MongoDB uses dual licensing with a SaaS offering (Atlas). The choice depends on the type of software, the target market, and the competitive landscape.

Support & Consulting

A simpler monetization approach is selling support, training, and consulting around the open source project. The software is entirely free and open. The revenue comes from helping companies use it effectively.

Support and consulting model:
- Software: 100% open source, no paid features
- Revenue: support contracts, training, custom development
- Example: Red Hat (before open core features)
- Example: Canonical (Ubuntu support)
- Example: Chef/Puppet (configuration management consulting)

This model works best for complex infrastructure software where companies need help with deployment, configuration, and integration. It does not scale as easily as SaaS because revenue is tied to human labor, but it avoids the tension of deciding what goes behind a paywall.

The Conversion Funnel

Understanding how users move from free to paid is critical for any open source business model:

Conversion funnel:
1. Awareness: developer discovers the project (blog, conference, search)
2. Trial: developer tries it locally or in a side project
3. Adoption: team uses it in production
4. Dependency: project becomes critical infrastructure
5. Enterprise needs: SSO, compliance, SLAs, support required
6. Purchase: company pays for enterprise features or hosted service

The funnel narrows dramatically at each step. A project with 100,000 downloads might have 10,000 active users, 1,000 teams using it in production, and 50 paying enterprise customers. Understanding this funnel helps set realistic revenue expectations.

Common Pitfalls

Putting essential features behind the paywall. If the free version feels crippled, developers will choose a fully open alternative. The free version must be genuinely useful.
Ignoring the cloud provider threat. If your project is a database or infrastructure tool, assume AWS will offer a competing managed service. Plan your licensing and product strategy accordingly.
Requiring CLAs without explaining why. Contributors push back on CLAs. Be transparent about why you need them and what rights you are asking for.
Treating open source as just marketing. The community will notice if you do not invest in the open source version. Neglecting it erodes trust and adoption.
Underpricing the enterprise tier. Enterprise buyers expect to pay thousands per month. Pricing at $50/month signals a toy, not enterprise software.
Changing the model after adoption. Switching from open source to source-available (as Elastic and HashiCorp did) generates significant backlash. Plan your licensing strategy before you have millions of users.

Key Takeaways

Open core splits the product into a free open source core and paid proprietary features, with the critical challenge being where to draw the line between them.
SaaS monetizes convenience by hosting the open source project, but faces competition from cloud providers who can offer the same software as a managed service.
Dual licensing uses copyleft to create a "buy" incentive for proprietary use, but requires copyright control through CLAs that some contributors resist.
The fundamental tension in all models is the same: too much in the paid tier kills adoption, too little kills revenue.
Open source functions as a distribution and adoption mechanism, replacing traditional sales and marketing with developer-driven adoption.
Most successful open source businesses combine multiple models rather than relying on a single revenue stream.