Menu
Learn about the best ways to build an OSS community and the main commercial business models to consider, with insights from Shay Banon of Elastic, Jonathan Ellis of DataStax, and more.
GTM for an open-source company starts with prioritizing adoption and usage of your OSS project. The most successful OSS companies typically delay monetization in favor of driving ubiquity among a large, enthusiastic user base. This community of engaged users needs to be established prior to building typical traditional GTM functions around enterprise sales and marketing.
The two early goals of GTM for any open-source company are to establish broad adoption and market credibility. Broad adoption requires building a large, engaged user base and is necessary because open-source monetization assumes most users will use the OSS for free and only some percentage of users convert to paying customers. Your user base must be large enough to support this model. Early market credibility is achieved when forward-thinking (and often technically sophisticated) organizations adopt and evangelize your OSS project first, giving the majority of other organizations the confidence to also eventually adopt your commercial offering. It takes substantial upfront investment to gain broad adoption and market credibility, which is why we often see many OSS companies originate from OSS projects developed at large technology companies. These OSS projects already have an existing user base and credibility from having been utilized by a technically respected organization.
The OSS adoption curve reflects these two goals. It’s necessary to attract a sizable group of users, but because this group must help further market credibility, the profiles of these users and the organizations they belong to matters greatly in the earliest stages of adoption.
The general pattern of effective OSS adoption mimics some of the principles described in Geoffrey Moore’s Crossing the Chasm. To simplify, we classify adopters into two groups: (1) users at “lighthouse” companies and (2) users at mainstream companies. Lighthouse companies are technically sophisticated and have a recognized track record of solving engineering challenges that they encounter earlier than the majority of the market. For example, companies like Netflix, Stripe, Block, Uber, Airbnb, Spotify, and others have significant followings in engineering communities and are often influential proponents of new tools and solutions.
Adoption by users at lighthouse companies boosts credibility of your OSS project before users at mainstream companies — which make up the majority of the market — are ready to adopt. Lighthouse companies may only use OSS and never pay for a commercial offering. They often have a preference for operationalizing and managing OSS themselves due to their level of technical talent. But users from lighthouse companies serve as important evangelists that amplify your mindshare and awareness in the market. They tend to highlight important, new technologies and serve as champions of new tools. The value of this user group to your company is that their credibility and influence significantly increases the likelihood that once users at mainstream companies need a solution, they will seek out your company. These mainstream companies typically prefer not to deal with OSS, making them the eventual focus of your commercial offering.
Initial marketing activities to engage a burgeoning OSS user base differ greatly from those of traditional enterprise software companies because classic marketing tactics are ineffective. OSS users such as developers do not want to be marketed to; in fact, one of the key reasons why they prefer OSS is because they can get started in a self-service way without ever having to interact with marketing pitches or salespeople. So when seeking to engage these users, you must instead focus on tactics that offer value to them without an expectation that they will adopt or buy anything. There are several ways to do this, primarily through educational content in different formats.
Educational content is a highly valuable means to get your target users interested in your OSS project. This content should focus on helping users clearly understand specific details of a problem or topic, with the goal that they learn something new. For example, for a developer tools company, it could provide practical tips on how users can set up an integration with their development environments. For example, for a security company it could be sharing about a new type of vulnerability that has been discovered and what users should do about it. Again, the goal of this type of content is to first engage a user with the hope that he or she will then take interest in your project without any upfront expectation that they will. At the same time, the content needs to implicitly convey that your team has a high level of technical knowledge in your immediate area. This means that in the early phases of your project, educational content almost always has to be produced by the founders or core technical team.
Educational content is most effective when provided in a “bite-sized” format to enable your audience to quickly and frequently consume it. It is most common for educational content to initially be published in blog posts, but don’t overlook other formats. Sharing content via technical talks, videos, webinars, podcasts, and other mediums can expand your reach and provide more options for your audience to discover it.
Read our Field Guide on Driving Adoption with Tutorials for tactics on creating effective educational content.
Getting involved with relevant open-source foundations can also increase your visibility with your users. For example, the Linux Foundation, Apache Software Foundation, Cloud Native Computing Foundation, and other organizations help provide credibility as your OSS project is early and still maturing. Joining as a member company (which typically requires a fee) can open up different types of marketing programs to reach your community — for example, speaking opportunities (webinars, conference talks), spotlighted content (community newsletters and blogs), access to invitation-only community events, and more. Eventually, enterprise companies may expect you to have membership in one of these organizations as a prerequisite for becoming a customer.
A critical priority for an OSS company is to build and grow a community, which facilitates learning from your early adopters and contributors and helps you steer your OSS project in the right direction. By paying close attention to your early adopters, you’ll learn how and why they take an interest in your project, what their use case is, what problems they’re solving, and what inspires them to continue staying engaged. Think of early users as analogous to “design partners” who will help you iterate and build your product in the open. In closed-source software, enterprise software companies often work with design partners — trusted product “testers” who provide critical feedback and fill in missing gaps during the early stage of product development.
Open-source communities embrace collaboration and thrive when fellow members help each other. In other words, project creators mustn’t take leadership status for granted. It’s important to continually earn a leadership role in the eyes of the community. Strong leaders focus on building a tight-knight, engaged community that works together to evolve the project.
Here are three of the most important ways to build your community:
First, decide on where your community will congregate virtually — Slack, Discord, or some other forum. Make it as easy as possible for new contributors to join your community and introduce themselves so that you can build an understanding of their roles. Be clear about your project’s direction and roadmap. Make documentation easy to discover with a dedicated section for your Contribution file. Set goals, establish a code of conduct, and make directions and tips easy to find and follow.
While observing your community’s activity is important for learning, you shouldn’t stand on the sidelines. To advance the project, founders need to establish themselves as the faces and voices behind it. If the project falls within an established community and ecosystem (for example, the Cloud Native Computing Foundation), then look for opportunities to get involved in relevant working groups and committees that are influencing technical standards and other best practices. The more you bring others along on the journey of the project, the more enthusiastic and motivated they’ll be to meaningfully contribute as you grow. Make sure users have an easy way of communicating with you. Be responsive in answering people’s questions and proactive in addressing their issues.
Jonathan Ellis, Co-Founder and CTO of DataStax, says the most important focus during the company’s first three years was understanding how people used Cassandra. “I could have told you what every single user of Cassandra was doing with it, how successful they were, and what pain points they were experiencing,” he says.
As a leader in the community, you’ll identify the most active contributors. Consider giving kudos to contributors by recognizing achievements and helping them feel appreciated. Strike up conversations and ask for direct feedback from your top contributors. Consider spotlighting them in a community newsletter. Open-source communities are typically distributed, so finding ways to engage virtually is critical. Let your most trustworthy contributors be maintainers of your open-source project. Give them commit access and offer them the chance to maintain the projects to a professional standard.
For example, Maxim Fateev, Co-founder and CEO of Temporal, says the team “first focused on serving back-end infrastructure engineers at high-profile, cloud-native companies. After that, a user posted on HackerNews and we engaged in answering questions about our project. We gained visibility as we started to build a community around our new category. It took time but we knew we had to invest the resources to build an engaged community.”
Most OSS users want to understand how decisions about the project will be made. Communicate clear expectations early. In some cases, open-source companies choose to contribute projects to a foundation (or start based on an existing project governed by a foundation). Several foundations have programs for new, incoming OSS projects — for example, The Apache Incubator and the CNCF Sandbox. One of the reasons for having a project belong to a foundation is that your community may favor having your OSS project be governed by a broader set of people than just you and your team. In this scenario, typically a committee (with norms for determining who is on it) oversees decisions for the project, initially made up of the people who have been the project’s leaders. In these circumstances, it is extremely important for you to maintain strong leadership and credibility with your user base (as well as the governing committee) to help drive the forward direction of the OSS project.
Establishing a viable commercial business model is the key step in addressing the challenge that crops up early in founders’ minds: how to build a revenue-generating business from something that is open source. Many founders are understandably anxious to launch a commercial product and often do so before demonstrating solid OSS project traction. We believe that for OSS companies, user adoption is critical to prioritize before focusing on revenue. However, that does not mean that you should only start thinking about your monetization model after achieving project traction. The most successful founders think about their commercial offering early in their open-source journey, even if they did not start building it until later.
The commercial models for OSS fall into three common categories, which reflect a shift over time in how companies have been able to monetize.
The support and services model leverages building credibility and brand recognition so that users will view you as an authoritative expert on how the OSS works and seek you out for help (assuming you have established the necessary credibility that we described earlier). This approach generates revenue from providing support and services for your OSS and is the oldest established OSS monetization model. Red Hat is the best example of a company that was able to successfully build a large business using this approach. Two other examples of companies that employed this model are Canonical (which provides support for Ubuntu) and HortonWorks (which provided support for Apache Hadoop).
Organizations often value support and professional services when implementing and operating new software, and this can provide an early source of revenue. However, revenue from services should not be confused with product revenue. In this model, customers are effectively paying for expertise that they don’t necessarily have.
The open core approach generates revenue through a commercial offering that includes proprietary features or add-ons on top of the existing OSS project. This commercial functionality often includes features such as reporting, advanced user management, security (for example, audit logs and single sign-on authentication), and integrations. Frequently, this type of offering is labeled as a company’s “Enterprise” version, reflecting that these features are often needed by larger organizations, to distinguish it from the OSS version (which itself is sometimes referred to as the “Community” edition).
Customers primarily pay for the value they derive from the additional product functionality that is not open source. Well-known companies that successfully monetized using an open-core model include Confluent, HashiCorp, DataStax, Elastic, Redis Labs, and Neo4j.
The managed cloud service approach generates revenue through a commercial offering that is fully managed, i.e., SaaS that runs the open-source software. This type of offering is nowadays also referred to as “serverless.” The managed cloud service may or may not also include proprietary features that are not available in the OSS project. Customers primarily pay for the value of having someone else run and manage the OSS for them, reducing their operational burden along with associated time and costs. We see the majority of new OSS companies now favoring this model for their commercial strategy.
It’s worth noting that these monetization options are not mutually exclusive — many open-source companies leverage a combination of them; in fact, most companies that became successful with the open-core model have now shifted toward employing the managed service model. A managed cloud service that also includes proprietary features can more easily differentiate against offerings from cloud providers who effectively just offer a fully managed version of the OSS. For example, Confluent now offers both a self-managed, enterprise-grade distribution of Apache Kafka as well as Confluent Cloud. HashiCorp offers both Terraform Enterprise and Terraform Cloud. However, most OSS companies choose to have a primary offering at a given time that is central to their forward-looking product roadmap and GTM motion.
This is part three of The Open Source Software Field Guide for Founders. Read part four: Fundraising for open source here.
Sign up for the Unusual Ventures newsletter to stay up to date on forthcoming sections.
