To be or not to be (open source)? 

It’s one of the most important decisions that founders in infrastructure and developer tools make, but it isn’t exactly a well understood one. What are good reasons to be open source? And what aren’t such good ones?

First, a little about me. I've spent most of my career building open source and open core products, most recently at HashiCorp, where I spent 7 years leading Vault Enterprise from creation to over $100M in ARR. I've seen just about every possible justification for products choosing to be open source or not. 

In this post, I’ll go through how I think about why products should or shouldn’t be open source. The most important piece of advice I can give: treat this decision with extreme consideration and gravity, and don’t let it be an afterthought. 

The moral imperative for open source

Most posts that cover this topic go straight into how open source can help or hurt your business strategically. And while this is important (we’ll cover it later), it’s only a part of the picture. There are also moral reasons to choose open source.

Readers may be familiar with (or a part of) the Free and Open Source Software (FOSS) group of communities. Well demonstrated by Richard Stallman’s GNU Foundation, FOSS-style communities are often dedicated to a moral imperative to ensure that fundamental civil liberties of users are protected in how their software is licensed and developed. 

For these types of users, open source and open source licenses are protecting users’ rights to privacy and security. The GPL suite of licenses created by the GNU Foundation are exemplary of how FOSS-style communities create legal protections to accomplish their goals and ensure that software developed by these communities remains aligned towards the principles of FOSS. Popular software developed by FOSS communities includes the Debian derivative of Linux (something that Richard Stallman would likely pillory me for not referring to as GNU Linux), the GNU C Compiler (or GCC) and the popular Linux windows managers Gnome and KDE.  

The FOSS community is only part of the picture, of course. On the other end of the spectrum is the commercial open source community. This community does not typically see open source as a strict means of social action or change, and more sees open source as a functional means of developing commercial products (potentially even closed source commercial products) from common, community developed and maintained components.

Back to you. If you align with FOSS values, that’s a great reason to build an open source company! There doesn’t need to be a strategic business case if you feel strongly that morally, you should be building open source software. The decision is still complex in a universe with many stakeholders (especially your investors, if they exist) – but you should feel comfortable and confident standing up for your values. 

The strategic imperative for open source

Whether you see open source as a moral imperative or not, the decision to operate in open source should be a strategic, doctrinal one. 

You should not decide to open source portions or a whole product without a very good, strategic reason. There are significant costs associated with creating and cultivating an open source community, and without investing the time and resources into both simply open sourcing a product for “kicks” can be seen as an incredulous and saccharine move by the open source community writ large. 

I’ll run through a few good reasons I’ve seen to open source your product, and then cover a few bad ones.

Open source to improve your product: Kerckhoff’s Principle

In many cases, being open source forces your product to be better. This is part of why when I was working at HashiCorp, most of Vault’s core cryptologic libraries were open source. 

A quick history lesson. Auguste Kerckhoffs was a famous Dutch cryptologist who arguably launched modern military cryptography. One of his greatest contributions to the field was Kerckhoffs’s Principle: a set of axioms that define how to describe an encryption system secure enough for military use. The most important aspect of Kerckhoffs’s Principle has been immortalized in the phrase “there is no security in obscurity” - an encryption system is secure if an enemy has all knowledge of how that system works, including some access to unencrypted messages, and still gains no advantage in breaking into that system. 

One of the best ways to ensure we were held to and successfully pass rigorous standards was to keep the internals of Vault’s cryptology in open source. If we were able to successfully build encryption securely even when the mechanisms to generate that encryption were wholly visible to the world, we could meet a standard that was globally accepted to be secure and do so in a way that most of Vault’s competition to this day did not. 

By keeping these components in open source, Vault also was similarly able to work with the community in developing and affirming new encryption mechanisms as they came out - ensuring through the scrutiny of a world’s worth of cryptologists that it was able to utilize such technology in the safest way possible. 

Even if your product isn’t in the cryptography universe, the same logic can apply. If the unique constraints of your market and company mean that open source will force you (in a good way) to hold your product to a higher bar, that’s a good reason to be open source.

Open source for low level infrastructure

For some fundamental parts of infrastructure, many developers won’t consider using products that don’t have at least some open source component. In this scenario, you need to be open source to even be in the discussion.

Outside of operating systems (which rarely have a commercial component anymore), the best example here is probably databases. The most successful databases today, outside of Oracle, are all open source. Developers will happily pay someone to run those databases for them, but the underlying technology needs to be open source to be trusted. Though plenty of great alternatives exist (Dynamo, Aurora, Spanner, etc.) they continue to lose out to Postgres, MySQL, and the lot. 

Open source as freemium

For the mid enterprise segment – which I’d define as companies with anywhere from $100M to $3B in annual revenue – the ability to kick the tires and try out a product can be very important. Open source can be one of the most direct ways to introduce this to prospective users. 

They can run the code themselves (locally or otherwise), poke around, and get a sense of whether this is something that might solve their problem. Closed source or source-available free tiers can sometimes work, but if both do not allow most users to modify code and then take advantage of those modifications in what they eventually use and standardize, it can be a nonstarter. 

There’s a delicate art to doing good open source marketing like this, and people who can do it are worth their weight in gold.

Bad reasons to be open source

I’ve seen founders pick bad reasons to be open source, too. Both start as innocent enough sounding, but end up being glorified exploitation of the very open source communities that so many work hard to create.

Open source for lead generation

When you have a large open source offering, abusing the social (or even sometimes legal) contract you have with your community can be damaging to your product and company’s success. The most glaring way I see this happen is companies using open source as a means for generating sales leads. Often this is done by harvesting the emails of committers and followers to a repository then dumping them into an organization’s marketing and lead qualification engine without getting the permission of the community to do so. 

Regardless of where you sit on the spectrum of OSS users, this is seen as a significant transgression. Following an open source repository, and especially committing to an open source project, is not consent to be marketed to by an organization. Don’t do this; it can create a serious reputational risk for your company and may even create legal exposure in some countries. 

Open source for contributions

Another common way to exploit the open source community is to treat committers as employees, using open source as a way to garner free labor. You see this in projects where the communication between employees of companies benefiting from projects pseudo-demand unreasonable timelines from unpaid maintainers. This is far from a great look - particularly when you consider that at the time of writing there are major layoffs and other tumult going on within tech that are likely negatively affecting the lives of many open source community contributors. Attempting to exploit OSS workers as unpaid labor in a period like right now is arguably unconscionable and definitely an item of reputational risk.

Not only that, but being open source for the “free contributions” is naive in the first place. The fact that much open source software has a maintainer crisis is well documented. Most projects are maintained by a small, tight knit group of overworked, underpaid developers. For a new open source project, the likelihood that you’ll receive meaningful contributions over time from the community without a massive coordination effort is quite low.

On the other hand, if you find a group of regular contributors who you like working with, there’s absolutely nothing wrong with hiring them. We did this often at Hashicorp, and these people ended up being some of our most productive employees.