Typical Mistakes in Open Source Sales
One key way Open Source Software is different from classic Commercial software is that not every user is going to be a customer. In fact, for most successful Open Source projects, the number of users and uses is orders of magnitude more than the number of customers and “paid” deployments.
You may argue Commercial Open Source is just a case of “Freemium” model, which a lot of SaaS solutions use, yet there is a difference, if you have a SaaS you have total control over changing what is included in “free forever” plan and what is not, whereas in open source there’s much more nuance.
For simplicity, let’s focus on Single Vendor Open Source, where a single commercial company has all IP (trademark, source code, etc.) related to a given Open Source Project. From that company’s point of view, there are N deployments of the project, showing its traction, and P% of those are paying customers. These paid customers can be running the “Enterprise” version, Support Subscribers, or running in your Cloud.
The number of paying deployments (D) equals N × P if P is a proportion, or N × (P/100) if P is a percentage. So to drive it up, you can either increase N or increase P%. To increase your Sales $$$, you also can increase the number of $ you get per deployment, though trying to grow your business only through price increases is usually a very slippery slope.
With basic math out of the way, let’s talk about a couple of mistakes I see over and over again, which can cause catastrophic outcomes for the project, and which are basically on the opposite ends of the spectrum.
Implementing Open Source Crippleware strategy
First, if you just listen to members of the Sales team, they often hate what the Paid version needs to compete with the Free version. In their mind, if only they could avoid “losing to Free and Open Source,” they would easily hit their quota many times over. As such, they often would advocate for increasing differentiation, which often means crippling the free and Open Source version. This, of course, can increase the P% and, especially short term, can give a very positive boost to sales, as it often takes a while for your users to find a feasible alternative.
Over time, though, you often would see your user base stagnate and shrink, and with N going down, there is only so much and so long you can continue by increasing P% and raising prices.
Furthermore, it is very possible for members of your community to come together and exercise their “right to fork,” which is unique to open source and which does not exist for “Freemium” SaaS Software. We have seen it happen with Redis, Elastic, MySQL, Terraform, and OpenOffice, among others.
Not enough Differentiation
Having said that, not having enough differentiation is problematic, too. Even if the number of deployments is insanely high, if your P% is zero… you’re obviously not making any money. You need to make sure there is a reason for customers to pay, and most likely it should not be charity/donation-based, as those do not scale and are hard to secure on an ongoing basis (though I’ve seen small projects successfully funded through donations, I would not call it a sustainable business model).
How to avoid those mistakes?
As Garima Kapoor, co-founder of MinIO, put it: “Never let monetization interfere with adoption.” I think it is a great way to think about this problem—you want everyone to be able to use your Open Source project and find it awesome for the purpose, yet you want those with the ability to pay to be motivated to do so. It can be a hard balance to find, but it is essential for long-term success.
Want to talk about where balance can be for your project? Drop me a line.
