Sales-led, product-led, and now open source–led growth. Each paradigm has a different engine. Here's how they evolved, when each works, and why developer tools are betting on the third.
I've been watching growth paradigms shift for years. Sales-led growth dominated enterprise software for decades. Product-led growth promised to replace it. Now there's a third paradigm emerging—open source–led and community-led growth—and it's the one most relevant to anyone marketing developer tools.
Here's how they fit together, when each works, and why the best developer tool companies are building hybrid engines instead of picking one.
| Paradigm | Growth engine | Who decides | Typical for |
|---|---|---|---|
| SLG (Sales-led) | Sales team, relationships, outbound | Buyer, champion, procurement | Enterprise, high-touch, complex sales |
| PLG (Product-led) | Product trial, self-serve, usage | User, developer, team lead | SaaS, SMB, bottoms-up adoption |
| OSLG (Open source–led) | Community, contributions, ecosystem | Developer, maintainer, contributor | Dev tools, infrastructure, APIs |
None of these are new. What's changed is how they combine—and which one leads.
Sales-led growth is the oldest model. A sales team finds prospects, qualifies them, runs demos, negotiates contracts, and closes deals. Growth scales with headcount and pipeline.
It works when:
The problem for developer tools: developers don't want to talk to sales. They want to try the thing, read the docs, and decide on their own. SLG alone fails when your primary user is a developer who will ghost a demo request.
That doesn't mean SLG is dead. It means it's become the second motion—the one that kicks in after PLG or OSLG has already created intent.
Product-led growth flipped the script. Give users a free tier. Let them self-serve. Optimize the funnel from signup to activation to conversion. The product is the growth engine.
It worked. Slack, Notion, Figma—all PLG success stories. For developer tools, PLG meant: free tier, good docs, fast onboarding. Developers could evaluate without talking to anyone.
But PLG had a blind spot. It assumed the product trial was the whole experience. The shift to Experience-Led Growth (XLG) is really about expanding PLG to include docs, community, support, and onboarding as part of the growth engine. PLG optimized the funnel. XLG optimizes the ecosystem.
For developer tools, PLG is table stakes. You need a free tier and self-serve. But it's not enough on its own—especially when your competitors are open source.
Open source–led growth (or community-led growth—the terms overlap) is different. The growth engine isn't the sales team or the product trial. It's the community: contributors, maintainers, users who answer each other's questions, and the ecosystem that forms around the project.
How it works:
Companies like Supabase, GitLab, HashiCorp, and Grafana didn't grow because they had the best sales team or the smoothest trial. They grew because developers discovered them through GitHub, package registries, and community content—and stayed because the community was real.
The monetization question is real. Open core (free core, paid enterprise features), hosted/managed offerings (Supabase Cloud, Grafana Cloud), and support contracts are the common patterns. The point is: growth comes from adoption and community first. Revenue follows.
I've watched this shift happen in real time. Developer tools companies that used to compete on PLG metrics—signup rate, activation, free-to-paid conversion—are now competing on community health, contribution velocity, and ecosystem size.
A few reasons:
1. Developers trust what they can see. Open source removes the "what's actually running?" question. For security-sensitive tools, that's non-negotiable.
2. Distribution is built-in. GitHub, npm, PyPI, Docker Hub—these are discovery channels you don't pay for. A well-maintained OSS project gets found.
3. Community is a moat. A thriving Discord or GitHub Discussions space is harder to replicate than a landing page. The developers who answer questions, write tutorials, and build integrations are doing marketing you can't buy.
4. Talent and adoption compound. Contributors become candidates. Users become advocates. The best developer tool hires often come from the community.
5. AI is changing discovery. When developers ask ChatGPT or Cursor "what should I use for X?", the tools that get recommended are often the ones with strong community presence, good docs, and visible OSS adoption. Getting cited when developers ask AI is the new SEO.
The cleanest framing is: SLG, PLG, and OSLG are not mutually exclusive. They're layers.
Most successful developer tool companies run a hybrid:
| Company | Stage 1 | Stage 2 | Stage 3 |
|---|---|---|---|
| Supabase | OSS adoption | Hosted cloud (PLG) | Enterprise sales (SLG) |
| HashiCorp | OSS adoption | Commercial products | Enterprise sales |
| Vercel | PLG free tier, self-serve | — | Enterprise sales |
The question isn't "which one do we pick?" It's "which one leads, and how do we layer the others?"
| Pillar | What to do |
|---|---|
| Community | Invest before you need it. Build when the product is early—you can't retrofit later. |
| Docs & OSS | Treat as distribution. Your docs and repo are how developers find and evaluate you. |
| Trust | Don't measure community by MQLs. Community drives trust → adoption → revenue (long attribution). |
| Sustainability | Fund maintainers, contribute upstream. Be authentic—developers spot performative OSS. |
If you're building a developer tool and OSLG is part of your strategy, here's what actually matters:
Invest in community before you need it. The communities that drive growth—Supabase's Discord, Vercel's GitHub Discussions, Tailwind's channels—were built when the product was early. You can't retrofit community after you've already optimized for PLG funnel metrics.
Treat docs and OSS as distribution. Your documentation and your open source repo are marketing channels. Documentation as a marketing channel isn't a metaphor—it's how developers find and evaluate you.
Don't treat community as lead gen. The moment you start measuring community by MQLs, developers notice and leave. Community drives trust. Trust drives adoption. Adoption drives revenue—with a long attribution window.
Be honest about OSS sustainability. If your product depends on open source, position around sustainability authentically. Developers can tell the difference between "we love open source" and "we fund maintainers and contribute upstream."
SLG, PLG, and OSLG aren't sequential replacements. They're three engines that can run in parallel—and the best developer tool companies use all three, with OSLG or PLG leading and SLG supporting expansion.
If you're marketing developer tools in 2026, the question isn't whether to be product-led or community-led. It's how to build an engine where community and product drive adoption, and sales captures the value that adoption creates.
The paradigm that wins is the one that matches how your users actually decide. For developers, that's increasingly: discover through community, evaluate through product, expand through relationships.
Build for that.
Company models and OSLG strategy are now tables for reliable rendering. Remaining diagrams use vertical (TB) layout. Alternatives:
Paradigm evolution — compact 3-node vertical:
OSLG flywheel — vertical with explicit loop label:
Decision tree (which paradigm leads?):