Why enterprises should pay for open-source software.

I installed Linux for the first time over thirty years ago. Ever since then, I’ve had at least one machine running Linux. My first interactions with the idea and practice of open-source software were even earlier. I was an 18 year old college student excited about the rise of the Internet and eager to learn as much as I could. I pitched in on documentation and build engineering for one of the earliest web browsers. In the early 2000s I helped move a major bank's mission-critical systems off Solaris and onto Linux. At the time, this was still a slightly heretical thing to propose in a large bank. 

My technology career has been lived in and around open source. So it may sound strange coming from me, but I think enterprises should pay for open-source software. The freedom to use open-source software for free should not be compromised, but in the vast majority of cases, commercial support is the better engineering and business decision. 

Two kinds of free

The open-source movement has always distinguished between the two meanings for "free”.  There is free, as in freedom: the right to run, read, modify, and redistribute the code. And then there is free, as in beer. The GNU license with its copyleft provision and the permissive Apache license guarantee the first kind absolutely. The second kind, zero cost is optional.

Our focus is on Apache, GPL, and other closely related open-source licenses. The vast majority of widely used open-source software is delivered under these licenses, which permit commercial use at no cost. There are other source-available licenses (Business Source, various Creative Commons variants) that let you read or even use the code but forbid unpaid commercial use. Those are a different arrangement with a different logic. Our sole concern is with software that is genuinely free to use commercially at no cost, where paying is a choice.

Why use open source at all?

For completeness, we will reiterate the reasons we think enterprises should build on open-source platforms and software. This debate was largely settled 10-20 years ago, but it’s worth recalling why enterprises have shifted with conviction to open-source software.

Commercial conditions change. Companies get acquired, pivot, run into a rough quarter, or simply decide a product is no longer strategic. When that happens to a proprietary software system you’ve built mission-critical applications on, you are exposed. The product may be orphaned. Support dwindles. The roadmap you were promised goes up in smoke. You are out on a limb, and your options are to keep running unsupported software with no path forward, or to undertake an expensive, emergency  migration. Even the largest and most stable technology companies are not immune, plenty of orphaned products carry famous logos.

If your platform is open-source and the commercial vendor behind it stumbles, you have options that simply do not exist with proprietary software. You can move to a different commercial distribution of the same underlying project. Migration is less complicated, because the core is the same code. If no viable commercial option exists, you can fall back to the open build and support it yourself. Neither path is free of effort, but they are available. For mission-critical systems, this is reason enough to prefer open source.

This is not a theoretical argument. Remember the bank migration I mentioned? It was, at its core, a decision to stop being dependent on a single commercial Unix vendor. Twenty-odd years later that decision holds up. The commercial distribution we used and loved at the time (Solaris) is no longer maintained. The company that made it and the hardware it ran on, is no longer around.

The custodian model, and how paying makes it work

Most large open-source projects now have one or more companies serving as commercial custodians. These companies employ the core contributors and sell support, certified builds, and enterprise features around the open core. The template was set when RedHat hired several kernel maintainers in 1999. At the time, Linux was a hobbyist kernel with growing adoption in research and educational institutions. With commercial support came wider adoption within industry. This arrangement is now prevalent across the ecosystem, and it is mutually beneficial.

When a project makes the jump from niche or hobbyist use to widespread adoption, the custodian model helps stabilize it. The committers and maintainers are paid to work on the software full-time instead of during stolen evenings. Features and security patches land faster. The project gets the sustained attention of dedicated experts rather than the intermittent attention of talented volunteers. And critically, users of both the free build and the commercial distribution benefit, because the improvements flow into the open core. Paying commercial customers help keep the open source project healthy.

When you buy commercial support, you are not only buying a support contract. You are funding the continued health of software your business depends on. 

The free-rider question

I am very sympathetic to the moral argument against commercial users free-riding on the contributions of open-source community volunteers. The open-source community settled this question decades ago, when it chose the GPL and permissive licences over more restrictive alternatives. The decision was that there would be no prohibition on commercial free use. That freedom is part of why open source won. So the free-rider question is not a legal one. 

An enterprise can take the free build and run it without paying anyone. The licence permits it explicitly. But is it in your long term interest to do so?

I think for most enterprises the answer is no, and the reasons are practical rather than moral.Unsurprisingly, the practical reasons align with the healthy outcome, which is usually necessary if a collaborative software development project is to succeed. 

Why paying is the better decision

Set the ethics aside and look at it as an operator. The reasons to pay are rooted in pragmatism.

You need someone to call. When a mission-critical platform fails at the wrong moment, you want an escalation path to people who know the code base better than anyone on earth. This is not a nice-to-have luxury; it lets you run a leaner team and point your own engineers at the functionality for  your business rather than at the internals of a general purpose platform.

Self-support is often the more expensive option. Running the free build is not actually free; it is a decision to self-insure. To do that effectively for a critical platform, you need in-house expertise deep enough to diagnose and patch the code under pressure.It also concentrates risk in a few individuals whom you can no longer afford to lose. Commercial support is often the cheaper path once you price the alternative honestly.

You want patches when you need them. A support relationship means security and functionality fixes on a timeline you can influence, not one you wait on. When a critical CVE lands, the difference between a vendor pushing you a certified patched build and you backporting a fix yourself is often the difference between a quiet afternoon and a very long night or week.

Regulation frequently requires it. Regulators commonly expect either a commercial support contract or documented assurance that you employ a team who knows the code base and can make changes when required. "We run the free version and hope" rarely survives an audit.

Indemnification. Commercial vendors typically indemnify customers against intellectual-property claims on the code they ship. If someone alleges that a component infringes a patent or copyright, that is the vendor's problem to defend, not yours. For an enterprise with real assets to protect, that risk transfer alone can justify the contract.

Provenance and supply-chain assurance. The last few years have made this urgent. A vendor's certified build comes with a known provenance, signed artifacts, CVE scanning, and increasingly a software bill of materials. After incidents like the xz backdoor — where a critical open-source utility was compromised through a single overburdened maintainer — the value of a commercial custodian vetting what actually goes into the build you run has become very hard to argue against.

A voice in the roadmap. Paying customers get to influence priorities. When you need a feature or a fix, being a commercial customer of the custodian is the difference between filing an issue into the void and having a conversation with people who can act on it.

Ecosystem sustainability. This is the free-rider question answered from the other side. The xz incident was at its core, a sustainability failure — critical infrastructure resting on one unpaid person. When enterprises pay, maintainers get salaries, projects get resourced, and the software the whole industry depends on stays healthy. You are paying because a well-funded project is a lower-risk dependency, and your payment is part of what makes it one.

In Summary

I am as committed to open source as I was at eighteen, and more convinced of its value now than I was then. The freedom to use, read, and modify the software, all while retaining the ability to walk away from any commercial vendor, is why enterprises should build their most important systems on it. 

That said, for nearly every enterprise running open source in a serious, mission-critical capacity, paying for commercial support is the right decision. It is cheaper than self-support, safer in the ways regulators and courts care about, and better for the health of the software you depend on. You pay because it is smart. The community benefits because you did. That is not a compromise of open-source principles. It is the incentives in the ecosystem working as intended.