Commercialising Open Source Software

So you’ve got a wildly popular open source project - be that measured in actual adoption, GitHub stars, forks, etc. And now you’ve raised some VC money to take your project to the next level, build an “enterprise-grade” product and eventually generate revenue.

But here’s the challenge: connecting the dots from a popular open source project to a viable commercial offering is fraught with many challenges. I’ve spent the last two years of my career working to do exactly this with Project Calico, one of the world’s most widely adopted open source Kubernetes networking tools. And I did this after spending nearly five years helping grow and scale Cloudflare, one of the world’s most widely adopted web performance and security tool, with tens of millions of free users.

Here’s what I’ve learned along the way:

Your open source offering is the free tier of your freemium business model

It seems obvious, but it’s often something project maintainers forget as soon as they start exploring possibilities for commercialisation. It’s because you start talking to the large, enterprise-scale adopters of your open source project, and then starting building the features that they need to deploy your project in production-grade environments.

But here’s the challenge - your largest, enterprise-iest users might not be representative of the broader market opportunity. In fact, they probably aren’t.

We made this mistake with Calico. Our commercial offerings were tools to help enterprise users get the most out of their open source deployments. But the commercial tools we built were quite a logical leap for users of our open source offering - we needed to give them a long winded explanation of how they were even related to each other. And, we treated the commercial offerings as a very separate entity: a separate product, with separate documentation, separate marketing, and separate support.

What we learned the hard way is that this makes it really hard to grow beyond the first wave of innovators and early adopters to the early majority. What we’ve instead learned is that your open source offering has to be the basic, free version of your commercial offering. And we’ve thus had to retroactively make open source and the community the starting point of our commercialization strategy.

Why? Because your free community is one of your most valuable assets!

This is something Cloudflare did very well. While Cloudflare is not an open source platform, it does operate a very very popular freemium networking and network security platform. Almost every product has a free version, and we started almost every new product launch by building and testing with a free version targeted at the wider community. Why? Because these users will use the product even when it SUCKS and will give you lots of great feedback on how to improve your product. And as you build with your community, a small portion of them will grow beyond hobbyist or free users and adopt the commercial solution they helped shape to build.

So, if your open source offering isn’t a skimmed down version of your commercial offering, I’d suggest you consider adding a skimmed down version of your commercial tools to your open source or free edition, and ensure your community is aware of and making use of those tools first. Only once they experience aha moments and build habits with those will they naturally come to you to take their free or open source deployments to the next level.

The first step to commercialising your product is getting visibility into your community

Commercialising open source is like trying to pursue product-led growth with no visibility into what your users are actually doing with your product. You likely have very limited telemetry, if any, from these users on what they are doing with your product by the very nature of self-managed software.

There are a few ways to get visibility into what your community is doing:

• Encourage community members to share (publicly) what they are building with your open source tools
• Build a free cloud service that encourages open source users to extend their open source deployments with your free tool in a way that fosters ongoing usage

Ultimately, these two efforts will help you get both qualitative and quantitative user feedback from your most enthusiastic community members. User feedback and experimentation in your early days of commercialization are critical, probably more critical than closing large revenue numbers, for your long term success as you are still building product-market fit.

Someone who has done this really well is Pulumi. Here’s the second sentence of their docs:

Pulumi is free, open source, and optionally pairs with the Pulumi Cloud to make managing infrastructure secure, reliable, and hassle-free.

This is also something we haven’t really done well with Calico. We started with a self-managed commercial offering designed for really large enterprises, and then built a cloud version of that self-managed commercial offering and offered a 14-day trial. But what we learned from user research is that it could take many months, maybe over a year of basic usage of Calico before a user really experiences an incident or performance issues that would ultimately lead to the aha moments needed to then champion the purchase of the commercial product.

We are currently working to implement some major changes to our cloud product to help address these challenges.

Dev advocacy is the heart of your marketing strategy

If the foundations of your project are open source software and community-driven growth, then it logically follows that developer advocacy should be treated as the core of your marketing strategy.

Traditional B2B software companies will often focus on generating leads and building the top of funnel of the sales pipeline. But focusing on growing pipeline rather than growing mindshare within the community is a bit short-sighted. The goal of developer advocacy is more than just generating awareness of your offering - developer advocacy is about building relationships with those developers and helping them to be successful with your product.

Where organizations often go wrong is trying to use traditional marketing KPIs, such as marketing qualified leads or sales leads generated, to measure the success of a developer advocacy program. Successful dev advocacy programs will focus on a combination of quality and quantity in terms of engagement, and thus evaluation metrics should be more nuanced. Dev advocacy programs will also not yield immediate success, so patience is required before you can judge whether or not your community is converting into sales pipeline. Active engagement in your community Slack or Discord, GitHub, Twitter, and other community touchpoints are leading indicators of how well you are reaching your community.

This was something Calico starting out doing well, but over the years, the company stopped investing in developer advocacy and instead on traditional enterprise marketing. It didn’t help with COVID that community events slowed down, and developers turned online to learn more about Kubernetes tooling. Now that I am back from maternity leave, it’s something that I am quite keen to revitalize, and so I’ve been working much more closely with our developer advocacy and marketing teams to change the way we operate. I’ve started doing more developer advocacy myself, speaking at Kubernetes Community Days UK earlier this year and local meetups in London. I am hopeful that we’ll be able to revitalize our community outreach with more focused attention on these efforts!