The playbook for OSS-core infrastructure companies — build a great open-source project, grow a community, convert enterprise users to contracts — is still the right strategy. But the specifics have changed meaningfully from the 2015–2020 era when Kafka, Spark, and Airflow were running it. If you're applying the same execution template without accounting for these changes, you'll be surprised by what's different.
Community scale threshold has shifted up
In 2015, 1,000 GitHub stars was a credibility signal. Enterprise buyers with an OSS track record knew what that meant and were willing to begin conversations at that scale. In 2024, the community is better at inflating star counts, and the enterprise buyers are more sophisticated about it. The credible threshold for enterprise conversations has moved to somewhere around 10,000 stars combined with demonstrated production deployments — not star counts, but the kind of community evidence that shows real teams depending on the software in real systems.
The faster path to credibility is reference customers. An enterprise infrastructure buyer who can talk to a principal engineer at a company they respect, who's running the tool in production at scale, is worth more than 20,000 GitHub stars. Finding these early production users and nurturing them into reference customers is now the most important community investment for an early-stage infrastructure company.
The cloud managed service runway has shortened
The monetization path for OSS infrastructure used to be: grow community for three to four years, build enterprise features, then launch a cloud managed service. The timeline has compressed. Cloud-native teams now expect a managed cloud option from almost the beginning — they don't want to self-host infrastructure that they didn't build. This means earlier-stage companies need to think about their cloud offering earlier than the canonical playbook suggested.
The tension is real: building a good managed cloud service is operationally expensive and distracts from open-source development. The companies managing this best in our portfolio are those that have made explicit architectural decisions that make the cloud service incrementally easier to build — a clean separation between the OSS compute layer and the control plane, for example, or a design that makes multi-tenancy straightforward rather than retrofitted.
What hasn't changed
The fundamental truth of developer tool distribution hasn't changed: software that engineers want to use, write about, and recommend to colleagues grows without a sales team. The companies in our portfolio with the best community growth don't have the best marketing. They have the best APIs, the best documentation, and the fastest time from installation to "this is clearly useful." No amount of developer relations spending compensates for an API that's confusing or documentation that's incomplete.
Enterprise buyers still follow the bottoms-up motion. The enterprise contracts that are easy to close are the ones where someone in the company has already been running the tool in production for six months and is now presenting the case to a VP of Engineering or CTO. The sales team's job is to convert these qualified internal champions, not to cold-source enterprise demand. This is still true, and the developer-first companies in our portfolio that forget it and try to build top-down enterprise sales motions before they have community pull pay a significant price in sales efficiency.