Get full access

Upcoming PLG Workshop

Join us at our upcoming Product-Led Growth Workshop with PLG expert Hila Qu on August 30, 2023.
private

Looking to lease sublet space?

Share details about the space you are looking for or have available and we'll match you with relevant portfolio companies.
private
Chapters

Open Source Fundamentals

The open source community can be a major source of product feedback, early customer traction, and an effective go-to-market for companies at any stage. In this resource, we explore the dynamics of open source products, various GTM models and how they can fit into your business strategy, as well as developer relations frameworks and how they can supercharge your product adoption.


Product Implications: Open Source vs. Paid Enterprise Edition

There's a saying that goes, "With enough eyeballs, all bugs are shallow."  With a large open source community, you can quickly identify problems, resolve product issues, and encourage community contributions to the code base, which creates a strong incentive toward the success of the project. 

However, it's essential to decide early on which features will remain open source and which will be part of a paid enterprise edition. Once a feature is in open source, it's challenging to restrict it later (both technically and in terms of loss of trust with the community). 

Features focused on enterprise-class needs, such as observability, security, and governance, are good candidates for a paid edition. While some might consider placing production readiness behind a paywall, it's trickier than you might think. Ideally, open source should be production-ready to attract a wide audience, including serious organizations that prefer not to pay for open source IP. Try not to leave potential demand on the table; make open source as accessible as possible.

One intriguing concept in open source is the "Eyeball of Open Source." This approach treats open source as a free trial, with the expectation that most users will eventually become paying customers. This differs from the traditional open source model where the open source version remains freeware.

Community Building: Your Secret Weapon

Community building is another crucial aspect of open source. It lowers barriers for users to get involved with your product, accelerates product adoption, and serves as a source of new talent. 

Early on, focus on community growth rather than business growth. If you address a significant need, your users may naturally push you to create commercial features, and your users' demands could make a compelling case for your product's value.

However, be wary of relying too much on vanity metrics. Instead, focus on consistent growth over time, such as new users per month. Cumulative milestones, like total lifetime sign-ups or GitHub stars, can be misleading. 


Project Stewardship 

If you're starting an open source project that didn't originate within your organization, it's important to address project stewardship. The sooner you gain control of the project, the better. This allows you to evangelize the technology beyond your organization's walls, adapt it to the wider community's needs, and ensure alignment with the project's goals.

Control over the project also prevents it from falling into "community rot." This occurs when a project lacks a dedicated organization committed to its commercial success, which can lead to community deterioration and misalignment with the project's original vision.


Licensing Matters

Licensing can also be a complex issue. Address it early to prevent complications down the road. 

Each company approaches licensing differently, but key considerations include: 

  • How to track and enforce usage.
  • What to disclose to users during onboarding.
  • What to offer in your free tier.

It's essential to maintain transparency and address concerns about data privacy. Keep in mind that changes in licensing can lead to pricing pressures and potential backlash, so tread carefully.

Diverse GTM Models

Now that we've explored the fundamentals of open source, let's shift our focus to various GTM models to consider, and how they have been successful for different companies.

1. Confluent: Open Source Adoption with High ACVs

Confluent serves as a prime example of widespread open source adoption while monetizing a smaller segment at high Annual Contract Values (ACVs). The majority of Confluent users leverage open source solutions, with the Confluent platform offering enterprise-grade features around Kafka. They charge on a per-day basis, adding support charges on a per-node basis. Despite the widespread open source usage, Confluent's revenue largely stems from these high ACVs.

Pros:
  • Exceptionally high ACVs.
  • Strong tie between usage and pricing, similar to a consumption risk model.
Cons:
  • A portion of support revenue is masked as product revenue.
  • Vulnerable to price competition, particularly from providers offering cheaper support.
  • Potential cannibalization between self-hosted and cloud-based offerings.

2. GitLab: Seat-Based Model with a Buyer-Based Open Core

GitLab follows a more traditional seat-based GTM model, balancing a robust open-source community with a diverse range of pricing tiers. It’s tiering features are based on user roles (individual contributors (free), directors (premium), executives (ultimate)). This approach allows GitLab to cater to a wide user base with varying needs.

Pros:
  • Offers a good entry point for users of different roles.
  • Diverse pricing tiers for varying user needs.
Cons:
  • Friction when upgrading between pricing tiers.
  • Frequent price hikes can lead to customer concerns.
  • A small number of customers drive disproportionate support requests. 

3. HashiCorp: Popular tool as Loss Leader, Monetizes Highly-Valued Features

HashiCorp is known for its Terraform and Vault products, where Terraform serves as the dominant open source tool. In this case, Terraform can be thought of as a "loss leader," where it may not generate significant revenue directly, but serves as a powerful way to attract users. It’s primary goal is to drive widespread adoption.

Vault, on the other hand, has a suite of features designed around security and governance, and it’s where HashiCorp focuses on monetization. While Vault may have fewer users compared to Terraform, it enjoys a higher willingness to pay, especially from enterprises that value robust security solutions.

Pros:
  • Nicely bifurcates what organizations are willing to pay for vs. not. 
Cons:
  • Requires significant open source base to make up for lower ACVs.
  • Too many different products can confuse product strategy and muddle prioritization.

Self-Hosted vs. Managed/Cloud Offerings: Why Cloud Products are Essential

Having a cloud offering is nearly essential for modern software companies. While there may have been concerns about cannibalization in the past, it's clear that cloud products are now indispensable.

The advantages are evident: cloud products improve user experience, reduce operational complexity, and streamline scalability. When you control the cloud offering, you ensure that everyone operates on the same version. Furthermore, you can provide managed services, making it more convenient for customers.

For infrastructure products, there are strong user experience arguments for having a managed service. These include handling scalability, controlling upgrades, and delivering a consistent user experience. Operating a cloud version keeps you honest about your product's quality, as the demand for reliability and uptime forces you to address issues that users encounter. It's a valuable exercise in maintaining product integrity.

When considering a cloud offering, especially in early-stage companies, it's important to keep the self-hosted and managed code bases in sync. A divergence between these 2 versions can lead to complications when trying to bring them back into alignment later on.


Sales Strategy: Founder-Led and Building a Pipeline

For open source and developer tools, sales strategy often takes on a unique form. Our recommendation is to have founders lead the sales efforts in the early stages of the company. This is particularly advantageous when there are multiple founders, as it provides extra leverage. Hiring traditional salespeople too quickly is a common mistake, and it's essential to remember that this industry has specific nuances that not all sales professionals are equipped to handle. 

Sales engineers can be invaluable for technical products, as they can speak the customer's language and offer credibility with technical users.

Even without a dedicated sales leader, your company has a sales motion. This can be driven through various channels, including mining the open source community and developer relations efforts. It's important to have a pipeline and ensure that you are actively engaging with potential customers, even before the official sales team is fully established.

Developer Relations Flywheels

Developer relations is a critical aspect of growing a developer-focused business. Begin building these relationships early, sometimes even before you have a product to sell. The investments you make in the community at an early stage will significantly pay off in the long run. 

The ideal scenario is to create a developer relations flywheel, where the community feeds upon itself, gaining momentum over time. The most vibrant communities are the ones where the vendor isn't propping them up, but the community itself is the primary source of energy. These communities are self-sustaining, with enthusiastic members who feel they are part of something larger than themselves.

Your role as a company is to provide the initial kindling or fuel to ignite this process. Over time, the community should become self-perpetuating. This organic growth becomes a self-sustaining cycle that continually attracts new users, contributors, and advocates.

While open source plays a significant role in nurturing communities, it's possible to build developer relations even without open sourcing your product. The key is to create a sense of ownership within the community, where members take an active role in the growth and development of the product.

Developer Relations Frameworks

Content: A Long-Term Investment

Content is a powerful asset for developer relations that accumulates value over time. Once you release it into the digital universe, you bear the upfront costs, and then it keeps delivering benefits for the long haul. 

However, here's the catch – most of the benefits of content marketing come in the long run. It's rare that you'll publish a few blog posts and immediately see a surge in traffic. Although it's possible, in most cases, the true benefits unfold gradually over time. This is why it's essential to invest in content early on.

Digital Ocean, a company known for its excellence in developer-focused content, has an interesting rule of thumb. They found that each piece of content they published could acquire a new customer for a month. This rule of thumb helped them gauge the return on investment for their content efforts. It's a testament to the long-lasting nature of quality content.

Content comes in various forms, such as blog posts, documentation, videos, and even podcasts. Each of these has its unique value and return on investment. For instance, videos, in particular, are gaining prominence in developer circles, providing an efficient way to leverage YouTube influencers for product promotion.

However, the challenge that often arises when it comes to content is finding the right people to create it. Engineers, who possess deep knowledge and expertise, might not always be eager to write down what they know. Founders can be valuable contributors, but they are often pressed for time. To address this challenge, it's important to involve your entire team in content creation.

Engineers can be encouraged and supported to contribute to the content. They may need some prodding, and their writing skills might not be polished, but they possess something invaluable – firsthand experience and the trust of the developer community. Establishing a process where your engineers regularly contribute to content is a wise approach.

One effective strategy is to make content generation a natural byproduct of your team's ongoing work. When engineers write documentation for new features or create code for upcoming releases, consider turning parts of this process into blog posts. Share your experiences, insights, and even the challenges you encountered during the development process. Your audience often appreciates this authentic content.

Additionally, when you release new features or host community events, create blog posts or live stream the events. These are different ways to maximize the return on your initial content investment.


The Power of SEO

SEO (Search Engine Optimization) is a powerful tool to ensure your content reaches the right audience. Targeting the right keywords can help attract people who are actively searching for what your product offers. While SEO can deliver quick results, it typically works like a compound interest investment, growing slowly but steadily over time.

While SEO is important, it's crucial not to overcomplicate it. You don't need to become an SEO expert. It's easy to get bogged down in details like keyword analysis and headline optimization. Focus on creating high-quality content, even if it's not perfectly SEO-optimized. A great piece of content that isn't perfectly optimized is often more valuable than a perfectly optimized piece that lacks substance.

SEO, like content in general, requires patience. It might not deliver immediate, dramatic results, but once it gains momentum, it tends to be more stable and reliable.


Hiring for Developer Relations

Hiring for developer relations can be challenging because it requires a unique blend of technical expertise and excellent communication skills. These roles are emerging, and finding the right people can be tougher than hiring traditional engineers.

One strategy is to identify current engineers who have the potential to transition into developer advocacy roles. Look for engineers who are naturally inclined toward public speaking and community engagement. These individuals are excellent prospects for developer relations roles. Many engineers don't want to write code forever and could be the perfect fit for this position.

Rather than trying to poach established developer advocates who are already famous on social media platforms, focus on up-and-coming individuals. Many talented individuals are on the cusp of breaking through and building their reputations. They're often more open to new opportunities and may be undervalued by other companies.

Previous
Next

Tools & Templates

No items found.

Tags:

No items found.
No items found.

Other Resources

No items found.
The resource is successfully added to favorites
The resource is removed from favorites
lighthouse