Why do open source companies struggle to convert community users into paying customers?

Because the community user and the enterprise buyer are different people with almost opposite needs. The community user wants to install the tool and get something working fast. The enterprise buyer wants reliability, security, audit trails, and a support line they can reach in the middle of the night. Companies that position the commercial product as 'the same thing you are using for free, but supported' fail to give either audience what they need. According to Grafana Labs COO Douglas Hanna, most open source companies should expect only 1 to 3% of users to convert to paying customers, not the 50%+ typical in traditional SaaS. Community size is not a pipeline proxy.

What was the real problem with HashiCorp's BSL license change?

The license change was a symptom. The real problem was that HashiCorp had not built a compelling commercial value proposition for HashiCorp Cloud Platform that was distinct from self-hosted Terraform. When competitors started building managed offerings on the same code, HashiCorp tried to solve a positioning problem with a licensing solution. The community read that correctly. Within a month, the OpenTF manifesto had 33,000 GitHub stars and pledges from nearly 140 companies. By September 2023 the OpenTofu fork was in the Linux Foundation. If your open source project is valuable enough to copy, the answer is better commercial positioning, not a more restrictive license.

How do successful open source companies position the commercial product?

They maintain two distinct identities in parallel. The OSS project is a public good. The commercial product is a different thing entirely, sold on different attributes. Grafana Cloud is a managed observability platform that runs on open source components, sold on managed operations rather than 'Grafana with support.' Supabase Cloud is the fastest way to ship a backend, with the managed cloud as the default path to production, sold on speed-to-launch rather than 'hosted Supabase.' Awareness comes from the open source side, and revenue comes from the commercial side. The companies that get this right never blur the line.

Why is GitHub stars a bad pipeline metric?

Because GitHub stars measure community interest, which is the input to the OSS funnel, not the input to the commercial funnel. To put it in rough terms, a 1 to 3% community-to-customer conversion rate would turn a project with 100,000 stars into maybe 1,000 to 3,000 commercial signups, and only a fraction of those become enterprise deals. Sales teams that treat GitHub stars as marketing-qualified leads end up chasing community members who were never going to be customers, while neglecting the actual enterprise evaluation surfaces (security review, procurement processes, executive briefings) that close deals.

What is the right mental model for open source GTM?

Treat the OSS project as your marketing engine and the commercial product as your actual business. The project builds trust at scale by being genuinely useful and genuinely open. The paid product earns revenue from a small group of users who have different needs. Both motions run side by side, kept deliberately apart. Apollo GraphQL is a good example: their developer advocates stayed out of pricing conversations, and their enterprise sellers stayed out of the community. Keeping those two roles separate is what made it work. Most COSS companies stumble because they ask one motion to handle both jobs at once.

What open source companies get wrong about go-to-market

A developer tools company has 50,000 GitHub stars, an active Discord, regular community contributions, and a year of zero enterprise close rate. The CEO is in board meetings explaining why such an obviously successful open source project can't generate enterprise revenue. The board is starting to ask whether the company is actually a business or just a popular GitHub repository.

The pattern is so common at commercial open source companies that it deserves its own diagnosis. HashiCorp, Grafana Labs, and Apollo GraphQL have all navigated some version of this reckoning. The most common open source GTM mistake is treating the OSS project and the commercial product as the same thing with different license agreements. They are different things that run on different funnels. The OSS project acquires community. The commercial product acquires customers. Conflating the two produces positioning that serves neither audience, and a commercial motion that stalls just as the community is hitting its peak.

I covered the basics in building a business on an open source product back in 2022. The wave of COSS companies that raised aggressively in 2021 and 2022 has now spent enough time hitting this wall to make the failure pattern visible in detail. This post is the sharpening of that earlier piece, with concrete examples and one specific argument.

Two audiences with almost opposite needs

The OSS community member and the enterprise buyer are different people with different jobs, different evaluation criteria, and different needs from the same software. Positioning that wins the community user (developer-friendly, fast to start, genuinely open) actively repels the enterprise buyer, who wants reliability commitments, security docs, and a vendor they can reach when something breaks at night. Most COSS companies write for the first audience and wonder why the second never converts.

The community member wants to clone a repo, run a command, and be productive quickly. They want documentation that explains how to do the thing, examples that work, and a Discord where someone helpful answers questions. Their internal advocacy is "I tried this on a side project and it just worked." That's the moment the OSS funnel was designed for.

The enterprise buyer wants reliability commitments, security review documents, audit trails, SOC 2 reports, and a vendor they can call when production is down in the middle of the night. Their internal advocacy is "we have evaluated five vendors, this one passed our procurement process, and we have a signed contract." That's the moment the commercial funnel needs to support.

The two audiences sit at opposite ends of a procurement question, not at adjacent points on a spectrum. They are different people doing different jobs, judging the software by different criteria.

Project-community fit is not product-market fit

Andreessen Horowitz published a useful three-stage framework for OSS companies (a16z.com). Project-community fit is when the OSS project resonates with developers and they adopt it. Product-market fit is when the broader market recognizes the technology category. Value-market fit is when a meaningful subset of those users will pay for something.

OSS companies hit the first two stages much earlier than the third. The gap between "this is widely adopted" and "people will pay for this" is where most COSS companies run out of runway. Crossing it requires a separate commercial motion, not a license change.

Grafana Labs COO Douglas Hanna spelled out the math on First Round Review (review.firstround.com). Most OSS companies should expect 1 to 3% of users to convert to paying customers, not the 50%+ typical in traditional SaaS. That's the planning input, not a problem to fix. A company with 100,000 OSS users that builds for a 50% conversion will go bankrupt. A company that designs the commercial motion for a 1% conversion at much higher value-per-customer will succeed.

The implication that nobody likes hearing: GitHub stars and Discord member counts measure community velocity. They do not measure pipeline. Conflating community signals with sales signals leads to a sales team chasing the wrong people while neglecting the enterprise evaluation surfaces that actually close deals.

The three moments where OSS GTM breaks

Treating the OSS project and the commercial product as one motion produces three specific failure modes. The first is measuring community velocity as a pipeline proxy. The second is designing the free tier to convert community users rather than attract enterprise evaluators. The third is positioning the commercial product as a paid upgrade of the free project. Each one is a different expression of the same underlying confusion about who the two audiences are.

The first is when GitHub stars and Discord members are used as pipeline signals. DevRel sends weekly reports on community velocity. Marketing treats it as top-of-funnel. Sales asks for warm intros from community members. The community notices, feels used, and the most influential contributors, the ones who actually have credibility inside enterprises, stop showing up. The community shrinks. So does the pipeline that depended on it.

The second is when the free tier is designed to convert community users rather than to attract enterprise evaluators. The free tier becomes a stripped-down version of the commercial product, gated and limited, instead of a real OSS project. Community members feel cheated because they can no longer use the free version for serious work. Enterprise evaluators ignore it because it doesn't look like the kind of evaluation environment they need. The product loses both audiences.

The third is when the commercial product is positioned as "the professional version of what you're already using for free." That collapses the entire distinction. If the commercial product is just the OSS plus support, the buyer correctly concludes they can self-host with a small ops team for a fraction of the cost.

The commercial offering has to do something the OSS doesn't, like managed operations, scale, reliability guarantees, or integrated observability, and the positioning has to make that distinct value visible. I covered the deeper version of this in does positioning still matter. For OSS companies it matters more, because your buyer is comparing the commercial product to your own free product, not to a competitor.

What the HashiCorp BSL fight actually revealed

The HashiCorp BSL announcement in August 2023 is the cleanest recent case study. After years of dominant Terraform adoption, HashiCorp switched the license from MPL to BSL. The stated reason was protecting commercial revenue from competitors using Terraform to build managed offerings. The actual problem was upstream of the license.

HashiCorp hadn't built a compelling enough reason for enterprises to pay for HashiCorp Cloud Platform over self-hosted Terraform. The cloud product looked too much like "Terraform plus support." When competitors started shipping managed Terraform offerings, the gap between HashiCorp's commercial value proposition and what self-hosting provided was small enough that customers and competitors alike could fill it. The license change was an attempt to create commercial value through legal restriction rather than through positioning.

The community read it correctly. The Register's coverage in August 2023 (theregister.com) tracked what happened next. Within a month of the announcement, the OpenTF manifesto had 33,000 GitHub stars and pledges from nearly 140 companies and 700 individuals. The fork was accepted into the Linux Foundation by September 20, 2023, as OpenTofu. A year of community trust built since 2014 was eroded in a quarter.

The takeaway here is about positioning, not licensing. BSL itself is a defensible license choice. What licensing changes can't do is solve commercial positioning problems. If your open source project is valuable enough that competitors want to fork it, the right answer is better commercial positioning, not a tighter license. HashiCorp had a positioning problem and reached for a legal tool. The community responded by removing them from the equation entirely.

What the companies that get this right do differently

Grafana Labs, Supabase, and Apollo GraphQL all run explicit separations between the OSS project and the commercial product, with different positioning, different audiences, and different motions. None of them position the commercial product as "the OSS with support." Each one sells something the OSS genuinely cannot provide at scale: managed operations, production reliability, or enterprise integrations.

Grafana Labs maintains a clear separation between the OSS project and Grafana Cloud as a distinct commercial product. Their public "big tent" philosophy keeps the OSS genuinely open and community-governed. Grafana Cloud is sold on reliability, scale, and managed operations, not on "you get more features." The positioning difference is the moat. Customers who buy Grafana Cloud are paying for managed operations they can't easily replicate, not for features they could get for free with effort.

Supabase has 100,000-plus GitHub stars and hundreds of thousands of Discord members. Their commercial positioning is "the fastest way to ship a backend," with the managed cloud as the default production path. The OSS drives awareness. The cloud captures value. The two motions are clearly separate and clearly aligned.

The same dynamic shows up in the broader PLG mechanics for developer products and in why developer experience is your best growth lever. The OSS is part of the experience that earns the right to sell the commercial product, not the funnel for it.

Apollo GraphQL ran an explicit organizational separation that they called the "love sandwich" (work-bench.com). Developer advocates who never talked about pricing. An enterprise sales team that never talked to OSS users. Educational content that drove 25% of signups, with those users onboarding at twice the rate of other channels.

The two motions ran in parallel with deliberate non-crossover. Developers experienced the product with no commercial pressure. Enterprise deals were negotiated separately. Keeping the two functions structurally apart is what made the model work.

For early-stage founders building this from scratch, the developer marketing for startups guide covers the team and motion design. The headline rule is the same one this post is making: two motions and two audiences inside one company.

What are the three diagnostic questions for open source GTM?

Before any tactical change, run these three questions. They are designed to surface the specific place where the OSS motion and the commercial motion have been collapsed into one. Most COSS companies fail all three. A company that passes all three has structural separation, accurate funnel metrics, and a commercial value proposition that stands on its own without the OSS as a crutch.

First: are you measuring community velocity (GitHub stars, Discord growth, contributor count) and commercial pipeline as if they live in the same funnel? If the answer is yes, the funnel is wrong. Those are different funnels, with a low single-digit conversion rate between them.

Second: if you removed the OSS project tomorrow and only sold the commercial product, what would the buyer be paying for? If the answer is "support and a logo," you have a positioning problem that no licensing change will fix. If the answer is "managed operations, scale, reliability guarantees, integrated observability, audit trails," you have a real commercial product. Most companies need to spend more time making the second answer obviously true.

Third: does the same person at your company own both the community motion and the enterprise sales motion? If yes, that person is being asked to play two opposed positions, and one of them is going to lose. The companies that make this work have structural separation between the two functions, not just philosophical separation.

Your OSS project is marketing. Your commercial product is the business. The companies that compound on open source in 2026 have stopped trying to make one motion do both jobs.