The open source advantage: Faster bugs, better builds, wider buy-in

Software companies have a lot of decisions to make as they move through the stages of building a thriving business. Among the many issues to debate is whether or not to open source their technology. It’s a big decision, and the licensing around open source receives a lot of attention in tech circles.

Part of the issue is that open source comes with a lot of strong opinions. Whenever a large company decides to restrict its license, even if it’s for valid reasons, they can receive a lot of backlash (as HashiCorp and Elastic learned in recent years). On the other hand, excellent tech that’s released as open source can quickly gather a lot of support from the open-source software (OSS) community.

It’s not easy for enterprises to decide which path to take. My company chose to release our cloud native security scanner, Kubescape, as open source through the Linux Foundation’s Cloud Native Computing Foundation (CNCF), and we’re extremely happy with the decision. In fact, Kubescape was recently promoted to incubating project status and is used by thousands of enterprises globally. Overall, we see it as a net benefit, but we did carefully weigh up the pros and cons before we took the plunge. It’s definitely not something to rush into, so I’m sharing some advice based on our experience.

DevOps teams have many good reasons to be reluctant to introduce new code into their clusters and environments: It could be full of bugs, undermine their security setup and/or mess up their existing configurations. Unless you’re offering a solution that’s entirely SaaS and doesn’t require any agent-based / in-cluster/on-prem installation, you’ll need to overcome these hesitations from DevOps.

Going open source can help with this. It signals transparency and accountability, and gives teams the opportunity to inspect code while contributing new code or opening issues that makes them part of the project and gives them the ability to influence its roadmap. They’re more likely to trust a solution that invites them to check the core code than one that asks them to trust a closed box.

This trust is amplified if you donate your code to a foundation that has credibility and a lively community base with a strong “cool” factor. A reputable foundation helps validate the quality of your product and testifies that you’ve implemented the right review processes, cadences and governance. It’s even better when your OSS offering has already achieved significant traction, a large install base and a certain amount of popularity in the community.

Continuous improvement is more than just a slogan. You want to find and fix bugs and improve your offering as fast as possible, and the best way to do that is to ramp up usage. Going open source means that your technology gets road-tested in the real world by far more users than you could reach through private sales.

We found that our platform was present in more than 200,000 clusters at a time when we still had only several dozen enterprise customers. That enabled us to draw on the feedback, feature requests and validation of a massive user base, so we could learn and roll out improvements more quickly.

At the same time, adoption increased, partly due to our greater reach, and partly because our product was improving at such a rapid rate. It’s possible to use your open-source community as a test environment, then release changes in the enterprise version once you’ve incorporated feedback and the version is stable, or vice versa. It’s good to have the dual options running simultaneously.

Those are the main advantages, but there are also drawbacks to open source, and it’s vital to keep them in mind. The main downside is that when your product is open source, you can’t control how people use it. That’s especially true if you decide to open source it through a community forum, since you’re essentially handing over your trademarks to a vendor neutral foundation.

Despite the widespread trust throughout the open-source community, there will still be some who’ll just use your open-source code and avoid your for-pay versions and features. (Of course, you can and should consider these free users as part of your sales pipeline, and work to upgrade them to the enterprise version for additional features and benefits).

There will even be some people who’ll take your hard work and use it to build a commercial product and make money off your innovation and the work of the community that you built and curated. You need to make your peace with this, because you can’t stop it from happening.

One of the main factors in deciding open-source projects is your user base. You need to know and understand their concerns and motivations, so you can correctly predict how they’ll respond to an OSS offering. If your audience is very technical, such as security engineers, DevOps teams and developers, they’re more likely to fall into the pro-open source camp.

There’s a reason why we call it the ‘open-source community.’ Open source is more than just a license decision: It’s a set of shared beliefs, with participants who go way beyond customers. It’s closer to a religion or a cult than a purchasing choice. If your user base shares your love for the idea of open source, this path is a lot more likely to succeed.

Establishing a firm pathway to monetization is crucial for any enterprise, but it’s doubly important for open-source companies. You have to be clear about how you’ll make your money, because open source could leave you without a strong cash flow.

For example, you might choose to make all your tech entirely open source for a year, to drive penetration and feedback, then introduce monetization methods. You could go open core, which is the route my company chose, where you offer your core code as open source, then sell additional services and features on top.

Many companies decide to offer both an OSS version and an enterprise version. This can work, but you need to strike the right balance between the functionality and support that’s included in the OSS version, and that which you provide only for paying customers. Another option is to set things up so that the open-source code can only be used in combination with the enterprise version. The OSS version doesn’t have any value except to demonstrate transparency. The thing to be aware of, though, is that this can conflict with working with a foundation.

Going open source is a very weighty decision. It doesn’t help that it’s pretty much a one-way street. You can move from closed source to open source, or from a more restrictive license to a more open license, whenever you like, and you’ll receive nothing but applause from the tech community.

But it can be very difficult to move in the other direction. All the code and information that you’ve already shared will be available to the public forever, so they can use it whenever and however they like. And as mentioned above, open source fans can be very critical of anyone who walks back their OSS offering, so they’re less likely to respect your code. HashiCorp learned this the hard way when fans forked Terraform after they changed from an NPL to a BSL license.

That said, open source can be awesome when the circumstances are right. If you’ve weighed up all the factors, your user base and tech offering align, and you’ve identified a reputable foundation that believes in your mission, you can benefit from a slew of advantages, like we have.

Shauli Rozen is the CEO and cofounder of ARMO and the creator of Kubescape.