Should I use AGPL or MIT?

MIT for libraries you want maximum adoption of (and don't plan to host commercially). AGPL for self-hostable applications you want to protect from cloud forks. BSL is increasingly common as a middle path — paid for commercial hosting, OSS after a few years.

How big does the community need to be before I monetise?

Earlier than you'd think. The 'we'll monetise once we're big' pattern is the path to the trap. Start with a paid tier when you launch, even if it has zero customers for the first year. Sets the expectation that this is a business, not a hobby.

What about dual licensing?

Works for libraries with commercial alternatives — pay for a commercial licence to use in proprietary software, or use the AGPL/copyleft version with the obligations. Adds friction; usually replaced by BSL for new projects.

Can I take VC money for an OSS company?

Yes, dozens of OSS-core companies have. Investors will price the round assuming you'll eventually offer a hosted paid tier. Make sure your articulated business model has a credible monetisation path.

All hubs

Business Model

Building a business on open source

Open source is the most powerful go-to-market motion of the last decade — and the easiest one to monetise badly. Sentry, Posthog, Cal.com, Plausible, Supabase, Hashicorp all built durable businesses on top of OSS. Each picked a different model, a different licence, and a different relationship with their community. This hub maps the choices and what each one costs you.

Last updated June 1, 2026

Who this is for

Founders building (or considering) a company where the core technology is open source.

What you'll learn

Three OSS business models: core, hosted, and adjacent
Which licence actually protects monetisation
Contributor economics — supporting the community without being captured by it
Common monetisation traps and how to avoid them
When OSS is the wrong call

Sharpen your pricing strategy

Three models — pick before you write the LICENSE file

OSS-core (Sentry, Posthog, Mattermost) — the core is open source under a permissive (MIT/Apache) or copyleft (AGPL) licence. The commercial company offers a hosted version of the same code, plus enterprise-only features (SSO, audit logs, dedicated support, SLAs). The split runs through the codebase, with proprietary modules in a separate licence.

Hosted-OSS / SaaS-on-OSS (Vercel for Next.js, Hashicorp Cloud) — the core is open source under a permissive licence. The commercial company runs the canonical hosted version. Customers can self-host but most pay for the hosted experience. Risk: clouds (AWS, GCP) launching competing hosted versions.

OSS-adjacent (Stripe, Tailwind) — the framework / library is open source; the business is a separate product that benefits from the OSS's distribution. Tailwind sells UI components and admin templates; Tailwind itself is free.

The model dictates the licence, which dictates the entire trajectory:

MIT / Apache 2.0 — maximum adoption, lowest moat (cloud forks legal)
AGPL — protects against unauthorised hosting; tolerated by most enterprise, refused by some
BSL (Business Source Licence) — paid for cloud hosting; converts to OSS after N years (HashiCorp, MariaDB pattern)
SSPL — Mongo's response to cloud forks; controversial; treated as non-OSS by Debian/Fedora

Pick licensing the day you start, not on day 365 when you realise the model needs protection — relicensing breaks trust permanently.

Contributor economics + community

OSS that grows depends on contributors. Contributors need:

Clear contribution paths — labelled-good-first-issues, accepted PR templates, fast review turnaround
Public recognition — contributors listed on the site, in the CHANGELOG, in release notes
Decision transparency — RFCs, roadmaps, public discussions — not closed-door decisions that surprise the community
Maintainer responsiveness — issues triaged within a week, PRs reviewed within two

What kills contributor energy:

Maintainers who never merge — contributors stop contributing after 2-3 stalled PRs
Surprise direction changes — "we're rewriting in Rust" without RFC
Vendor decisions that contradict community needs — adding feature X because enterprise asked, when 90% of community wants feature Y

What about paid maintainers? Mature OSS projects (Linux Foundation–style) blend volunteers + paid maintainers from sponsoring companies. For a single-vendor project, paying the core maintainers is fine; just be transparent that they're employees, not independent voices.

Monetisation traps + when OSS is the wrong call

Trap 1: monetising too late. A common pattern: launch OSS, build a community, hit a million users, only then start charging. By then the community expects everything to be free, the cloud is hosting your software for billions, and your monetisation feels predatory. Build the monetisation path on day one even if you don't switch it on until later.

Trap 2: monetisation that feels like extortion. Pulling features out of OSS and into the paid tier breaks trust. New paid features only — never remove what was free.

Trap 3: relicensing. Going from MIT/Apache to AGPL or BSL is sometimes necessary but always painful. You'll lose a portion of the community permanently. Plan licensing carefully on day one.

When OSS is the wrong call:

Your differentiation is the implementation (not the interface). OSS exposes the implementation; competitors copy.
Your customer doesn't care about OSS values (most consumer products, most B2C). OSS adds operational overhead without growth lift.
You're optimising for a fast acquisition rather than a durable business. Acquirers discount OSS-core because of the licence and community complications.

OSS is leverage, not magic. Use it when distribution to developers / technical buyers is your bottleneck. Don't use it because Hacker News will applaud.

Step-by-step action plan

Do these, in order

1Pick your OSS model and licence before launching the repo
2Document the contribution path — issues, PR template, RFC process
3Stand up a paid tier on day one; it can have zero features
4Plan the boundary between OSS and paid features before the community asks
5Spend 25% of engineering time on community work (reviews, RFC discussion, releases)

Frequently asked questions

Should I use AGPL or MIT?: MIT for libraries you want maximum adoption of (and don't plan to host commercially). AGPL for self-hostable applications you want to protect from cloud forks. BSL is increasingly common as a middle path — paid for commercial hosting, OSS after a few years.
How big does the community need to be before I monetise?: Earlier than you'd think. The 'we'll monetise once we're big' pattern is the path to the trap. Start with a paid tier when you launch, even if it has zero customers for the first year. Sets the expectation that this is a business, not a hobby.
What about dual licensing?: Works for libraries with commercial alternatives — pay for a commercial licence to use in proprietary software, or use the AGPL/copyleft version with the obligations. Adds friction; usually replaced by BSL for new projects.
Can I take VC money for an OSS company?: Yes, dozens of OSS-core companies have. Investors will price the round assuming you'll eventually offer a hosted paid tier. Make sure your articulated business model has a credible monetisation path.

Related tools

LTV:CAC Calculator

Related courses

Category Design 101

Related hubs

Building a Devtools Business

Building API and developer-tools businesses: bottom-up adoption, docs as marketing, PLG pricing, and the unit economics of selling to engineers.

Building a SaaS Business

Practical guide to building a SaaS business as a solo or small-team founder — niches, pricing, distribution, retention.

Startup Growth

Real startup growth — growth loops, why most channels don't work for your business, and how to find the 1-2 that do. Without the growth-hack mythology.