Playbook
GTM Playbooks
How GitGuardian Leverages Data and GitHub to Fuel Its Growth
Read more
This post by François Dufour is part of our series on Product-Led Growth Playbooks. There, we share insights and advice from leaders who have built successful PLG businesses that target software development teams.
A classic dilemma emerges for successful open-source project founders: how do I monetize that? Should I go and sell an enterprise license to support the companies who use my open-source on-prem or do I develop a cloud-based offering that makes adopting and scaling much easier for customers, since I will manage it for them?
Pierre Burgy, CEO and co-founder of Strapi, was faced with this same dilemma once Strapi’s open-source started gaining real traction. His choice was to start with an on-prem enterprise offering, but he doesn’t believe this is the solution for every open-source product.
When I first met Pierre in 2018 outside the Apollo GraphQL office in San Francisco, I was immediately impressed by his understanding of what it takes to build a great product and go-to-market strategy on top of a successful open-source project and community.
Four years later, it’s no surprise that Strapi, a headless content management system (CMS), has 43k stars on GitHub, has raised $14M from Index Ventures, Accel, and Stride.VC, and has been downloaded more than 5M times. Notably, Strapi has made significant strides in a space created and dominated by Contentful (disclosure: Contentful is a former client of mine).
Pierre and his colleague Victor Coisne, Strapi’s VP of Marketing, agreed to share their insights on how to structure a commercial product offering.
This article covers:
Read on to understand how to leverage open-source when you need to take on a successful incumbent.
Pierre and his team first focused on building a great product, making it open-source, and relying on the community to help improve it.
Strapi started a community in the early days, not just to spread the word about the product, but also as a means for getting quick and actionable product feedback. This is one of the benefits of having an open-source product over a more traditional SaaS product.
There are many paths for Strapi contributors to take. Victor refers to these different paths as “swim lanes.”
“Being a contributor is so much more than making a pull request or contributing code– it can be creating videos or articles for others or providing feedback. Our job is to make sure that people can contribute in a way that interests them– if they like public speaking, there’s a lane for them. If they like blogging, there’s another lane. Our job is to lay out the options and make them available.
”
— VICTOR COISNE
Here are a few of the “swim lanes” that Strapi contributors can join:
In order to measure the success of their open-source, Strapi tracks a number of KPIs, including the number of GitHub stars, contributors, forks, PRs, npm downloads, etc.
However, beyond these reach metrics, their north star is the number of monthly or weekly active projects, meaning one user logged into the Strapi admin panel to manage content. This anonymous and otherwise non-sensitive data is collected via telemetry to give the team a better understanding of how users interact with the product. That’s what shows that a user is well on their way to getting value by actually using the product.
Not all developers want their product activity tracked and some large companies have stringent rules as part of their software security compliance policy, so the data collection feature is publicly documented and can be easily disabled. On average, the team expects that 5 - 15% of users opt out.
For their first commercial offering, Strapi decided to choose an on-prem/open core option rather than build out a Cloud offering. Here’s why:
Strapi’s biggest competitor, Contentful, is Cloud-based and is not open-sourced. Going on-prem/open core first was a deliberate differentiator to go faster and better serve their ICP.
Strapi noticed that many interested users of their open-source were from enterprises in regulated industries. These are customers who often need to host their own CMS on their own servers for compliance and privacy reasons. Although these companies might be interested in private cloud offerings, an on-prem/open core solution was a better fit for their needs.
On-prem/open core model was easier to develop and support as it did not require the recruitment of DevOps, SRE, and Support teams ensuring high availability and being on call 24/7. They wanted to provide the highest quality product and support possible and knew this would be more viable with on-prem/open core in the short term.
Building a Cloud offering would’ve taken a substantial amount of time. By starting with on-prem/open core, Strapi was able to release key features for the community quickly instead of taking the longer path to building the Cloud product first.
Although Strapi’s first product is on-prem/open core, creating a Cloud offering was always the goal. Strapi has already announced that they’ll launch their Cloud offering soon. Starting with on-prem/open core helped the team quickly deploy a product, then learn about how it gets used and where users get the most value. With hundreds of companies on the waiting list, Strapi expects a massive increase in adoption and revenue.
Not only does the Cloud offer advantages to developers, but it will also increase the total addressable market (TAM) that Strapi is targeting, making it a great choice for SMBs and less-regulated enterprises.
In addition to the Community open-source edition, Strapi designed their commercial product offering and tiers with a bronze, silver, and gold plan where companies pay per admin user on a monthly basis.
Their goal was to make it clear to their users and buyers what the right solution was for them given their role, stage, or use case. But they also wanted to be very deliberate about what features should go (and not go) into each tier to avoid giving away too little on the free trier while still giving the right incentives to upgrade.
As a result, the plans are defined this way:
Every open-source product is different, so what worked for Strapi might not work for you. Pierre suggests considering where you will send people most when they come from the open-source product. What do your current users want?
You don’t want to complicate the offering either. Either start on day one with a Cloud offering or move forward confidently with on-prem/open core.
Who are your competitors and what choices have they made? As mentioned, in Strapi’s case, Contentful, the category leader, was not open-source and is cloud-based.
Choosing between Cloud or on-prem/open core comes down to looking at your ICP and determining their needs. Are there ways you can differentiate your product from what’s already out there? For example, if your product is similar to a SaaS competitor, then on-prem may make more sense for a more technical audience seeking a greater level of customization and flexibility.
Once you’ve reviewed the competitive landscape, consider the companies you target. If you’re targeting small to medium-sized businesses (SMBs), it may be best to develop a SaaS model in the Cloud. Similarly, if you expect to scale to a large number of projects or users, the cloud will remove friction as you grow.
If you expect to have a smaller number of customers, it may be better to focus on enterprises with an on-prem/on-core option. A great solution to better understand this is to look at where is the traction today: in the mid-market or the enterprise?
If you need to quickly make revenue with high margins, then open-core can be a great solution. Otherwise, the Cloud will probably be a better option to increase adoption by making usage frictionless.
Although Strapi chose to offer an on-prem option first, Pierre recommends cloud-first most of the time, especially if you have application software. Building for the Cloud does take a lot of time and resources up front, but it also has a number of clear benefits.
According to Pierre and Victor, one of the most common mistakes OSS founders make is not understanding the target audience and listening carefully to the community. Strapi has relied much on their community to guide product development and credit their feedback as essential to long-term success.
When Strapi first began, the founders wanted it to be both a CMS and an API framework. But it was too much to cover. Recognizing this – and making the tough choice to focus exclusively on CMS – allowed the team to go deeper and provide more value.
“Once we only focused on building a CMS, we then double-downed on our main use cases, created much more value, and provided a way for the community to extend to other use cases, especially via their own plugins.”
— PIERRE BURGY
It might be tempting to invest in large scale marketing initiatives, but before going big, test, see what sticks, and then double down. One piece of advice would be to focus only on the bottom of the funnel.
“Before going big, start with a few experiments to see what sticks. There might be a lot of room for improvement in terms of understanding your ICP and narrowing down more before scaling your marketing budget and initiatives.”
— VICTOR COISNE
It’s tempting to try to collect leads when you get started, but your goal should be to make the process as frictionless as possible. For example, you don’t want to gate the experience – or any of the resources to use it – too early. Even today, and it will always be the case, you can download or buy Strapi without giving your email or talking to anyone.
Thanks, Pierre and Victor for sharing these great insights and congrats on the great momentum you have built!!
.png)
