Building a Commercial Open Source Company
In our time investing and supporting open source companies, we’ve learned several lessons about project & community growth, balancing roadmap and priorities, go-to-market strategy, considering various deployment models, and more.
In the spirit of open source, we wanted to share these learnings, organized into a series of posts that we’ll be publishing every week — enjoy!
- Part 1: Building blocks to a commercial open source offering
- Part 2: Focus your commercial and OSS roadmaps on developer adoption
- Part 3: Sequence your distribution & GTM strategy in layers
- Part 4: Your deployment model is your business model
1. Solve for the homegrown gap
When developers struggle with deploying an open-source project into their complex internal environments or infrastructures, they build homegrown solutions instead. Solving for key areas turns developer engagement into commercial customers. This means it needs to be as easy and seamless as possible to set up and deploy in order to start demonstrating value. Whether it’s providing Kubernetes operators, specific integrations, CLIs, or UIs, make it dead easy to deploy.
2. Offer an enterprise-ready package
Open source is designed for the community, by the community, and by definition wasn’t designed to work out of the box in the enterprise. Comprehensive testing, a certification program, performance guarantees, consistency & reliability, cloud-native, and key integrations are all substantial value propositions on top of an open core.
3. Layer value on top of the open core
Focus on ways to magnify the value of the open core within the customer’s organization; make it easier to deploy, operate, manage, and scale. Adding capabilities such as rich UIs, analytics, security & policies, management planes, logging/observability, integrations, and more make it easier to work within increasingly complex customer environments. For example, Elastic built a number of products on top of their core that made it easier to deploy and manage such as Shield (security), Marvel (monitoring), Watcher (alerting), native graph, and ML packages.
4. Narrow focus until you become ‘the’ company:
Focus narrowly on making it easy and obvious for every company in the world to be on your open core, and use it to grow both the community and customer love to become the [open source project] company. Avoid splitting focus until you’ve generated enough market adoption (i.e. $25M in ARR) to declare yourself the winner. Databricks is the Spark company, Astronomer is the Airflow company, Confluent is the Kafka company, by focusing on developing, growing, and scaling the open core.
5. Go horizontal over vertical
Focus on modular, horizontal capabilities that apply to all engineering organizations, of all sizes, that make the open core and enterprise solution more robust, manageable, performant, and scalable. Horizontal would include such capabilities mentioned earlier such as analytics, logging/observability, management tools, and automation, but also enabling new capabilities that amplify the value of the core. This might include improved capabilities for data ingress/egress, replacing existing infrastructure components for tighter integration, or moving up/down the stack. Vertical capabilities are focused on specific customer segments or markets, such as offering a ‘financial services package’ or specific offerings designed for large enterprises. The illustration of this has been most recently evident in diverging strategies of Puppet vs Chef and led to Chef’s low revenue multiple acquisition.
6. Optimize for developer usage over revenue
In the early commercial days, usage counts more than revenue. You are looking at downloads, stars/fork ratio, contributor velocity on the open source project, and beginning to see reference customers adopting your project on the commercial side. Developer engagement is key to building customer love, deep adoption, and lock-in. These lead to eventual expansions, referrals, customer champions, and all the goodness.
7. Without telemetry, you’re flying blind
Without understanding how the project is being used, the number of deployments/developers/organizations, service utilization, and adoption curves, it’s difficult to prioritize fixes or features. To better observe, manage, and debug before they become major issues, implementing lightweight telemetry can offer continuous, unfiltered insight into the developer’s experience. Two key projects, OpenCensus and OpenTracing have merged to form OpenTelemetry, enabling metrics, and distributed traces that can easily be integrated into your project.
Building Commercial Open Source Software: Part 2— Roadmap & Developer Adoption was originally published on Medium