Your license is your contract with the market. It is your business model enforcement mechanism. Define it early. Be transparent about your boundaries. And remember: You can always make a restrictive license more permissive later, but making a permissive license more restrictive is a painful, trust-burning one-way door. Measure twice, cut once.

Your license choice is one of the most important decisions you’ll make in the life of your company. If you get it wrong in one direction, you undermine your community by being overly restrictive, strangling the top-of-funnel adoption that makes the COSS model so powerful. If you get it wrong in the other direction, you hand your revenue directly to hyperscale cloud providers by being too permissive. Let’s strip away the legal hedging and philosophical debates. We are going to look directly at what these licenses actually do in the market, how they shape competitive dynamics, and how you must use them to defend your enterprise.

The permissive trap

When a founder writes their first line of code, their primary objective is adoption. They want developers to use their tool, love their tool, and share their tool. Consequently, developers instinctively reach for permissive licenses. Recent data from the Open Source Initiative (OSI) confirms this enduring psychological default: in 2025, the MIT license remained the most-viewed license in the world with over 1.5 million pageviews, followed distantly by Apache 2.0 with 344,000.

The gap between this permissive instinct and commercial reality is the central crisis of the modern COSS ecosystem. Starting with an MIT or Apache 2.0 license maximizes initial adoption and friction-free distribution because it provides absolute freedom. These licenses allow anyone to embed your code into any commercial product without restriction. However, they provide precisely zero legal protection against commoditization.

As of Q4 2025, AWS, Azure, and Google Cloud together held sixty-three percent of the global cloud market and generate $119 billion in quarterly cloud infrastructure revenue. These are the apex predators of the internet. If your permissively licensed infrastructure tool achieves widespread popularity, it will inevitably attract their attention. The pattern is painfully consistent: you spend years building a massive open-source ecosystem; a hyperscaler launches a managed service wrapping your exact code without contributing a single commit back to the core project; your enterprise buyers default to the hyperscaler because the spend is already committed in their multi-year enterprise discount programs; and finally, you are starved of the very managed-service revenue you created. You must plan your defense before they arrive, not after they have integrated your life’s work into their cloud console.

From copyleft to network defense

To defend your business, you must understand the mechanics of the traditional open-source spectrum beyond permissive licenses. Moving up the ladder of protection, we encounter weak copyleft licenses like MPL 2.0 and LGPL. The key characteristic of these licenses is that any modifications made specifically to the licensed files must be shared back with the community. However, the enforcement mechanism is limited strictly to the file level, meaning a hyperscaler can easily build a proprietary control plane around your unmodified open-source core without triggering any obligation to share their lucrative management software.

Strong copyleft, GPL 2.0 and 3.0, escalate the defense. Any software that incorporates GPL code must itself be GPL, and the trigger is distribution: ship the software, share the source. But the modern cloud broke that lever. Hyperscalers don’t distribute software. They host it, and hosting isn’t distribution. This massive loophole gave rise to network copyleft licenses, specifically the AGPL v3.

AGPL v3 is the strongest fully OSI-approved license available. It extends GPL to network use, so a company that modifies an AGPL application and offers it as a service is legally compelled to share its modifications. In theory that puts enormous pressure on cloud providers and forces their proprietary wrappers into the open. In practice the corporate reaction was swift and brutal. Because AGPL is viral, it’s banned across much of the enterprise. Many Fortune 500 companies maintain blanket policies forbidding any AGPL dependency, on the reasoning that one bad import could infect their proprietary code. So AGPL protects you against cloud providers and, in the same stroke, throttles the enterprise adoption you were counting on. Strong defense, narrow doorway.

Source-available and fair source

Because traditional OSI-approved licenses either failed to protect revenue (Apache/MIT) or triggered enterprise procurement bans (AGPL), a new category of “source-available” licenses emerged to thread the needle. These are not technically “open source” by OSI definitions, but they provide the community with source code access while erecting commercial firewalls.

MongoDB invented the first of these, the Server Side Public License, later adopted by Redis. The SSPL is a poison pill aimed squarely at hyperscalers. It adds one devastating clause beyond AGPL: any company offering the software as a managed service must open source its entire infrastructure stack, not just its modifications. Because no hyperscaler will ever open source their proprietary operational backend, it practically outlaws third-party managed services without a commercial agreement. It is incredibly powerful, but major Linux distributions immediately removed MongoDB packages upon its adoption, and the ecosystem backlash was severe.

More recently, the Business Source License (BSL 1.1) became the most widely adopted source-available license, largely popularized by MariaDB, CockroachDB, and heavily utilized by HashiCorp. BSL is generally considered more “enterprise friendly” because it allows free use for almost all internal commercial purposes. Its enforcement mechanism specifically restricts production use only if it is part of a competing managed service. Crucially, BSL requires that the code revert to a fully OSI-approved license, typically after four years. It does not force anyone to open-source anything; it simply buys the creator a temporary monopoly on cloud commercialization.

Elastic took its own route with Elastic License v2 (ELv2). This license cleanly bars SaaS use without the vendor’s permission and bars circumventing built-in license keys or usage limits. It avoids the viral “entire stack” complexities of the SSPL, making it an elegant, targeted weapon against cloud commoditization, though it is best suited for younger products where the risk of a massive community fork is lower.

The newest arrival is the Fair Source family, led by the Functional Source License (FSL) that Sentry adopted recently. FSL is built for SaaS companies that care about developer sustainability. It keeps the source available and protected from commercial competitors for two years, then converts automatically to permissive Apache 2.0 or MIT. Because it carries none of AGPL’s viral obligations, it sails through enterprise legal review.If you are building a SaaS application rather than an on-premise infrastructure tool, FSL is a masterclass in balancing commercial defense with long-term open-source contribution.

Working the decision in order

Choosing a license is a sequence of business questions, and the order matters.

First, coldly evaluate your commoditization risk. If you’re building core database infrastructure, an observability platform, or an event-streaming pipeline, AWS is coming for you, and you need protection. If you’re building a niche developer workflow tool with no heavy compute appetite, your risk is genuinely lower and you can lean toward permissive adoption.

Then look at how much your roadmap depends on outside contributions. If community pull requests are a real engine of your velocity, a heavily restrictive license like BSL or SSPL will scare off the enterprise contributors who write most of them.

Then look at how you ship. A pure SaaS company gets time-limited protection and enterprise friendliness from FSL. An on-premise infrastructure company has to weigh the OSI-approved purity of AGPL against the broader, more contested commercial protection of BSL.

The last question is the one founders skip and later regret: who owns the intellectual property? The choice is between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO). A DCO is light. It’s a one-line sign-off in a Git commit, developers like it, and it adds almost no friction. It also gives you no future flexibility, because you never consolidate the rights and so can never unilaterally relicense the project. A CLA is the opposite trade. It adds friction, and many corporate developers are forbidden from signing one, but it grants the commercial entity full IP rights over the aggregated codebase.

The answer here isn’t balanced, and it shouldn’t be. If there’s any chance you’ll need to change your license later, to fend off a hyperscaler, to clean up before an IPO, or to position for an acquisition, you must institute a CLA on day one. HashiCorp’s pivot to BSL, community fallout and all, was only legally possible because someone had the foresight to require a CLA.

The full spectrum

A reference map of the field, from maximum freedom to maximum defense.

OSI-approved licenses

License Type Key characteristic What enforces it MIT / Apache 2.0 / BSD Permissive Maximum freedom; embeddable in any commercial product Nothing; anyone can do anything MPL 2.0 / LGPL Weak copyleft Changes to licensed files must be shared back File-level copyleft only GPL 2.0 / 3.0 Strong copyleft Any software incorporating GPL code must be GPL Distribution triggers sharing AGPL v3 Network copyleft Extends GPL to network use; SaaS apps must share source Network use triggers sharing

Source-available and fair source

License Type Key characteristic What enforces it SSPL Source-available Offering it as a service requires sharing the entire stack Prohibits managed-service competitors in practice BSL 1.1 Source-available Restricts competing managed services; reverts to OSS after a set period Production use as a managed service is restricted Elastic License v2 Source-available Prohibits SaaS use and circumventing license restrictions Custom vendor license FSL Fair source Source-available for two years, then converts to Apache 2.0 Time-limited commercial protection

OSI license pageview data for 2025 shows MIT is still the most-viewed license (1.53M pageviews), with Apache 2.0 second (344K). Developers still start with permissive licenses. The gap between that instinct and commercial reality is the central problem this chapter addresses.

The source-available options, up close

Business Source License (BSL 1.1)

BSL is the most widely adopted source-available license since 2022. It allows free use for almost everything, including internal commercial use, and restricts only production use as part of a competing managed service. After a defined window, typically four years, it reverts to an OSI-approved license such as AGPL or MPL. And it imposes no copyleft obligation — nothing downstream has to be open-sourced.

Who runs it: HashiCorp moved Terraform, Vault, Consul, and Nomad to it in August 2023, alongside MariaDB and CockroachDB.

The verdict: BSL is the most enterprise-friendly of the source-available options because it permits most commercial use. Its weak spot, which HashiCorp found the hard way, is that it triggers forks on contact. OpenTofu launched within thirty days of the announcement. If your project is dominant enough that a foundation will back the fork (and the Linux Foundation backed OpenTofu), BSL buys time without permanently protecting your position.

SSPL (Server Side Public License)

SSPL was MongoDB’s invention and was later used by Redis before the Valkey fork. The SSPL adds one clause beyond AGPL: any company offering the software as a service must open-source its entire infrastructure stack, not just its modifications. That effectively bars cloud providers from offering a managed service without a commercial agreement because no hyperscaler will open-source its whole operations stack.

The verdict: powerful on paper, but not OSI-approved and widely treated as a non-open-source license. Major Linux distributions removed MongoDB packages after the change. The Redis switch triggered the Valkey fork, backed by AWS, Google, Snap, and others, which picked up adoption fast. SSPL works only if you can stomach the community and ecosystem cost.

Elastic License v2 (ELv2)

Elastic’s custom license (ELv2) is the most vendor-friendly of the bunch. It prohibits two things: SaaS use without the vendor’s permission, and circumventing built-in license or usage restrictions.

The verdict: ELv2 is cleaner and simpler than SSPL, with narrower restrictions, and no entire-stack open sourcing requirement. But Elastic’s own history shows the catch. Switching from Apache 2.0 to ELv2 prompted AWS to fork Elasticsearch into OpenSearch (Apache 2.0) and split the community for good. ELv2 fits products that are newer or less dominant, where fork risk is lower.

FSL (Functional Source License)

FSL is the newest major license in the category, adopted by Sentry in 2024 and others. It converts to Apache 2.0 or MIT after two years. Per FSL’s own site, it’s designed for SaaS companies that value both user freedom and developer sustainability.

The verdict: the most developer-friendly of the source-available options, thanks to that two-year sunset into fully open source. It carries no AGPL-style obligations, so it passes muster in enterprises where AGPL is banned. If you’re a SaaS company rather than an on-premise infrastructure product, FSL deserves a serious look.

AGPL v3, the strongest OSI-approved option

AGPL v3 is the strongest fully open-source license. Its key extension over GPL: any software that communicates over a network must share its source. In theory that pressures cloud providers running AGPL software to share their modifications.

The reality bites the other way. AGPL is widely banned in the enterprise because it’s viral, and many large companies forbid AGPL dependencies outright. So it protects you against cloud providers while capping your enterprise adoption. Elastic’s 2024 move, adding AGPL v3 as a third option alongside SSPL and ELv2, was a goodwill gesture to OSI-aligned developers, not a commercial pivot. The commercial default stayed ELv2.

Subscribe now

Case studies, and what they cost

HashiCorp to BSL, August 2023

The change: Terraform, Vault, Consul, and Nomad all moved from MPL 2.0 to BSL 1.1.

The trigger: stopping competing managed-service providers, Gruntwork, Env0, and Spacelift, from using the code commercially.

The outcome: OpenTofu launched within thirty days, backed by the Linux Foundation. Gartner put the industry re-tooling cost above $600M. IBM later acquired HashiCorp for $6.4B, a 54% discount to its $14B IPO valuation. The prevailing read is that the BSL change was meant in part to clean up the cap table before an exit. It worked in that narrow sense while dissolving the community moat that made HashiCorp worth the premium in the first place.

The lesson: a license change that fragments the community right before an exit destroys the trust-based moat that justified the price.

Elastic to SSPL/ELv2, January 2021, then AGPL, September 2024

The change: Apache 2.0 to dual SSPL/Elastic License in January 2021, then back to AGPL v3 in September 2024 alongside SSPL and ELv2.

The trigger: AWS launched Amazon Elasticsearch Service in 2015 and contributed little. By 2021, Elastic was bleeding cloud revenue to AWS.

The outcome: AWS immediately forked OpenSearch (Apache 2.0) and split the community for good. In August 2024, Elastic’s stock dropped 27% on weak cloud guidance, with OpenSearch pressure cited. The 2024 return to AGPL was a sound strategy since AGPL blocks managed-service extraction better than SSPL because it’s OSI-approved. It was also a public admission that the 2021 change had damaged community trust.

The lesson: never say you’ll never change your license, which is precisely what Elastic had said in public. And build your cloud offering before the cloud providers build theirs. Elastic Cloud launched in 2019. Four years after AWS Elasticsearch.

Redis to SSPL/RSALv2, March 2024

The change: BSD to dual SSPL/Redis Source Available License.

The trigger: AWS ElastiCache was capturing managed Redis revenue without contributing back. Underneath sat Redis’s 1% conversion problem: only 1% of Redis users ever became paying Redis Enterprise customers, while AWS earned ElastiCache revenue from the other 99%.

The outcome: the Valkey fork launched within weeks, backed by AWS, Google, Snap, Ericsson, and others, and again by the Linux Foundation. Enterprise migration was fast, and Redis’s community position weakened sharply.

The lesson: BSD-licensed infrastructure that becomes a cloud staple gets commoditized eventually. The relicense bought time at the cost of the community.

MongoDB to SSPL, October 2018

The change: AGPL to SSPL.

The trigger: AWS DocumentDB, MongoDB-compatible but not MongoDB, launched in 2018 and captured enterprise AWS customers who wanted compatibility without paying MongoDB.

The outcome: commercial success. Atlas grew from $100M annualized in 2019 to 75% of MongoDB’s $2.4B ARR in 2025. The trade, community damage for commercial protection, paid off because Atlas, not community-driven adoption, had already become the primary growth engine.

The lesson: if your business has already pivoted to managed cloud as its main growth engine, the SSPL’s community costs may be a price worth paying. MongoDB made that trade with open eyes, and it worked.

Ring-fencing the value into three layers

Trust requires clarity, and clarity means saying out loud which parts of your software live under which rules. This is a communication strategy as much as a legal one. It tells every user exactly where they stand. Three layers do the work.

Layer one: the commons

This is the engine of the flywheel, and it has to stay friction-free.

License: permissive, Apache 2.0 or MIT.

The promise: this code will always be free. Run it, inspect it, modify it, build on it. It includes the core runtime, the standard APIs, and single-node functionality.

The strategy: this layer optimizes for ubiquity. It drops the barrier to entry to zero and lets developers quietly bring your product into the enterprise without procurement approval. Choke this layer and you kill your own top-of-funnel.

Layer two: the enterprise product

This is where you capture value, and it aims at the organization, not the individual developer.

License: proprietary or source-available, such as Polyform, ELv2, or a commercial EULA.

The promise: these features are for companies operating at scale. They solve organizational, compliance, security, and governance problems. They are paid.

The strategy: this layer monetizes complexity and risk. Single Sign-On, audit logs, role-based access control, and multi-region replication all belong here. The individual developer does not care about SSO. The Chief Information Security Officer does, and the CISO is who you’re selling to.

Layer three: the cloud shield

This is the defense against a hyperscaler taking your code, selling it as a service, and contributing nothing.

License: copyleft (AGPL v3) or Business Source License.

The promise: you cannot wrap our code in a cloud service and resell it against us without contributing back or paying a license fee.

The strategy: this is what stops the Amazon problem. If a cloud provider wants to monetize your R&D, it has to either open-source its entire stack, which it won’t, or come negotiate a commercial partnership.

The rug pull and how not to do one

The most damaging move in the COSS world is the rug pull: build a large community on a permissive license like Apache, then flip overnight to something restrictive like BSL to force monetization. It reads as betrayal, and it taxes exactly the hobbyists and early adopters who built your success.

Sometimes you genuinely have to change licenses to survive, say moving from Apache to BSL to stop a cloud competitor. When you do, integrity is the difference between a hard pivot and a rug pull. Four rules hold the line.

Exempt the little guy. Make the new license permissive for non-commercial use, development, and companies under a revenue threshold. You’re targeting the whales, not the minnows.

Honor the legacy. Never retroactively relicense old versions. Code that was free stays free. The new terms apply only to future versions.

Give notice, in plain words. Explain the economics, not the legalese: we need to protect our ability to invest in R&D against cloud providers who strip-mine our work, and this change is how we keep building the best product for you.

Never bait and switch. Don’t move features from the free tier to the paid tier. That’s the cardinal sin. The only direction you may move a feature is from paid to free.

CLA versus DCO, in practice

The choice between a Contributor License Agreement (CLA) and a Developer Certificate of Origin (DCO) is a strategic one, not a paperwork detail to delegate to outside counsel. Both govern how IP from outside contributors flows into your project. They determine what rights your company holds over code other people commit and what every contributor has to agree to before their code lands. It decides whether you can adapt your business model five years from now or sit paralyzed by fragmented IP. You can’t maximize commercial optionality and community velocity at once. You have to choose.

A CLA is a formal contract a developer signs before any code merges. Signing it grants your company broad rights over the contributed code, often including the right to relicense it, dual-license it, or use it in proprietary products. The IP consolidates under your roof, and that buys you commercial agility. Because you control the aggregated rights to the whole codebase, you can change the open-source license later on your own authority. When a hyperscaler starts strip-mining the project, or when an IPO requires ring-fencing the commercial offering, the CLA is what lets you pivot. HashiCorp’s move to BSL was possible only because it had one. The cost is friction. CLAs are heavy, many enterprise developers are barred by their legal departments from signing them, and requiring one lowers your raw contribution volume.

A DCO is the lightweight alternative the Linux kernel popularized. There’s no document to sign. A developer adds a Signed-off-by line to the commit message, asserting only that they wrote the code or have the right to contribute it under the project’s existing license. Developers love it, it rarely trips corporate legal alarms, and if your goal is to grow the ecosystem and aggregate contributions fast, the DCO is the gold standard. The cost is total. A DCO transfers no broad rights, so the IP stays fragmented across every contributor, and you can’t relicense later without tracking down each one. Launch on Apache 2.0 under a DCO, and when AWS commoditizes you three years on, switching to a protective license means getting explicit permission from everyone who ever committed. That isn’t a hard task. It’s an impossible one.

For a venture-backed COSS company the recommendation is clear: a CLA is usually necessary to preserve the option for dual-licensing or defensive relicensing.

How to actually execute

Don’t let lawyers pick your license. Your business model picks it. An open-core model needs a permissive core and a proprietary wrapper. A dual-licensing model, selling exceptions to GPL, needs a copyleft base. Lawyers optimize for risk. You have to optimize for leverage.

Gate features by buyer versus user. When you decide which features go in the free core and which go in the paid tier, ask who the feature serves. Does it help an individual developer build an app, the CLI, local testing, and raw speed? Make it free. Does it solve a problem for a manager, an auditor, or a VP, compliance, reporting, or team management? Make it paid. The developer is the user. The manager is the buyer, and the buyer is who pays.

Manage copyright deliberately. A CLA hands you the rights to relicense later, at the cost of contribution friction. A DCO keeps contribution easy at the cost of relicensing freedom. For a venture-backed company that may one day need to launch an enterprise edition or defend against a hyperscaler, the CLA is usually the right call.

Let the business model dictate the legal strategy, never the reverse. Default to AGPL v3 when you need the strongest OSI-approved protection against hyperscalers and can absorb the enterprise procurement friction that comes with it. Default to MIT or Apache 2.0 only when ubiquity is the whole game and cloud extraction risk is genuinely low. Look hard at FSL if you’re a modern SaaS company looking for a principled path to commercial sustainability. The license is the one decision you make under no pressure and live under for years. And the asymmetry never moves: loosening is free, and tightening is the door that swings one way.

Subscribe now

GitHub stars don’t pay the bills. Neither do fork counts or Docker pulls. They’re the best top-of-funnel signal a commercial open-source founder will ever get, and they tell you almost nothing about the size of the business you can build. Every credible go-to-market plan starts somewhere less flattering, with an honest count of the people who will actually open their wallets.

Total Addressable Market (TAM) is that count, expressed as a ceiling. It’s the revenue you’d book if you won every enterprise customer on earth who could buy your commercial offering, the theoretical top of your business rather than your project. Two things hang on the number. It sets the line you draw between the free tier and the paid one, and it’s the figure an investor uses to decide whether your model can return a venture-scale fund.

Most founders get TAM wrong in the same direction, upward. Your open-source database does not have a TAM of $100 billion just because that’s what the world spends on databases. That slide looks impressive until someone asks how close you are to displacing Oracle or AWS, and the answer is “not close.” A TAM built on total community downloads is a vanity number. It aims your sales budget at people who were never going to pay, and it drains the runway you raised to find the ones who would.

You run two funnels at once. The community funnel feeds on free downloads, stars, and developer goodwill. The commercial funnel feeds on enterprise features, managed cloud, and SLAs. Confusing the two is the original sin of COSS finance, and experienced investors smell it on contact, because claiming the entire database spend as your market is the same as admitting you can’t tell a free user from a buyer.

A tight definition does the opposite. It keeps your strategy anchored to the slice you can actually win, and it proves to a board that you did the arithmetic before you asked for the check.

The crowd at the door is not the market

Open source democratizes technology, which is the whole point and also the source of the confusion. Your software gets downloaded by students, hobbyists, weekend tinkerers, three-person startups, and the Fortune 50, all from the same release page. That produces an enormous pool of Total Addressable Users, basically every developer who could benefit from running your code for free. Your TAU dwarfs your TAM. Always.

Your TAM is the much smaller subset who work somewhere with the budget, the operational scale, and the specific pain that needs your paid offering. The crowd at the door isn’t the market. It’s the reason the market exists at all.

The classic mistake is multiplying total deployments by enterprise contract value. A hundred thousand active open-source deployments times a $50,000 enterprise tier looks like a $5 billion TAM, and it’s a mirage. Somewhere between 95 and 99 percent of those deployments will never send you a dollar, which is open source working exactly as designed. Your free users are your marketing engine and your QA department. They aren’t your buyers.

Getting to a real number means running those users through a brutal, realistic conversion filter.

Your pricing model decides your market

In traditional SaaS, TAM is close to a multiplication problem: companies that need the software times the subscription price. In COSS, the number swells or collapses depending on how you decide to charge for free code. Pick the vehicle before you run the math.

The support-and-services model is the Red Hat path. You give the software away and sell SLAs, training, and emergency patches. The customer base is wide, but contract values stay low, margins stay thin, and your ceiling is whatever companies will pay for insurance against their own infrastructure.

Open-core is the path Elastic and GitLab took. The core is free, and the enterprise features live behind a license: SSO, RBAC, compliance reporting, and high availability. Contract values climb, but the market narrows to mid-market and enterprise buyers with real security and compliance obligations. A ten-person startup never enters your TAM because nobody that small needs row-level access control.

Then there’s managed cloud, the MongoDB Atlas and Confluent path, which usually produces the largest and most defensible market of the three. You stop selling features and start selling uptime and the elimination of a DevOps payroll line. The market widens at both ends, small companies that lack the talent to self-host, and large ones that would rather hand off the operational burden than staff for it.

Whatever you pick, the TAM has to reflect its pricing and its limits, not a generic count of everyone who could install the thing.

Three ways to size it

You have three methods, and a COSS founder needs all three, because each one answers a different person in the room.

The analyst filter, from the top down

Top-down starts wide and narrows. You find a Gartner or Forrester line that reads “global enterprise spend on monitoring and observability is $15 billion a year,” and you carve it down.

A generic startup says “capture 5 percent and the TAM is $750 million” and stops there. A COSS founder keeps filtering. Start with the $15 billion. Strip out the spend locked into legacy proprietary mainframes that will never touch open infrastructure; if 40 percent of the market is actively modernizing, you’re down to $6.0 billion. Then ask how much of that $6.0 billion belongs to organizations willing to pay a vendor for managed open source rather than running it themselves. Call it 30 percent, and the top-down number lands at $1.8 billion.

This view is fast and imprecise by construction. It rests on broad assumptions about how a whole market behaves, which makes it useful for a sanity check or a macro vision and dangerous as a sales quota. Use it to prove the market is real. Don’t let anyone on your team carry it into a forecast.

The open-source funnel, from the bottom up

Bottom-up is the method that wins Series A rooms. You build the number from your own community data and a sharp Ideal Customer Profile, unit by unit, and the act of building it proves you know exactly who buys and what they pay.

The equation is a chain of filters:

TAM = (target organizations) × (share with the specific pain) × (COSS conversion rate) × (average contract value)

Walk it with real numbers. If your tool requires Kubernetes, your universe is companies running Kubernetes in production, say 50,000 mid-market and enterprise accounts worldwide. Now the pain filter. Your commercial product does multi-region replication, which only matters to companies large enough to need multi-region setups, so 20 percent qualify and the pool drops to 10,000. Then the conversion rate, which is the number that actually governs your business. Of the companies that need the technology, how many pay rather than self-host the free build? Successful open-core conversion runs 2 to 5 percent of the active base. Be aggressive, take 5 percent of these highly qualified orgs, and you get 500 paying customers. Price the managed enterprise cloud at a $50,000 ACV from early pilots or competitor benchmarks, and the chain closes:

10,000 qualified orgs × 5% conversion × $50,000 ACV = $25,000,000.

A $25 million beachhead sounds small to a founder dreaming in unicorns. It’s far more persuasive to a Series A partner than a fabricated $10 billion top-down claim, because it shows you know how to land your first 500 logos. Expansion comes later, when you add features, open new regions, or drop a self-serve tier that lowers the floor.

Value theory for the market that has no report yet

Value theory earns its keep when you’re creating a category, replacing a legacy giant, or solving a problem in a way nobody has named. Instead of carving up existing software spend, you price the problem itself. In open source, the problem usually gets measured in reclaimed engineering hours and infrastructure you no longer have to run.

The question to ask: if an enterprise adopts our managed open-source cloud, what’s the dollar value of the DevOps salaries, the downtime, and the legacy licenses they delete?

Picture a next-generation open-source vector database for AI workloads. No analyst tracks “vector database spend” yet, so you reason from value. Companies shipping AI features pay specialized engineers roughly $200,000 a year to hand-build data pipelines on databases that were never meant for the job. Your managed cloud removes half that custom work, saving $100,000 a year. Because you’re handing the customer $100,000 in hard value, a $30,000 ACV is easy to defend; it leaves $70,000 in their pocket. Estimate 15,000 companies actively deploying generative AI in your target regions, and the math is:

15,000 companies × $30,000 ACV = $450 million.

Value-based TAM is speculative, and without strong case studies it’s hard to hold under questioning. For founders leading a genuine shift, it’s often the only honest way to size an uncharted market. Be ready to defend, line by line, what a DevOps engineer’s time is worth to a CFO who would rather not believe you.

When the hyperscaler forks you

Every COSS pitch reaches the same question, and you should want it asked early. What happens when AWS, GCP, or Azure forks your project and runs it as a managed service? Does your TAM go to zero?

This is the recurring fear of commercial open source, and it isn’t paranoid. A hyperscaler that wraps your free code in its billing console can, in theory, take the entire managed-cloud market you just sized. It has happened. When Elastic relicensed Elasticsearch under the SSPL in 2021, AWS forked the last open version and shipped it as OpenSearch, billing console and all. A credible TAM doesn’t pretend the threat away. It shows the moat in the numbers.

Licensing is the first wall. A Business Source License or SSPL legally blocks the hyperscalers from offering your software as a competing managed service. It protects the market, and it costs you goodwill with the open-source purists, so price that trade deliberately. The second wall is the enterprise delta. Your commercial TAM has to rest on features the open-source core doesn’t carry. AWS can fork the core and still lack your control plane, your advanced security modules, your specialized console, which means your market is defended by the parts you never gave away. The third wall is multi-cloud. Enterprises are afraid of AWS lock-in, and a managed service that runs cleanly across AWS, Azure, and GCP holds customers an Amazon-only fork can only trap.

A strong presentation names the hyperscaler threat out loud, then shows the arithmetic for why a buyer pays the people who built the project instead of the cloud renting it back to them.

An example, sized two ways

Say you’re building MeshFlow, an ultra-lightweight open-source service mesh aimed at mid-sized companies on Kubernetes.

The top-down pitch sells the vision. Global enterprise spend on cloud infrastructure software hits $120 billion next year; networking and security are roughly 10 percent of it; the macro TAM is $12 billion.

The bottom-up pitch sells the execution, and it’s where the company actually lives. Fortune 50 banks are entrenched with legacy gear and heavyweight tools like Istio, so you skip them. Your sweet spot is the mid-market, companies with 100 to 1,000 engineers who need simplicity more than they need knobs. Tech-stack scraping turns up 30,000 mid-sized SaaS and tech companies on Kubernetes worldwide. About 30 percent of them, 9,000 orgs, have hit the microservices complexity where a mesh stops being optional. Your own telemetry shows 10 percent of those, 900 orgs, are already running the free build. MeshFlow Cloud manages the control plane for $25,000 a year:

9,000 target orgs × $25,000 ACV = $225 million beachhead.

In the room, you say both numbers in one breath:

“Our beachhead TAM is $225 million: 9,000 mid-market Kubernetes shops that need a simplified service mesh at a $25k ACV, and we already have open-source deployments inside 10 percent of those accounts, which is a warm pipeline our sales team can work today. As we ship multi-cluster compliance and move upmarket, we have a clear line into the broader $12 billion cloud-native networking market.”

That tells a coherent story. It separates the macro-market you can imagine from the developer segment you can win this year, and it shows you know the difference cold.

Open source builds the market it later sells to

The COSS model does something proprietary software can’t. It doesn’t just take a share of an existing market, it grows a new one. Enterprise software is expensive, gated behind a sales call, and a chore to trial. Open-sourcing the core drops the barrier to zero, and a developer who could never get a $100k legacy license approved pulls your tool down in seconds.

Those developers carry your software into industries, geographies, and company sizes the legacy vendors never bothered to address. The small accounts grow. Their usage scales. Some convert into paying customers for your commercial tier, and they arrive already knowing the product, having run it for a year before anyone signed anything.

When you present TAM, claim that effect explicitly. Open source is a wedge that keeps widening the borders of your market by raising buyers the top-down B2B playbook would have ignored.

A small market can be the whole point

Founders panic that a small TAM sinks the raise. Investors do love big markets. They love fast, efficient, dominant businesses more, and in open source a tightly drawn market is often the asset rather than the liability. Developers distrust the generic all-in-one platform. They adopt the opinionated tool that solves one acute pain perfectly, and they adopt it hard.

Take an open-source tool built only to manage compliance configurations for FinTech startups running Terraform. Maybe 2,000 well-funded startups on earth fit the profile. In raw dollars the TAM looks like a rounding error. But the pain is severe and regulatory, so adoption inside that niche is fast and loyal, and the community standardizes on your tool because there’s no second choice worth evaluating. Conversion to your commercial compliance-auditing cloud runs far above the open-core norm, maybe 20 percent instead of 5, and the contracts are large and long because a failed audit costs millions:

2,000 orgs × 20% conversion × $75,000 ACV = $30 million in defensible, high-margin revenue.

That’s stable revenue and enviable net revenue retention, earned while you own the mindshare of an entire industry. Investors who know open source recognize the shape. Winning is far easier when your roadmap is laser-focused and you’re not out-marketing 50 generic competitors at once. The best open-source VCs say a version of the same thing: better to own 100 percent of the mindshare in a critical niche than to be the tenth proprietary option in a loud, crowded one.

Domination doesn’t stay contained, either. The community pulls your product into adjacent markets on its own. Developers change jobs and bring your tool from FinTech into Healthcare, and the TAM expands organically while you sleep. The niche was the tip of the spear, never the ceiling.

What to actually do with the number

Know your numbers. Separate the free crowd from the paying buyers. Be honest with yourself about where your monetization model stops, even when honesty shrinks the slide.

Build the TAM bottom-up on assumptions you can defend one at a time and hold the number in its proper place: not a promise of revenue, but a direction for your focus. A TAM done right tells your team and your investors the same thing about you. You have the operational maturity to turn a popular repository into a business, and you already know which 500 customers come first.

Subscribe now

You can have 40,000 GitHub stars, a hundred forks a week, and a Slack channel that never sleeps, and still not have a business. Stars tell you people run your code. They don’t tell you anyone will pay for it, and downloads aren’t revenue either.

For a commercial open-source (COSS) founder, go-to-market is how free adoption turns into paid revenue. It comes down to a list of unglamorous questions. Who actually needs the enterprise or cloud version? What does the paid tier do that the free tier doesn’t? How does the buyer find it? And why would they pay when they could keep self-hosting the code they already have, for free? GTM is the work of lining up marketing, sales, product, pricing, and distribution behind one named customer, with the line between free and paid drawn on purpose instead of by accident.

The easy move is to “sell to the community.” It’s the path of least resistance, and it’s usually wrong. Before you hire a single rep, answer the question everything else hangs on: who pays, and why?

Why your community is not your market

Pick your market wrong and you die the most common COSS death, which is selling to people who have no budget.

I watched one COSS team spend three months sharpening a pitch aimed straight at the developers who contributed to their repo. They nailed the user and missed the buyer. They chased startups that were perfectly happy on the free self-hosted version, and never once called the enterprise compliance teams who had both the pain and the purchase order. A quarter of their sales hours went into trying to pull money out of people who wanted, reasonably, to keep using free software. You can guess how that quarter ended.

Your community tells you who uses your code. Your ideal customer profile tells you which companies are worth a sales conversation. Treat them as the same list and you’re selling blind.

A defined market keeps the rest of the company honest, too. Tell an investor your target is “anyone who downloads the project” and what you’ve actually told them is that you don’t have a beachhead. Pick a narrow segment you can win a paid contract in. Win it. Then widen out.

From ICP to message

Your ICP and personas are where the value proposition comes from. Once you know a segment’s specific pain, you can write a line that makes the buyer realize they need the commercial tier.

Say your ICP is a mid-market engineering org drowning in the cost of self-hosting your tool. The headline isn’t the code, it’s the cost of running it:

“The power of [Project Name] without the DevOps headache. Fully managed, secure, ready to scale.”

That goes straight at the wasted time, the infrastructure bill, and the fear of what breaks at scale. Compare it to something like “Next-Gen Data Management,” which speaks to nobody.

The user is not the buyer

In COSS, tailoring the message usually means splitting the practitioner from the executive, because they want different things.

The lead developer cares about developer experience, open APIs, raw performance, and not getting locked in. The VP of Engineering (or the CISO) cares about SOC 2, SSO, SLAs, and not owning the maintenance. So write two angles. For the developer champion: “fits straight into your existing CI/CD pipelines.” For the VP: “enterprise-grade security, RBAC, and 99.99% uptime.” Same product underneath. Different language on top, each in the dialect one persona actually respects.

Mirror their vocabulary and you signal you understand their world. Selling to developers, you talk PRs, workflows, open-source flexibility. Selling to the enterprise buyer, you talk total cost of ownership, governance, managed infrastructure. Use the wrong words and the reader stops trusting you somewhere around the first line.

Positioning against your own free product

COSS has a strange wrinkle here. The status quo you have to beat is often your own free product. So make the contrast loud. If the whole pitch is that you take maintenance off their plate, say it in exactly those words:

“Stop waking up at 3 AM to fix database nodes. Let the creators of [Project Name] run it for you.”

That puts the commercial product up against the real cost of self-hosting, which is the only competitor that matters here.

If you serve several industries, give each one its own landing page. The open-source engine underneath doesn’t change. What changes is the case studies, the terminology, and the compliance language, and a financial-services buyer who needs strict audit controls will convert at a higher rate on a page written for him than on a page written for everyone (and therefore no one in particular).

What the groundwork buys you

Define the market, segment it, build the ICPs, separate the users from the buyers, and you’ve got the raw material for messaging that actually lands.

Skip all that and you ship copy that reads like a README: technically accurate, commercially dead. Put in the hours and you can write something precise. When your users are DevOps engineers and your buyers are CTOs, the line almost writes itself: “Give your engineers the open-source tools they love, with the compliance, SSO, and audit logs your enterprise requires.”

Anchor the message in a real ICP and a clear read on who uses versus who pays, and it stops sounding like a pitch. It starts sounding like you know what your open-source success is worth to the person who has to sign the check.

Open source is the strongest distribution strategy in enterprise software, and the companies that treat it as charity leave most of the value on the table. If you’re building developer-facing infrastructure, data tooling, DevOps platforms, or security software, the commercial open source model hands you advantages no marketing budget can buy. Whether you capture them comes down to execution.

Start with the numbers, because they settle the argument before any theory gets a chance to. The Linux Foundation’s State of Commercial Open Source 2025 report draws on 25 years of venture data across 800 VC-backed startups, and COSS beats its closed-source peers on every financial dimension that matters:

• COSS median IPO valuation of $1.3 billion against $171 million for closed-source peers, a 7.6× premium

• COSS median M&A valuation of $482 million against $34 million, a 14.2× premium

• COSS companies raise 20 to 34% faster than closed-source peers at each stage

• COSS companies command 1.29 to 1.60× higher valuations at Seed and Series A, with the Series A premium the widest gap anywhere in the lifecycle

None of these premiums is luck. They fall out of the economics: lower customer acquisition cost, faster product-market validation, a community doing R&D the competition has to pay for. That last one is the wall a competitor can’t scale, and it runs through everything below.

Five things the model gives you that money can’t

Faster product-market fit comes first. An open source project is a pre-commercial signal no volume of customer interviews can match. When 10,000 developers download your project and 500 of them file issues, you’ve got harder evidence of real pain than any focus group will produce. HashiCorp waited until Terraform was genuinely everywhere before pushing enterprise features, and by then the market was pulling those features out of them. The proprietary SaaS path runs the other direction: you spend $2M on sales and marketing just to find out whether anyone wanted the thing.

Then there’s a lower cost to acquire each customer. Download-and-deploy growth cuts effective CAC by 30 to 50% against sales-led equivalents. MongoDB’s own data shows that 25% of its customers spending $100K+ ARR started as self-serve users, and those self-serve-originated enterprise accounts reach $1M ARR 15% faster than the ones sales sourced directly. Your OSS project runs outbound around the clock, in every country, and never files an expense report.

Third, community as R&D leverage. (This is where the compounding actually lives.) GitLab took in more than 6,500 external merge requests in calendar 2025 alone, real product contributions from engineers who draw no GitLab paycheck. Open Core Ventures’ handbook documents how community value and business value feed each other over years: the open core improves, which pulls in more users, which produces more contributors, which improves the core again. And the cycle turns at roughly zero marginal cost to you.

Fourth, enterprise trust, the kind that wins procurement fights a proprietary vendor can’t. Security teams can audit your code. Legal can read your dependencies. Architects see your internals instead of guessing at them. This matters most in regulated industries (financial services, healthcare, government) where a security review can drag on for months, and a product that survives one closes deals a black box never reaches.

Fifth, a hiring moat. The contributors who already know your codebase make your strongest engineering hires, and they often arrive inbound. Good engineers have opinions about their tools, and when you build the best one in a category, a fair number of them quietly decide they’d rather be working on it with you than on whatever they’re stuck with now.

The moat a competitor can’t dig

Every other distribution advantage has a counter. Outspend the marketing, poach the sales team, fine. But nobody conjures 50,000 GitHub stars, 10,000 production deployments, and 300 active contributors on a deadline. A community moat takes longer to build than any proprietary edge, and it lasts longer once built.

Community creates distribution through three separate channels. The first is word-of-mouth between practitioners: a developer who solved a real problem with your project recommends it unprompted, in code reviews, in Slack threads, in Stack Overflow answers, with a credibility no marketing copy manufactures. The second is ecosystem gravity. Once your project becomes the standard in a space (Terraform in IaC, Kafka in event streaming, Elasticsearch in search) every tutorial and blog post and job description that names it reinforces your position, and you stop competing for attention because you’ve become the default. The third is recognition that shows up before your sales team does. When the buyer’s engineers already run your project in production, you walk into the deal with a reference customer sitting at the table. Confluent landed 136 Fortune 500 companies at IPO partly because more than 70% of the Fortune 500 was already running Apache Kafka, the project Confluent’s founders created. Your sales team negotiates with organizations your community already won.

The unit economics, run right

The financial model is clean once you execute it correctly. Grafana Labs crossed $270M+ ARR at 69% YoY growth with 20 million users and roughly 5,000 paying customers. That’s a conversion rate of about 1%. The math holds because the 1% who pay carry high ACV ($25K to $500K+), net revenue retention is strong through land-and-expand, gross margins sit at 80 to 90%, and CAC on community-sourced leads is structurally low. Open core companies that run the model well land SaaS-like margins: Grafana at 80 to 90%, GitLab at 87%. The community subsidizes your margin directly, by cutting the marginal cost of building the core.

Where the moat never forms

Be honest about the failure modes before you commit. COSS punishes the wrong fit harder than proprietary SaaS does.

Some products have no natural community. The model works because developers choose their own tools and build network effects around them. Sell top-down to procurement, with non-technical buyers signing off (ERP, financial compliance, HR systems) and community-led growth just won’t show up the way COSS needs it to. The Linux Foundation notes that roughly 90% of COSS companies operate in infrastructure software rather than business applications. That split isn’t a coincidence.

Some moats live in data or network rather than code. If your defensibility is a proprietary dataset, a user network, or a curated marketplace instead of a technical implementation, open-sourcing the code gives away little and earns you little distribution back. Marketplace and data businesses are rarely served well here.

Some companies need revenue now, and COSS ramps slowly: you invest in community before you can charge for value. HashiCorp didn’t start meaningful commercialization until 2016, four years in. Databricks had enormous Apache Spark traction by 2015 with, in Ali Ghodsi’s own words, essentially no monetization path. If you need $500K ARR in twelve months to keep the lights on, this isn’t your road.

Some teams can’t sustain the investment, and a half-executed COSS strategy is worse than none. A neglected project, slow on issues, stale docs, no maintainer in sight, actively destroys trust. A zombie repository does more damage than never open-sourcing at all. Without the engineering bandwidth and the commitment to keep a project healthy, don’t start one.

And some attack surfaces are simply too narrow. Monetizely’s research benchmarks free-to-paid conversion at 0.3 to 3%. If your total addressable community is a thousand developers worldwide, the enterprise pipeline that funnel produces will be thin. The funnel needs a large enough developer population to work at all.

What the data settles

COSS is a complete business model with its own economics, not a marketing tactic bolted onto a proprietary core. It wins on distribution, on trust, and on a community moat proprietary SaaS can’t copy. The IPO premium (7.6×), the M&A premium (14.2×), and the funding-speed advantage stopped being arguable a while ago. It also fails, predictably, when the product has no natural developer community, when the moat is data or network instead of code, or when the team can’t sustain the community the model demands. Both the premiums and the failure modes are real. The job is knowing which camp you’re in before you build a go-to-market around either one.

I’ve spent three decades in technology, watching brilliant founders pour their hearts into building world-changing open-source projects. Yet, time and again, I have seen these same founders fall prey to a dangerous illusion: the belief that a massive community and a mountain of GitHub stars automatically forge a viable business. Let me be clear: GitHub stars often reflect popularity more than health or sustainability. Popularity is not a business model, and raw downloads do not equal a go-to-market (GTM) strategy.

For years, a flawed narrative has persisted, framing open source as a kind of digital charity. That era is over. Open source is an asset class—arguably the most undervalued one in the modern economy. The data is conclusive: Commercial Open Source (COSS) companies consistently achieve 7x greater valuations at IPO and 14x at M&A compared to their closed-source peers. However, COSS founders face a unique positioning paradox that traditional proprietary SaaS founders simply do not understand. Because your baseline offering is a fully functional project that developers can deploy for free, your biggest competitor is often your own free product. The traditional B2B SaaS playbook shatters when you have to convince people to pay for something they can technically get for free.

To win, you must master the dual-engagement model by fundamentally separating the user from the buyer. Throughout these pages, you will learn how to navigate this distinct two-level persona structure: the End-User (the developer or DevOps engineer who adopts the free code) and the Economic Buyer (the executive who signs the check). You will learn how to delight the developer with open APIs and frictionless workflows, while simultaneously selling Total Cost of Ownership (TCO), compliance, and risk mitigation to the C-suite.

When capital and community are aligned, everyone benefits. A thriving open-source community acts as an unstoppable top-of-funnel engine. This book provides the actionable frameworks—from defining your Total Addressable Market (TAM) and Ideal Customer Profile (ICP) to structuring your packaging and messaging—necessary to seamlessly feed that community into a highly efficient enterprise sales machine. By defining your commercial value, respecting the boundaries of your community, and executing a targeted strategy, you can turn developer enthusiasm into sustainable, scalable enterprise revenue.

— Matt Trifiro, April 2026