This post was originally published on The Data Source, my monthly newsletter covering the top innovation in data infrastructure, engineering and developer-first tooling. Subscribe here and never miss an issue!
Building an open-source business is hard work like building any other business, but it oftentimes represents a different entrepreneurial grit and hustle: it requires founders to be out there from day one, familiarizing with their target developer ecosystem, spreading awareness and cultivating a community of committed users around their products.
Below are three key strategies that I’ve seen some of the most successful open-source companies in the market today adopting in the early days of building software.
The commonality among open-source companies from a GTM standpoint is that founders truly understand the symbiotic value of building strong developer communities around their businesses.
This trend has crystallized among big tech companies, many of which are talent powerhouses of very capable developers who are used to building their own tooling. In fact, big tech culture empowers their developers to establish open-source communities where developers across organizations can contribute to making improvements to projects, sharing best practices and learnings. People were quick to realize that even though different businesses operate in distinct ways and specialize in different types of services, there are enough core infrastructural challenges that are repeatable across the board that could benefit from an ecosystem effort versus that of a singular organization.
We are also seeing a parallel movement in the market wherein some founders are consciously adopting open-source business models as a growth strategy to win over new users and boost their competitive edge in the market.
Data integration company Airbyte is a great example of this: Airbyte is going to market in an increasingly competitive sphere where Fivetran, now a unicorn with 4x the amount of funding than Airbyte, has established itself as the leading player. With open source at its core, Airbyte is able to unlock new GTM potential and users by rallying a group of contributors around the product and getting them to build their own data connectors. The more connectors built, the broader Airbyte’s reach — a competitive advantage over its closed-source counterpart, Fivetran.
Dbt Labs too, follows a similar growth path where it leverages open source as a way to wedge into the ETL tech stack. Dbt Labs enables analytics engineers to build their own transformation models. The more models built and shared across the data org, the deeper dbt Labs anchors into the stack, now known as the “modern data stack”.
Transform Data is yet another example of a developer tool company experimenting with an open-source strategy. The company, whose flagship product is a centralized metrics store, recently launched their open source metric framework, MetricFlow, as a way to enable users to build and maintain their key metrics in code. In a world where there is increasing competition between ELT, BI and analytics players to “own” the metric layer, Transform Data open sourcing MetricFlow seems to be their attempt at owning a slice of the market.
Regardless of whether companies started off as passion projects or ended up adopting open source as a strategic GTM model, the one thing they have in common is their founding teams have invested significant time creating and cultivating their communities.
Take Dbt Labs founders Tristan, Drew and Connor as an example — the team were known figures in the data world owing to their consulting work and that was well before the startup started raising massive funding from VCs. In the early days of spinning dbt Labs off Fishtown Analytics, the team started the dbt Labs Slack channel. Now with ~25,000 members, they hold monthly community meetups in different cities globally. Being on the ground since day one enabled the team to remain close to their target user bases which made it tremendously easy and successful for them to evangelize the concept of the “analytics engineer.” Together, the community of dbt Labs users have spurred the analytics engineering movement making the product an indispensable tool in the modern ELT toolkit.
In the case of Airbyte, it’s all about highlighting the individual contributors. You win over the contributors, you have a shot at winning a significant segment of the data integration market. Since contributors are an integral part of Airbyte’s data connector building initiative, the company created a “Top Contributor” page, “Connector Marketplace” and a “Maintainer Program” where the community is encouraged to build and maintain connectors, submit and review PRs, write tutorials and experiment together. The company is also putting together a compensation platform to appropriately reward open-source contributors and maintainers of the product as an incentive to keep growing the community of developers around Airbyte.
The practice of putting together technical docs is becoming more and more commonplace among developer-first companies, although not everyone prioritizes it equally. For companies building in open source, however, it’s apparent that the sooner you establish a culture of producing good docs and the more consistently you do so, the better. Some of the most successful open-source companies including HashiCorp, Snyk, Cockroach Labs and Confluent have invested massively in putting out docs for their product offerings to facilitate adoption within the larger community. To some, docs have become their competitive advantage.
For example, Cockroach Labs hired its first technical writer in the early days of the company, which turned out to be a game changer as Cockroach’s docs became one of their biggest selling points for the community. As it turns out, a well crafted doc can effectively help win over users!
While the role of a technical writer is quite nascent within the open-source community, more and more companies are hiring for the role as part of their core team. Folks are starting to realize the value of having a dedicated person to educate and market to a technical audience. Their tasks include crafting “how-to” tutorials, writing complex guides covering edge case scenarios, and troubleshooting scenarios, as well as capturing key ROI metrics to gauge user engagement. Examples of ROI metrics include number of page views per technical guide, average time a user spends on a particular section (the more time spent might indicate that the user is getting distracted because the docs are not clear enough). By keeping track of these key metrics, technical writers are able to develop content that’s best suited for their target audience.
As part of launching a full fledged community-led GTM strategy, I’ve seen many companies (e.g. Confluent, HashiCorp, Cockroach Labs, etc.) put together a “Community” team within their organization. From my assessment, the roles that people tend to hire for roughly falls into the following categories:
As you can probably tell, the “Community” team is not a one person-army. It includes distinct roles that may take time and resources to hire, which is why not every open-source company starts off by hiring for all of these roles. Most early stage companies start by bringing on a Developer relations / advocate person and slowly hiring for the other roles as they grow. While most of these roles are still nascent, I’m starting to see a shift in mindset especially as early stage founders become increasingly aware of the benefits of doubling down on community early.
If you’re an early stage software-developer startup building out your open source go-to-market strategy, I’d love to hear from you!
This post is part of an ongoing series on all things open source and GTM related, so be sure to watch this space for more related content.
