Building Commercial Open Source Software: Part 1 — Community & Market Fit
Since the early 90s, with the emergence of the MIT free software movement and popularity of Linux, there has been an accelerating shift away from proprietary, closed software to open source.
Today the open source ecosystem has over 40M registered users, 2.9M organizations, and 44M projects on Github alone. Just in 2019, 10M new developers joined the GitHub community, contributing to 44M+ repos across the world.
Open source continues to be the heartbeat of the software community and one of the largest and growing segments of the market by IPO, M&A, and market cap; with new projects emerging well beyond low-level systems to machine learning, data infrastructure, messaging, orchestration, and more.
Companies such as Hashicorp, Astronomer*, Puppet, Confluent, and Databricks are a new approach to commercial open source, with a focus on deploying their open cores to the broad developer community and the largest companies in the world with enterprise-ready needs attached to them. All while actively contributing to the community and gradually opening up more of the closed platform to the community — and building big, meaningful businesses along the way.
These new approaches are building platforms that wrap open core packages with support, enterprise-focused capabilities, and enterprise-level stability to transform a solution into a high availability, horizontally scalable, modular service that can fit into any set of cloud or infrastructure needs. Riding a tidal wave of community growth and demand as the underlying projects proliferate across developers and enterprises.
While there is no one-size-fits-all approach, each of these companies have navigated a complex maze of decisions as they built and scaled their solutions: deciding when building a commercial solution made sense, ensuring the community still stayed in primary focus, remaining open yet balancing the needs of the enterprise, deciding when to focus on bottoms-up or introduce enterprise-wide selling, and how to remain competitive against the cloud providers.
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.
So 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. Find Community-Project Fit
Ultimately the success of a commercial open source company first relies on an active community of contributors and developers supporting the project and distributing it to more and more developers. This means building a project that the community has decided is worthy of their participation and support is the most important goal starting out. The keys to building a vibrant community around your project center around earning developer love by solving an important and widely felt problem, inspiring and supporting others to actively contribute, and giving reason for a passionate community to begin to form around it; whether it’s around integrations, an ecosystem built on top of it, or new ways to extend the project. The key questions we ask ourselves when evaluating a new project are: Is the project seeing increases in contributors, commits, pull requests, and stars? Has the community rallied beyond this project amongst the many variants or flavors attempting to solve a similar problem? Is this project introducing a compelling new approach to solving a thorny and wide- felt problem? Have the project creators put forward an assertive and opinionated view on the direction of the project? Have they also been inclusive in ensuring the community has a voice and say? How would developers feel if the project was no longer available?
2. Build Around Project-Market Fit
Next is understanding how your project is being used inside of companies: how are developers using your project? What are the killer use cases? Where are they struggling to use the project? From there, you can decide whether building an enterprise offering around the project makes sense. For instance, is it a run-time service that companies struggle to host where a managed solution would see strong adoption? Are developers building homegrown solutions to make it work or stitch it together internally? Might customers need enterprise-level security, support, or performance in order to deploy into a production environment? Could the value of an enterprise solution wrapped around the open core eventually multiply if coupled with capabilities such as logging, analytics, monitoring, high availability, horizontal scaling, connectors, security, etc. Understanding how the project is being used and where there might be value-add for enterprise customers is key before embarking on building an enterprise service.
3. Start With a Loose Open Core
The goal in going open source to enterprise is to see widespread distribution and adoption of a project by a large community of developers which can eventually turn into a healthy cocoon of demand for an enterprise offering. To do so, it’s best to avoid dogmatic decisions in the early stages of going pure open or what/how will be closed. Rather, focus on keeping a loose open core; keeping the core open for the life of the project and building an enterprise offering as source-available and closed source capabilities that magnify the value of the core when being deployed into complex environments or use cases. Over time you can decide to graduate source available and closed source capabilities into the open core — more about that in an upcoming post. Keeping a loose open core allows the flexibility to continue to build and grow the community while offering specific SaaS or deployment models that meet the needs of the commercial market, and hopefully keep both constituencies satisfied.
4. Pick the Right License
Your project license structure is key to get right from the start; a permissive software license (MIT, BSD, Apache) allows for mass adoption by unburdening users from needing to contribute back. Protective licenses (GNU GPL) force forks/derivatives to release their contributions back as open source. Then there are variants such as the LGPL, AGPL, and Apache 2.0 with Commons Clause that are mostly permissive but have specific limits if you’re concerned about cloud providers or others freeloading on your project into a managed service. Thinking through the competitive risks, such as what groups forking your project might be able to do, or if the cloud providers could fork a managed service of your project, are critical to designing the right license structure. See, in example, the Redis Labs post on changing from AGPL to Apache 2.0 with Commons Clause and why.
5. Define Clear Principles for Open vs Closed
Constructing the right open core vs source available vs closed source strategy could be a company-making or killing decision. Source available and closed core need to be thought of as value-adds that wrap around open core, with many cases, in a path to eventually graduating into open core. Be explicit about the principles you use to decide what to open vs close, and how/when/if they graduate. A guiding principle for what to make part of open core vs closed might be (a) the closed enterprise/commercial edition only focuses on the needs of enterprise segment, or (b) the needs of companies that are post-revenue, or © based on use cases that exceed certain scale/performance requirements. Be explicit about it, write it down, share it with your community. The selected guiding principle then dictates when to release to the open core vs keeping closed The community often will understand that a strong commercial business is required for continued investment into the project, as long as you are explicit about the intentions and roadmap to continue supporting the community. These transparent principles will often avoid many of the conflicts between the community and commercial needs, i.e. the community pushing for a feature that competes with the enterprise offering.
6. Maintain Project Leadership
Even as the project creators, maintaining project leadership is key and is not guaranteed. This means striking the right balance between supporting and leading the community, and being explicit with the direction of the project, yet engaging deeply with the community. Taking an active role in the PMC if part of the Apache community, lead the AIPs, know the top 50 contributors intimately, and drive the direction of the project. Be responsible for the majority of the new commits and releases for the project. Ensure there is always a reason for new contributors to join and for the community to continue growing.
*Venrock is an investor in Astronomer, the enterprise developers of Apache Airflow.