Contributing is cheaper than forking and the Linux Foundation did put a number on it.
Forking an open source project feels like the fastest way in. It is usually the slowest way out.
The first time I got serious about open source, I forked a project. If that word is new to you: forking means taking the freely available code, keeping your own private copy, and changing it to fit you. I thought it was the fastest way to get my hands dirty. Add the features I wanted, cut what I didn't, make it mine. And it was. For about a month. Then keeping it in step with the original became a second job, and the fun went out of it.
Most organizations make the same bet at a far larger scale, and the Linux Foundation just measured the bill. Across the more than 500 IT leaders it surveyed, the average organization was carrying 86 private forks, each a copy it now patches by hand. Keeping them in sync burns around 5,160 engineering hours, roughly $258,000. Every release cycle.
It gets worse the closer you look. On top of the forks, the gap between what a project offers and what a company actually needs pushes teams into private workarounds, costing another $670,000 a year. For the largest organizations, the fork upkeep alone climbs past 11,000 engineering hours per release cycle.
The moment you keep a change to yourself, everyone else stops maintaining it for you. It is yours alone now. Every time the original moves forward with new features and security fixes, you re-apply your changes by hand, re-test them, and watch half of them break. The gap never closes on its own. It widens, quietly, until the one person who understands your copy hands in their notice.
There is another path, and it is the boring one: contribute the change back. That means sending your fix or feature to the original project so it becomes part of the version everyone shares, the one developers call upstream. This is not generosity. The study is blunt: contribution is an investment, not a charitable expense. It is the cheapest way to stop paying rent on your own copy. Once your change lives in the shared code, thousands of other people keep it working, for free. That is why the same study measures a return of two to five times the cost of contributing, and closer to 3.6x for code. Contributors also get security fixes faster and help decide where the project goes next.
People still argue about whether to build software or buy it. Open source sits outside that argument. You pay either way. The licence costs nothing, keeping it running does, like any software you own. All you really choose is where the money goes: into a private copy no one else will ever touch, or into the shared version, where the cost is split and comes back multiplied.
Most companies take far more from open source than they ever put back, and file it under free. The next time you need something a project does not offer, that habit quietly picks your options for you: carry the change alone, or help build it where the whole ecosystem shares the load. Which one is your organization actually set up to do?
