Strategies for open source product management

Having worked with several open source products as a product manager (PM), I sometimes get asked how being a PM focused on open source is different from traditional product management.

I started my PM career at a traditional B2B company, where we were not relying on the open source distribution model. At one point, we developed an integration with “the ELK stack” and that is how I learned about Elasticsearch, a popular open source search and analytics engine.

I was lucky enough to join Elastic on the ground floor as a PM for the logging use case, and it was a bit of an adjustment at first to figure out how to operate as a PM for an open source product. After 6 years at Elastic, I joined ClickHouse, a popular open source real-time analytics database, as a head of product.

This blog describes key concepts critical to understand when working with open source, as well as some of the things I learned as an open source PM and keep in mind to this date.

Types of open source projects

Open source projects are not all the same. They use different software licenses and governance models.

Open source licenses: There are many open source licenses with different goals, restrictions, and implications for users. The main distinctions I think about are:

• (1) How “permissive” is the license, meaning can you just use it without any restrictions? An example of a commonly used permissive license is Apache 2.0.
• (2) How “viral” is the license, meaning if you use it, does your software have to also be open sourced? An example of a license where that is the case is GPL.
• (3) Is the license standardized (OSI approved) or custom? In recent years, many commercial open source companies (COSS), such as Elastic, Confluent, Hashicorp, stopped using OSI approved licenses and started using customized licenses to restrict competition with CSPs and other hosted providers of software.

Governance models: Open source projects can be governed in multiple ways, but the main models I have seen adopted in the data space are:

• Founder-leader. This is how many open source projects get started. A creator of a project publishes it and at first supports it as a side-job. For example, Elasticsearch was built and open sourced by Shay Bannon in 2010 as an independent developer, and was supported solely by him until formation of Elastic in 2012.
• Single-vendor. As the name suggests, in this model, a single vendor chooses to distribute some of its intellectual property under an open source license. Sometimes, this project is not core to their business, and they simply look to attract collaboration around it (for example, the Facebook React project). Sometimes, the vendor exists specifically to support and build a business around the open source project (e.g. MongoDB, Elastic, ClickHouse).
• Foundation-backed. A foundation is a non-profit organization managing an open source project on behalf of many interested parties. Popular foundations include Apache Foundation, CNCF, and Linux Foundation. A project can be donated to a foundation by a commercial entity or a solo creator. Many open source projects in the data space are managed by foundations, including Apache Kafka, Apache Spark, Prometheus, etc..

Open source community members

In the context of open source, “community” refers to people that use, contribute to, and build businesses on top of the open source project.

If you are a product manager, you are likely working at a company responsible for extending the open source project and building a commercial business fueled in part by this project. Your role may differ depending on your company’s relationship to the open source project, its license, and governance model (see above).

For the rest of this blog, I will assume that your company is wholly or partially responsible for the open source project direction and roadmap. If that is the case, it is important that you know how to interact with the community of users and contributors and leverage these relationships positively toward the project success.

• Users are individuals who adopt open source in some capacity, whether for personal use or production use in their organization. They typically evaluate it against other technology alternatives, and can be a great source of product feedback.
• Contributors are individuals that get actively involved in improving the project, typically by improving the code or documentation. There are one-time contributors (e.g. fix a specific bug, add one new feature — usually in the context of their own use), and consistent contributors (e.g. maintain an existing feature on an ongoing basis, or consistently contribute bug fixes and features — not only for themselves). Sometimes they are enthusiasts that contribute on their own time, and sometimes their contributions are sponsored by their employer.
• Customers of a commercial open-source company are individuals or organizations that pay money in exchange for a service (e.g. support, professional services) or an additional commercial product (e.g. commercial extension or hosted version of open source product).
• Ecosystem of integrations refers to open-source or commercial projects that extend the core capabilities of the product and allow it to interact with other software. This is especially critical in the infrastructure space, where a project does not exist in isolation, but is usually part of a technology stack that gets adopted together. Understanding what this stack is for each key use case will help you identify the right connectors to build, maintain, and nurture within the ecosystem.
• Partners of a commercial open-source company are individuals or organizations that provide products or services that do not directly compete with the core offering of your company. Usually, their activities broaden adoption of open source and thus the potential serviceable market, and they may be interested in joint go-to-market strategies and co-marketing activities.
• Competitors of a commercial open-source company are individuals or organizations that provide products or services that overlap or directly compete with your core offering. Sometimes, if the overall market opportunity is large, such an offering may be competitive in the part of the market where you are not currently focused, and in that case, this potential competitor can become a partner or an eventual acquisition target.

Things to keep in mind as an open source PM

Here are some of the things I learned that helped me transition to open source product management from a traditional commercial PM role.

• Marketing: In the context of open source offerings, how marketing works is very different. Rather than spend a lot of money on branding and top-down sales, it is more typical to rely on users adopting the software directly and sharing their experiences with others through word of mouth. A lot of the marketing activities then become about finding these users and giving them avenues to share their stories — either through virtual and online forums, or in-person meetups and conferences.
• Sales: Similar to marketing, the sales organization typically works differently in the open-source commercial company. Since your product can be tried at scale and even adopted in production before a sales person ever gets involved, it is possible to to avoid building a massive, top-down sales force in the early stages of the company. You can avoid needing to run long, costly proof-of-concepts and be successful with sales folks who are good at reaching out to existing users of open source and gauging interest in commercial offerings (sometimes referred to as “farming” as opposed to “hunting” in sales lingo).
• Getting product feedback: It is tempting at first to only get feedback from customers — i.e. those that pay for your commercial offerings — because you know who they are, and they can help you understand why they adopted your commercial offering. But do not forget to talk to your open source users, as well as those that use competitive offerings. These users can help you understand why they are choosing to use your project as opposed to other technology alternatives, as well as discover different types of commercial offerings you may have not introduced yet.
• Innovation: Building on the previous point, because users can adopt your product for free, the open source offering often becomes a great platform for experimenting with new ideas. Users will choose it for “moonshot projects”, and even if there are rough edges with these new use cases initially, they’ll often stick with it, because the platform is free and they can contribute improvements. As a result, the amount of innovation that happens on top of open source projects, in my experience, is exceptional, and you can often see where the overall industry is headed earlier. In some circumstances, whole new products and viable commercial companies may be built on top of open source outside of your company, and these can become great partners or acquisition targets.

Commercial strategies

Every commercial open-source company has a strategy for being financially self-sustaining. Commercial goals may differ — from bootstrapping and lifestyle-business as a goal, to venture-backed and aimed at high-growth and eventual IPO.

If you are a PM for an open source project as part of a company that is commercializing some aspect of this software, it will be important to understand the financial goals of your company and how commercial vs open source offerings fit into these goals. You will have to decide if specific features, new products, or improvements should be built and released as part of open source, built and released under a commercial license, or perhaps not introduced at all.

There are many ways to build businesses on top of open source offerings, and it is possible to combine them.

• Support and services, including commercial support, professional services, and paid training and certification. While typically not considered high-growth and enough to sustain a business alone, due to low margins and high cost of hiring technical professionals, almost any business on top of open source will have some amount of these services. However, most modern successful COSS companies target to have support and services to no more than 10% of their business.
• Commercial distribution of an open source project. Popularized by RedHat in the early days of commercial Linux, it is still not uncommon to have an “enterprise version” of an open source project. This version typically has higher reliability and quality assurance guarantees, and is sometimes combined with commercial features not available in open source.
• Commercial features on top of open source core distribution released for self-managed usage. These “commercial extensions or add-ons” typically represent “advanced” features that most early adopters and individual users do not need, but are aimed at larger organizations adopting open source in a commercial setting and willing to pay for mission-critical production use of the project. As a result, these features typically include advanced security and disaster recovery capabilities. Elastic and MongoDB both serve as good examples of this model in the early days of their commercial journey.
• Hosted offerings. It is increasingly common to offer a hosted version of open source software as a cloud or hosted offering, consisting of open source as well as cloud-native tools and services. There are multiple ways to package hosted software — multi-tenant, dedicated, bring-your-own-cloud (BYOC), and even “private cloud” — and successful commercial open-source companies may eventually build out all of the above. Many modern COSS companies today (including ClickHouse, where I am currently), start with sole focus on hosted offerings as the main way to build commercial offerings.

Thanks for reading! Please follow me here on Medium, Twitter, and LinkedIn to learn more about my thoughts on product management, packaging, pricing, and latest news about the products I am building.