Software startups have to make a lot of decisions as they move through the stages of building a thriving business. Among the many issues to debate is whether or not to open-source your technology. It is 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 is for valid reasons, it can receive a lot of backlash (as HashiCorp and Elastic learned in recent years). On the other hand, excellent tech that has been released as open source can quickly gather a lot of support from the operational support system (OSS) community.  

It is not easy for startups to decide which path to take. My own company, ARMO, chose to release our cloud-native security scanner, called Kubescape, as open source through the Linux Foundation’s Cloud Native Computing Foundation (CNCF), and we are extremely happy with the decision. 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 the pros and cons before we took the plunge. It is not something to rush into, so I am sharing some advice based on our experience.  

Removing Barriers to Adoption  

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 are offering a solution that is SaaS and does not require any agent-based, in-cluster or on-prem installation, you would need to overcome these challenges from DevOps.  

Going open source can help with this. It signals transparency and accountability, as well as allowing teams to inspect your code while contributing new code or opening issues, which makes them part of the project and gives them the ability to influence its roadmap. They are 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 have implemented the right review processes, cadences and governance. It is even better when your OSS offering has already achieved significant traction, a large install base and a certain amount of popularity in the community.  

Speed Up Continuous Improvements  

Continuous improvement is more than just a phrase. You want to find and fix bugs and improve your offering as quickly 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 over 200,000 clusters at a time when we still had only several dozen enterprise customers. This enabled us to draw on the feedback, feature requests and validate a massive user base, so that 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 is possible to use your open-source community as a test environment and then release changes in the enterprise version once you have incorporated feedback and the version is stable, or vice versa. It is good to have both options running simultaneously.  

Open Source Means Less Control  

There are also drawbacks to open source, and it is vital to keep them in mind. The main downside is that when your product is open source, you cannot control how people use it. That is especially true if you decide to open-source it through a community forum, since you are essentially handing over your trademarks to a vendor-neutral foundation.  

Despite the trust that is widespread throughout the open-source community, there will still be some who will just use your open-source code and avoid your paid 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.)  

Meanwhile, some people will take your hard work and use it to build a commercial product, making money off your innovation and the work of the community that you built and curated. You need to make peace with this because you cannot stop it from happening.  

Open Source Only Works if it Matches Your User Base 

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

There is a reason why we call it the open-source community. Open source is more than just a license decision: It is a set of shared beliefs, with participants who go way beyond customers. It is 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 much more likely to succeed.  

Deciding to Open-Source Software Requires a Clear Monetization Model 

Establishing a firm pathway to monetization is crucial for any startup, but it is twice as important for open-source tech startups. You have to be clear about how you will 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 and then introduce monetization methods. You could go open core, which is the route we chose, offering your core code as open source and selling 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 find the right balance between the functionality and support included in the OSS version and what 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 does not have any value except to demonstrate transparency. The thing to be aware of, though, is that this can conflict with working with a foundation. 

Once You Open Source, There is No Going Back  

Going open source is a significant decision. It does not help that it is 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 will receive nothing but applause from the tech community.  

However, it can be difficult to move in the other direction. All the code and information you have already shared will be available to the public forever, so they can use it whenever and however they like. As mentioned above, open source fans can be overly critical of anyone who reserves their OSS offering, making it less likely they will respect your code. HashiCorp learned this the hard way when fans forked Terraform after it switched from the Mozilla Public License (MPL) to the Business Source License (BSL).  

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