The Fork You Forgot to Budget For
Patching open-source software you depend on feels free. It isn't. Every private fork is a maintenance tax you pay at each upstream release, and funding the change upstream is almost always the cheaper trade.
Here is the trade almost no one prices correctly. You depend on an open-source component. It does 95% of what you need. So an engineer opens the source, makes the change, and ships the patched build. Job done, cost recorded as roughly zero.
That zero is the mistake. You didn't make a change. You opened a liability with a recurring payment schedule, and the first invoice arrives at the next upstream release.
Why is a private fork more expensive than it looks?
Follow the mechanism. Upstream keeps moving: security fixes, feature work, refactors that quietly shift the ground your patch stands on. Your deviation doesn't move with it. So at every release you face the same chore: rebase the patch onto the new tree, discover what upstream changed underneath it, resolve the conflicts, and re-test the whole thing to prove your change still does what it did.
Do that once and it's an afternoon. Do it across a dozen releases and it's a standing obligation that never appears on any roadmap. The patch that looked static is actually decaying against a moving target, and the maintenance cost compounds with two things at once: the size of your deviation, and the velocity of the project you forked. The busier and healthier the upstream, the more your private patch costs you to keep, which is a genuinely perverse incentive.
There's a second, quieter cost. The change lives only in your tree. It's documented, if at all, in a commit message and one person's memory. That's bus-factor risk with a fuse on it: the day the person who understands the patch leaves is the day the next rebase becomes archaeology.
The cheaper path is counterintuitive: pay for the thing you could take for free
The alternative sounds like charity and isn't. Instead of carrying the patch privately, you fund the change upstream, either by contributing it and getting it merged, or by paying the people who maintain the project to do it. Both routes have the same effect on your balance sheet. The change stops being yours to carry. It becomes part of vanilla.
Now the mechanism runs in your favour. Once your change is upstream, every future release already contains it. There is no rebase, because there is no deviation. The maintainers who accept the change also inherit the duty to keep it working as the rest of the code evolves, and they test it as part of their own release process, not yours. You've converted a private, decaying liability into a shared, maintained asset, and the marginal cost of keeping it alive drops to nothing you have to schedule.
That's the whole argument in one line: a fork is a tax you pay per release, and an upstream contribution is a one-time cost that turns into free maintenance. For any change you expect to depend on for more than a release or two, the arithmetic isn't close.
The unpriced line item on your dependency risk register
Most supplier-risk reviews ask whether a dependency is maintained, licensed cleanly, and free of known vulnerabilities. Almost none ask the question that actually predicts future cost: how far from vanilla upstream do we sit, and what does each deviation cost us per release?
Distance from upstream is the metric that predicts the bill. Zero distance is cheap and boring. Every deviation is a small recurring bill plus a small slug of key-person risk, and the sum of those is a real number your organisation is paying whether or not anyone has written it down. Making that number visible is the first move in any serious technical strategy for a stack built on open source, because you cannot manage a cost you refuse to name.
Once it's named, the options get sharper. Some deviations are strategic and worth carrying deliberately. Many are accidental, a fix someone made under deadline that could have gone upstream and never did. Those are the ones quietly bleeding you, and they're the ones an upstream-first policy is designed to catch before they calcify.
Why now: cheap forks are the new default
This has always been true. What's changed is the cost of making the mistake. AI-assisted coding has made spinning up a fork close to frictionless. Point a model at a component, describe the behaviour you want, and you have a working private patch in minutes. The barrier that used to make people think twice, the sheer effort of understanding someone else's codebase well enough to change it, is largely gone.
The effort of understanding it well enough to maintain the change forever has not gone anywhere. So the gap between how easy it is to create a deviation and how expensive it is to keep one has widened sharply, and that gap is exactly where unbudgeted cost accumulates. Teams treating AI as a way to move faster on their dependencies should be pairing it with a discipline about where those changes land. Speed without a home for the output is just a faster way to generate liabilities, which is the same trap that shows up whenever a capability outruns its governance.
There's a continuity angle too, and it cuts against the instinct that owning your fork makes you safer. A private patch is safe only as long as the person who understands it stays and the upstream it's pegged to keeps existing. Funding the maintainers of the components you actually ship is a more defensible hedge than either forking or quietly hoping a volunteer sticks around. It keeps the specific projects you depend on funded and staffed, which is worth more to a business than any patch it's carrying alone.
The reflex to fork feels like control. Priced properly, it's usually the more fragile and more expensive option on the table. Pay upstream.
Questions people ask
When does forking an open-source dependency actually make sense?
When the change is genuinely private and you never want it upstream (proprietary behaviour, a temporary hotfix ahead of a merge, or an experiment), or when upstream has refused the change and you've accepted the recurring maintenance cost as a deliberate decision. The test is whether you've priced the per-release rebase-and-retest burden and still judged it worth paying. Forking by accident, under deadline, without that reckoning is the failure mode.
How do you fund a change upstream if the project doesn't take contributions easily?
You have three levers: contribute the change through the project's normal process and shepherd it to merge, sponsor or contract the existing maintainers to prioritise it, or fund a maintainer's time more generally so the project has capacity to review outside work. All three beat carrying the patch alone, because all three end with your change living in vanilla rather than in your tree.
What should a dependency risk review measure that most don't?
Distance from vanilla upstream: how many deviations you carry across your critical components, how large each one is, and what it costs to rebase and re-test per release. That single metric predicts future maintenance cost and key-person risk better than a licence check or a vulnerability scan, and almost no standard review captures it.
Related
- Epic v Google: The App Catalogue Remedy That Hands Rivals the Moat
- Memory Prices Turned. Renegotiate the Supply Contract Before the Next Refresh.
- How AI Makes Bad Bosses Worse: The Agreeability Machine in the Corner Office
- Digital Business
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.