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.

 Subscribe via RSS

The post Typical Mistakes in Open Source Sales appeared first on Peter Zaitsev.

It’s no longer surprising when a corporate-owned open source project abruptly shifts to a more restrictive ‘source-available’ license, such as SSPL or BSL. However, foundation-backed open source software has traditionally offered greater stability in this regard. While commercial sponsors may change and funding levels can fluctuate, the underlying software license has generally remained the same.

That’s what makes the whole NATS situation so unusual—and honestly, a bit alarming. If Synadia manages to pull NATS out of the CNCF and switch its license, it could shake people’s trust in the idea that foundation-governed open source projects are safe from that kind of change.

Here is CNCF message,  response from Synadia’s Derek  Collison (original creator of NATS), and also HackerNews discussion  for those seeking more first-hand information on this topic  

I won’t go over the whole story again, but I do want to call out a few key points.

First off, I think the NATS community deserves to have a say—this isn’t a decision Derek and Synadia should be making on their own. If supporting open source NATS just isn’t sustainable for them anymore, they should fork the project, apply whatever license they want, and pour their resources into that new version. Maybe that new fork takes off and NATS fades out. Or maybe the community rallies, new sponsors step in, and NATS keeps thriving as an open source project. Either way, the choice should be in the hands of the community, not a single company.

Second, donating a project to the CNCF should be a one-way street. You can’t just take it back later—and honestly, that’s kind of the whole point. It’s about giving the community ownership and ensuring the project lives beyond the original sponsor’s control.

Third, if Synadia really wants a commercially licensed version of the NATS server, there’s nothing stopping them from doing that, without needing to “take back” or fork the whole thing. They could offer something like “Synadia Enterprise for NATS” and still benefit from the brand recognition they’ve built. What they wouldn’t get, of course, is exclusive control over the NATS name, which might be what they’re really after.

Finally, there’s a lesson here for the CNCF too. If it wants people to trust the projects it hosts, it needs to make sure situations like this don’t happen. That means locking down all the key assets—like trademarks and licensing rights—before fully accepting a project. If things are still legally messy, like with the NATS trademark, maybe those projects should be flagged with a different status to show they’re not yet fully aligned with CNCF’s IP and governance standards.

 Subscribe via RSS

The post NATS goes Nuts – Quite Unique Open Source controversy appeared first on Peter Zaitsev.