Why Open Source as GTM Is Having a Moment
Is it the right choice for AI Infra?
A founder in the Vermilion portfolio recently asked if he should open source his product to help build momentum and drive adoption around a targeted pain point for developers. The answer is a layered one.
Open source used to be an ethos. A philosophy. A community thing. Now it’s a GTM strategy and in many cases, one of the most effective ones available to developer-first startups.
The same playbook built Elastic, Confluent, HashiCorp, and MongoDB into companies worth billions. Now we’re watching the next generation of founders try to run it at the AI layer. Some of our own portcos like CopilotKit and Cognee are doing it very well.
But OSS-as-GTM is not a cheat code. It has real trade-offs, real timing dependencies, and real failure modes. Getting initial traction is hard and takes grit.
Where some startups use star growth as measures of momentum, it’s getting harder to prove. A recent investigation found six million suspected fake stars across nearly 19,000 repositories. AI and LLM repos were the largest non-malicious category. Forks, contributor retention, and issue quality are harder to fake and tell you much more about whether anyone is actually using the thing.
Below are some ways to think about open source in your GTM strategy and what to consider from a product perspective to how hard it really is to turn open source users into enterprise customers. A note, this thinking assumes you are an early stage company. When you’re a larger and later stage entity, the open source strategy becomes a bit of a different ball game.
Why OSS Works as GTM (When It Works)
The mechanics of why it works are simpler than most people make them. GitHub stars, forks, and community pull requests create awareness that paid acquisition can’t replicate.
When every dev tool company is competing for the same developer attention and CAC keeps climbing, open source is one of the only distribution strategies that gets cheaper the more people use it. The motion that makes it work is simple in theory and hard in practice. An individual developer finds your project, installs it, gets value from it. They start advocating internally. The team adopts it. Someone with a budget eventually asks how to get enterprise support. The developer was your champion before you ever had a sales rep. That’s the dream. And when it works, it is genuinely one of the best sales motions that exists for infrastructure and tooling companies.
There’s also a compounding dynamic that most founders underestimate early on. Every commit, every release, every piece of documentation that goes public is a distribution asset. The community contributes, extends, and markets the product for you over time. It doesn’t feel like much in the first six months. A year in, it starts to matter. Two years in, it’s a real moat.
The last piece is credibility, and this one is specific to the categories that Vermilion invests in. For infra, AI memory, agent frameworks, security tooling, the buyers are technical and skeptical. Developers can read the code, audit the architecture, and understand what they’re actually deploying.
When the conditions are right, OSS-as-GTM can work in ways that almost nothing else does.
The Core Strategic Questions
So should you lead with open source, or build the commercial product first and open source later? There are patterns in when each approach works and when it doesn’t.
When OSS as your first product makes sense
The clearest case for going OSS-first is when you’re building something that only has value if the ecosystem adopts it. Infrastructure, tooling, protocols - these categories need distribution and developer trust before they need revenue. CopilotKit is a good example of this. Their bet on the AG-UI protocol only makes sense as an open play. A proprietary protocol that nobody builds on is not a protocol. It’s a dead end. If you need to establish a standard before a competitor does, open source is often the only credible path.
A recent GTMfor.dev podcast from Essence VC had a great conversation with Ryan Blue, the creator of Apache Iceberg and co-founder of Tabular, and his framing on why Netflix open sourced Iceberg in the first place. It was self-interest. They knew that if they didn’t do it in open source, they’d end up with a format specific to Netflix that would never be as good because you don’t get the benefit of other people doing the work. As Ryan put it: “The project unlocks the market. We are a product within that market.”
Being open is a trust signal that no amount of marketing can replicate, especially in a space where developers have been burned by close-sourced vendors. If you have genuine conviction that the open layer will drive usage of a proprietary cloud or enterprise tier, the economics can work with patience and discipline.
You will have users before you have customers, and converting one to the other without a sales motion in place is harder than it looks. The other risk is the Elastic problem. If you release under a permissive license and your product gains traction, a cloud provider can package and sell it without paying you anything. AWS did it to Elastic, to Redis, to MongoDB. And community work is genuinely expensive in ways founders underestimate early. Documentation, DevRel, issue triage, keeping contributors happy.
When OSS as a later product makes sense
The case for going commercial first and open sourcing later is simpler: you know more. You have paying customers who told you what they actually need. You know which parts of the product are defensible and which parts are commodity. You’ve earned the right to invest in the community because you’ve already validated that the thing you’re building has value.
It also makes sense when you want to expand into a new segment like self-hosted, mid-market, developer-led adoption without standing up a new sales motion. Open source can do that work for you, but only if the product is already proven.
The risks here are different. Late open source releases can feel cynical to a community that watches these things closely. If it looks like you’re open sourcing because growth slowed or a competitor went OSS-first, developers notice. Authenticity is not optional in this community. And if a competitor already went OSS-first in your category, you may be fighting uphill to earn trust you could have built from day one. I’ll say that if you are early in your lifecycle, say Seed stage, it’s less of a risk.
OSS-first optimizes for distribution. OSS-later optimizes for defensibility. Most founders need both eventually. The question is which one you need more urgently right now, and whether you have the capital and runway to build the other one before it becomes a problem.
What to open source and what to keep closed
The canonical model has a name: open-core. Open source the thing developers need to get started. Close the things enterprises need to sleep at night.
The framework is less about features and more about who needs what. Developers want something they can install, run, and trust like the core runtime, the SDK, the integrations, the CLI, whatever lowers the barrier to building a habit around your product. Procurement teams don’t care about any of that. They’re asking whether it’s safe to deploy at scale inside a company with real compliance obligations. SSO, RBAC, audit logging, deployment controls, non-negotiable for a CISO signing off on a purchase order. That’s where the revenue comes from. Keep it proprietary.
Without them, a security team will kill the deal before it reaches procurement. Audit logging matters for compliance-heavy industries. SLAs and dedicated support matter because enterprises are not willing to post a GitHub issue and wait. On-prem and VPC deployment options still matter more than most cloud-native founders expect, especially in regulated industries like finance, healthcare, and government.
Don’t open source your moat. If the algorithm, the model, or the data pipeline is what makes you defensible, keep it closed. The open layer is for distribution. Something else has to be for defensibility.
One useful test: ask yourself whether a developer could get real value from your open source layer without ever paying you anything. If the answer is no, it’s not really open source. It’s a feature-locked demo. Developers figure that out fast. Before you decide where to draw the line, Heavybit’s guide is the clearest breakdown I’ve found for founders who aren’t licensing lawyers.
Transitioning to enterprise is harder than you think
At some point, if the OSS motion is working, you will start hearing from companies you didn’t go looking for. The signals are usually clearer than founders expect. Inbound from companies with real procurement processes asking about security, compliance, or deployment control. GitHub org-level installs at accounts you recognize. Champions starting to ask not whether the product works, but whether it can survive an InfoSec review.
The problem is that most teams get here having been heads down on OSS (shipping, iterating, growing the community) and suddenly realize they have none of the enterprise readiness infrastructure in place. Building that muscle while also maintaining the OSS community is genuinely hard, and most teams underestimate how long it takes to do both well.
The harder signal to read is the champion-to-economic-buyer gap. Your OSS champion is almost never the person who signs the check. They are an engineer, a team lead, maybe a VP of Engineering if you’re lucky. The economic buyer is a CTO, a CISO, a CFO, sometimes all three in a room together. The champion got themselves convinced. Your job is to give them everything they need to convince everyone else. That is a completely different sales motion than anything that worked to get the open source community to adopt you.
The other hard part is figuring out how to intentionally go after the champions already hiding in your user base. You have thousands of stargazers. Some of them are engineers at Fortune 500 companies who would pay for enterprise support tomorrow if someone asked them the right question. The problem is most of them signed up with a Gmail address and you have no idea who they are or where they work.
This is a solvable problem but it requires deliberate effort. A few things that actually work: pull your stargazer list via the GitHub API and run reverse IP or email enrichment tools like Clearbit or Apollo against any work email addresses you do have from cloud signups or doc registrations. Set up retargeting against your GitHub and docs traffic. The person reading your deployment guide three times in a week is worth a LinkedIn impression.
Build a lightweight PLG motion into your cloud or hosted tier that captures company affiliation at signup. The OSS community got you here on pull. The enterprise motion requires some push using resources and moments to get those champions to show up and tell you who they are - and just need someone to help them make the internal case.
If you want to go deep on this transition, pricing, and more, the WorkOS Crossing the Enterprise Chasm episode with Armon Dadgar is a fantastic resource. HashiCorp’s path is instructive; they started with entitlement licensing, the model enterprises were already comfortable with, and only gradually migrated toward consumption-based cloud pricing as customers built comfort with cloud delivery. Meet buyers where they are. Build trust. Move them over time
Final Thoughts
If you’re asking yourself if you should open source part of their product, ask yourself the following: what happens the day after it works? What do you sell, to whom, and how do you find them when they’re all hiding behind Gmail addresses?
Open source is not a strategy by itself. It’s the first move in a longer game. The founders who do it well know exactly what the second and third moves are before they make the first one.