Is your open source project too good?

There are plenty of ways that an open source startup is different from a ‘traditional’ closed source one, but among the differences is the very real risk that your business could fail because your core technology is too good, too easy to use, too comprehensive.

Why would anyone pay for support if they can get set up in two clicks and have everything work? Why pay for support if integrations really are seamless and easy to manage? No one wants to need support — they hope that everything is so easy that they never need to log into Slack or read the docs.

Why pay for an enterprise edition if the pure open source version is so featureful? As long as you’re running it yourself, in your environment, it makes no sense to purchase a license if the FOSS is so good that it meets all your needs.

Cloud / Hosted

There is one open source model that gets away from this problem — the cloud version. Even with this, however, you only need someone else to manage the software if it’s, well, hard to manage. If the operational story is automated and easy, the value of having it delivered as a SaaS experience is lower.

Shall I make my project crappier?

I don’t want to be the person advocating for crappy open source projects. I also don’t think that crappy open source projects are necessary (or advisable — to the contrary, I think your open source project should be awesome if you intend to monetize it) if you’re trying to build an open source company. What I do advocate, however, is thinking very carefully about how any commercial offerings are going to add value above and beyond your open source project.

If your intention is to create a profitable business around the project, you need to think about this all the time, with every new feature addition, and you need to start thinking about it early. Removing a capability from the free version is a bad look (and not always entirely possible with an open source project, anyway). So you want to make sure you’re not adding something you’ll regret later.

IC versus teams

The most common way to think about this is that your open source project is for individuals, and the commercial options have some functionality for teams and/or managers. Sometimes the open source project and the commercial project are actually different — this is the case at Deepfence, for example. In their case, the open source and commercial project do different things, so it is very obvious where one stops and the other begins, and the commercial project does not replace the open source one — a paying customer would likely still be using the open source project. I actually really like this model, because it is a way to have an outstanding open source project without worrying that it will be too good for commercialization.

The bottom line is that open source startups have to be careful about how their product packaging fits with their open source monetization model. Because being too good can be a bad thing.