Open Source Does Not Mean Free

Richard Stallman, founder of the GNU Project and Free Software Foundation, is quoted saying[1][2]:

Think free as in speech, not as in beer.

The benefit of open-source software (OSS) is not that it has no cost. The benefit is that anyone has the liberty to use and modify it as they see fit. OSS does cost money; the costs are just diffuse and distributed unevenly.

So how does "free" software actually cost money? And what do companies get in return?

The sliding scale of control

There are three main types of software:

1. Proprietary, closed source, first-party software. Software your organization writes which is not public.
2. Open source, third party software. Software which you use, but is controlled by a network of engineers inside and outside your organization. Your engineers manage this.
3. Proprietary, closed source, third-party software. You do not control this software at all and pay another organization to develop it.

An organization has full control over internal code, and no control over third-party closed-source proprietary code. Open source is a middle ground between these two options. You don’t fully control or fund the software. All of these options cost money, but who you pay changes. Likewise, the level of control is a sliding scale between these options. You control your internal code most, you partially control OSS, and you do not control third-party proprietary code at all.

It’s obvious how the first and the third options cost money: either you pay your engineers to build something internally, or you pay another company for their off-the-shelf solution. How then does open source cost an organization?

Types of open source monetization

There are many ways to fund open source work. Each business model comes with its own set of tradeoffs. These business models can be mixed-and-matched.

Freemium

The freemium model means the software is mostly open-source with premium (typically closed source) features. Anyone can use it for free, but additional functionality requires payment. A specific and popular example of this is putting various government compliance features behind a paywall. Small organizations typically have to worry less about compliance functionality than large ones, and the large organizations are usually the most able to pay. It’s a win-win, at the cost of being quite boring. A good example of this is Canonical and its flagship open source product, Ubuntu Linux. Ubuntu is ubiquitous, but only the largest companies pay for Ubuntu Pro. Ubuntu Pro, among other features, provides FIPS compliant[3] crypto modules which make it so that companies may use their software in government settings.

Consulting

Some companies make their code open source, but they consult on the side for the tool. Companies pay the developer to get help with using the tool. The best example of this is the SQLite database. SQLite is the most deployed database engine in the world[4], and the software is released under the public domain. When D. Richard Hipp and his company first created SQLite, phone manufacturers like Motorola and Nokia contracted with him to help port it to mobile devices.

"Help Me With My Black Magic Please"

This business model entails making the software so incredibly hard to deploy such that paying for a SaaS version of it seems reasonable. The best and most recent example of this is the NextJS framework and the web hosting company Vercel. Due to its complexity, and parts of it which are likely left intentionally opaque, many struggle with deploying NextJS effectively. On the other hand, Vercel makes it trivial to deploy and scale a NextJS application, and they charge accordingly. In mid-2025 Vercel surpassed 200 million dollars in annual-recurring-revenue.

Blitzscale

Blitzscaling means disregarding profit, taking significant VC investment, scaling the company as quickly as possible, and deferring monetization. Most success stories here eventually sold the company for an exit, with exceedingly few finding a way to make money directly. The best and most recent example of this is the Bun javascript runtime[5]. Bun was recently acquired by Anthropic. Often this can go astray when the acquiring company guts the project, paywalls important features, or even closes the source. It’s too soon to tell what will happen to Bun, but many great pieces of software have died this way.

Commoditized Complement

Finally, there are the rare cases where open source is spun off from a large company or is funded entirely by large companies, simply because the large company has a large vested stake in its success. Google Chrome is a good example of this. Google doesn’t make much money directly from Chrome. Google is an advertising company, their bottom line is tied to the amount of time people spend browsing the internet. It follows that the best way to get more internet users is to make it as easy as possible to browse the internet. By making Chrome excellent, they get more eyes on their advertisements and make more money. If you want to read more about this, check out this article about "commoditizing your complement"[6].

Indirect Costs of OSS

Now that we’ve identified the ways companies directly pay for free software, let’s look at some ways companies indirectly pay for OSS.

Open source is progressive: it costs large organizations more than it does small organizations. Many of the costs of open source do not appear until an organization reaches scale.

At the large software company I work for, it’s my job to ensure we use open source software correctly. We have hundreds of engineers all working on different facets of this open source. We have security engineers who carefully audit each project we pull in. We have engineers who build infrastructure to defend against supply-chain attacks[7]. We have engineers who contribute bugfixes and features upstream. We have lawyers who determine whether we are compliant with the innumerable and complex OSS licenses. And finally, for any company of any scale, investing heavily into an open source project means that there need to be engineers able to deeply understand the external dependency and how it is integrated into our first-party code. For a large company consuming open source liberally, a ballpark estimate of the payroll cost is likely upwards of tens of millions of dollars.

Beyond payroll, there’s a third category of cost: third-party tools and services to help manage OSS. These aren’t payments to the creators of the software you’re using, they’re payments to entirely separate companies that exist to make OSS manageable at scale. BlackDuck scans packages for vulnerabilities. Artifactory stores source code and binaries. Snyk monitors dependencies for security issues and automates fixes. These additional costs can also reach tens of millions of dollars.

Conclusion

Companies pay for open source:

• directly through support contracts, subscriptions, and donations to non-profits that build critical infrastructure.
• indirectly through payroll for employees maintaining OSS.
• by paying for third party tools to manage open source.

By paying these costs, companies gain large pieces of battle-tested functionality.

Choosing open-source over building things internally means sacrificing some control and sovereignty for expediency. Instead of hiring engineers to build a thing, you hire engineers to manage the risks inherent to things other organizations built.

Ultimately, the choice to use OSS or not is situationally dependent; there is no dogmatically correct answer. Every company faces different challenges, what type of software they use should suit their situation.

References

1. https://en.wikipedia.org/wiki/Richard_Stallman
2. https://en.wikipedia.org/wiki/Gratis_versus_libre
3. https://en.wikipedia.org/wiki/FIPS_140
4. https://sqlite.org/mostdeployed.html
5. https://bun.com
6. https://gwern.net/complement
7. https://en.wikipedia.org/wiki/XZ_Utils_backdoor