Menu
Learn how to develop customers in open-source software projects, with insights from leaders of Sysdig, Heptio, Styra, and more.
Customer discovery differs in some important ways when it’s done in the open. For one, project feedback is mostly public, meaning more users can weigh in on issues, feature requests, and other topics. Founders can leverage this to rapidly engage with end users, fueling faster project iteration. They can pose open-ended questions at once to an audience of early adopters that is much broader than standard customer interactions allow. Additionally, self-service adoption (or the lack thereof) provides important validation regarding early product hypotheses. Start by developing a robust core user persona to bring focus to your early product development efforts.
Open-source founders typically tackle customer discovery by starting with the tactics described in the Unusual Field Guide, but instead of working with a limited number of design partners, their process looks like something like this:
For example, many new OSS projects targeted toward developers are posted on HackerNews, Reddit threads, and engineering blogs.
Once the initial OSS project (the minimum viable OSS) is launched, founders engage with the earliest users to quickly iterate the project based on their feedback, with the goals of enabling these users to progress toward deploying the project in production and driving adoption among new users.
A key part of the validation that founders must perform in the customer discovery process is identifying the specific user who is desperate for the solution that your OSS project will provide. Just like commercial products, successful OSS needs to be created for a specific target user and address the problem they want to solve. It’s essential to have empathy for your user and why OSS is a benefit to them. For example, Harness, a modern CI/CD company, provides several OSS projects to its customers because the majority of them consider OSS to be a prerequisite for buying its commercial product.
There is a common misconception that OSS only makes sense for developers when, in fact, there are many different types of users who could potentially benefit from OSS. Here are several examples of target users other than developers whom successful open-source projects and companies serve:
James Hawkins, Co-founder-CEO of PostHog, shared that one of the benefits of open source is the ease of accessibility. “We've seen a lot of product engineers who work for big companies trial the open-source project. They wouldn’t be able to get started by sharing their data with us or our competitors, but what they can do is use our open-source project to self-host and test it much more quickly.”
Early adopters may not necessarily be users at companies either. Oftentimes, they may be enthusiasts and hobbyists, so understanding their profile and their use cases for adopting your OSS project is critical. Following early users through their adoption journey will help you refine your solution. Your early users will also help you learn the best ways to engage with them.
Once you’ve identified the specific user your OSS project will serve, it becomes important to determine its initial scope — what’s the minimum viable project? Founders sometimes debate whether to initially make their entire product open source or just a small sampling as a lead-generation tool with limited features. So how do you know that what you release in open source is substantive enough? Ultimately, it’s important that an open-source project provides standalone value to end users in order to generate meaningful adoption. Here are the two ways to accomplish that:
For example, Sysdig is a cloud-native security company that started with an OSS project of the same name that provided a CLI system exploration tool for container monitoring. Its first project was focused on solving a specific problem in observability. Eventually it released OSS projects in adjacent areas as it expanded from monitoring to security use cases.
One way to scope down what you initially launch in open source is releasing product functionality that serves what individual users need. In fact, features that enable teams and organizations to get more value out of your product are often good candidates for your commercial version.
Before launching an open-source project, you’ll need to decide what license to use. Licenses vary in terms of how permissive (in terms of re-use and distribution) they are and the protections they offer, meaning your choice of license can have a significant impact on your company. In choosing a license, founders face tradeoffs between enabling easy adoption and maintaining defensibility of their commercial business, so it is important to make an informed decision.
Competitive concerns play a role in this choice. As more open-source business models rely on managed/cloud offerings as the primary form of monetization, founders have become increasingly concerned about the ability of large cloud providers or other companies to co-opt open-source projects and offer their own competitive cloud offerings, a trend that some founders describe as “strip-mining.” New licenses have emerged that can provide competitive protection, but aren’t considered pure “open-source” licenses. This can sometimes hinder adoption with the end user organizations you’re ultimately targeting, especially if the license is not widely approved for use. For most companies, using a permissive and widely accepted open-source license is the best choice to start because driving user adoption is the top priority for any open-source company early on.
Here is an overview of the most common categories of open-source licenses:
Permissive licenses
A permissive license puts very limited restrictions on reuse and distribution, enabling greater adoption by end users. The most common permissive license we see used by founders is the Apache 2.0 License. Other permissive open-source licenses include the MIT License and BSD Licenses.
Organizations usually have internal policies regarding which licenses are approved for end-user adoption of open-source software. These permissive licenses are nearly always allowed, removing potential friction that would hinder users from adopting your OSS.
Copyleft licenses
Another class of licenses is known as “copyleft,” which place requirements on users to redistribute their work that utilizes your open-source project also as open source. Since many organizations do not want to open source their software, these licenses are typically, by default, not allowed, which can severely restrict end-user adoption. Licenses in this category include the GPL, LGPL, and AGPL Licenses.
Custom license
You can always craft your own custom license if you believe an existing one doesn’t fully meet the aims of what you want to achieve. For example, GitLab has used two separate licenses: Community Edition (CE) and Enterprise Edition (EE). The drawback of this approach is that organizations may place greater scrutiny on your license since it is not standard, either slowing down adoption or requiring you to engage in a process to gain internal approval.
Other licenses to consider
In recent years, new licenses have emerged to protect against “strip-mining” by competitors, especially driven by large cloud providers offering competitive cloud services to prominent open-source companies. Two examples of these licenses are the Business Source License (BSL) and Elastic 2.0 License. These cannot be considered pure open-source licenses since they restrict usage in important ways but can help address the competing opportunities and risks of making a project widely available.
While it’s often tempting to use one of these licenses for competitive protection, because these licenses are less widely approved within organizations, we often recommend that founders choose a permissive license and focus on growing their user base. You generally won’t need to be concerned about larger competitors until your project has significant adoption for others to take notice.
Contributor license
In addition to the license you apply for your open-source project, it’s also important to prepare a Contributor license that makes it easy for your users to contribute and further the project.
Finally, it’s worth mentioning that some companies mitigate the risk of their underlying open-source project being co-opted by competitors by releasing features in open source only after some period of time that they are available in a proprietary offering. This strategy is different from using licensing as a means of protection.
As you continue engaging with your early user base to build your OSS project, it’s worthwhile to start thinking ahead about how the OSS project will evolve over time, especially once you also launch a commercial offering. Most successful OSS founders have shared that they started thinking about what their commercial version would look like while they were still focused on growing their OSS project.
This is important because you’ll want to establish some guiding principles on what product functionality should always be made available in OSS and what will only be available in your commercial offering. It is necessary because you will have to set the right expectations with your OSS user base as to what types of features they can expect to be freely available.
Building and maintaining trust with OSS users is paramount. Once a feature is made available in your project, users assume it will be available as OSS in all future versions. Removing functionality from OSS and charging for it in later versions can cause irreparable damage to your relationship with your users. Implementing a guiding framework to determine what product functionality should be made available as OSS and what should be kept commercial can help you avoid this scenario.
Once you launch your commercial offering and start to ramp up traditional GTM functions, namely sales and marketing, your product strategy and roadmap will need to balance prioritizing features that are added to the OSS project versus those that are paid. Sales will push for more commercial features while your user community (and perhaps some of the engineers on your team who are enthusiastic about OSS) will push in the opposite direction with more OSS feature requests; this tension will always continue to exist. Focusing too much on commercial features to grow revenue can stall community growth, which is the engine that underlies a successful GTM for an open-source company. At the same time, overemphasizing OSS features risks not being able to serve the customers needed to reach repeatable sales and sustainable revenue.
We have observed some different approaches that have been successful in helping OSS companies to determine whether product functionality should live in OSS or commercial versions. We have listed the most common here. Note that there’s no single answer and some companies use a combination of these.
Single player vs. multiplayer mode
In this approach, any features that are aimed at individual users are made available in open source and any features that are primarily needed for usage by a team or organization are only available in the commercial version.
Basic use cases vs. advanced use cases
This approach favors open source for features that support basic use cases, to eliminate any friction for users to get started and realize the foundational value of your project. Product features that enable advanced use cases are put into the commercial offering, requiring the users who need them to pay for them.
Small company vs. enterprise
This approach prioritizes open source for anything that would be needed by a small- or medium-sized organization and the commercial offering for anything needed by a larger enterprise. Some of these enterprise features include security, audit and compliance capabilities, identity management, and integrations with particular tools.
On-premise vs. cloud
This approach is better suited to companies whose commercial offering is solely a cloud/SaaS service because OSS can be used as a way to cater to customers who want to run your software on-premise (“self-hosted”). In this option, any features designed for on-premise deployments are made available as OSS. This can allow a company to avoid having to provide ongoing enterprise support for on-premise environments while monetizing exclusively through a managed cloud service, with the goal of migrating some of those on-premise deployments to the cloud service over time.
In addition to these approaches, it’s critical to assess which features are broadly applicable to the majority of users and customers versus only a handful. These are a few of the most common approaches, but you might find another works best for your business. Regardless of your approach, it is helpful to establish guiding principles for what features should be available in open source and what should be limited to paying customers. A clear strategy will guide your team’s product decisions, and provide clarity and consistency for your users and customers.
This is part two of The Open Source Software Field Guide for Founders. Read part three: Building GTM now.
Sign up for the Unusual Ventures newsletter to stay up to date on forthcoming sections.
