A new case study from Google offers a rare, numbers-driven look at what it really takes to keep internal copies of open source packages current. The work tracked 54 package updates between April and December 2024 and surveyed the engineers doing the work. The headline finding: company-specific patches roughly tripled the median engineering effort, and the worst-case update consumed an estimated 400 hours.
The data challenges the casual assumption that open source equals cheap. Pulling in someone else's code still costs real engineering time, especially when the package has been bent out of shape to fit internal needs.
What the study actually measured
Sophia Vargas of Google Open Source explained that for updates stretching beyond two days, most of the time went into remediation. That means fixing downstream dependencies and repairing other software that broke because of the new version. The median effort of 2.2 hours sounds comfortable, but the 13.9-hour average—and that 400-hour outlier—tell a more honest story.
Engineers in 52 of 54 cases were very familiar with the language but had never worked with the package before. Learning the package averaged under an hour. The work itself was the grind.
What inflates the cost
Three factors stood out in the research:
- Company-specific patches.** Internal modifications force engineers to reapply and re-test custom changes on every new upstream version.
- External dependencies and upstream contributor activity.** The busier and more tangled the project, the more downstream breakage to chase.
- Remediation work.** The time spent fixing other applications affected by the upgrade often dwarfs the upgrade itself.
Stale and archived packages got limited attention, and the study did not look at generative AI tools, so it offers no verdict on whether AI shrinks the workload. Google's internal tools and processes clearly shape the effort too, but the study deliberately did not isolate their effect.
Why this matters
The story matters because most large companies, and plenty of smaller ones, run internal forks of open source code. Every fork is a future tax. The longer a patch lives, the heavier it gets when the next version lands. That is also a security story: a package that is painful to upgrade is a package that gets skipped, and skipped upgrades turn into known vulnerabilities that linger in production.
Our analysis
The ratio that should worry security teams is not the median—it is the tail. A handful of stragglers with local modifications, complex dependencies, and downstream breakage can quietly absorb weeks of engineering time per quarter. That is engineering time not spent on new features, threat hunting, or incident response. It is also the package most likely to be left behind the next time a CVE drops, because nobody wants to touch it.
Compared with the usual narrative—"just update faster"—the study points the other way. The bottleneck is rarely the patch itself. It is the integration cost around it, which is exactly where defenders lose the most time during a vulnerability disclosure.
Who should care
| Role | Why it matters |
|---|---|
| Security teams | Hard-to-upgrade forks become forgotten vulnerabilities. Patch debt compounds. |
| Engineering managers | A few "400-hour monsters" can distort quarterly resource allocation. |
| DevSecOps | Dependency repair is invisible work until it blocks a release. |
| Finance | Open source "savings" need to account for long-tail maintenance costs. |
What to watch next
Watch whether Google or other hyperscalers publish follow-up data on AI-assisted maintenance. If the 13.9-hour average drops sharply, expect the industry to follow. Also worth watching: how many of those 400-hour monsters were driven by old, unmaintained forks. Those are the same forks sitting in your environment, waiting for the next CVE.
Bottom line: open source is free to download and expensive to keep. Plan for it.
Key takeaways
- Company-specific patches are the single biggest driver of open source update cost.
- Average update effort is roughly 6x the median, which means a few painful packages skew the whole picture.
- Security teams should treat hard-to-upgrade internal forks as live risk, not just engineering debt.
Frequently asked questions
Why do company-specific patches make open source updates harder?
Internal changes have to be reapplied and re-tested on top of every new upstream version, which adds work and creates compatibility issues that do not exist for a clean import.
Did Google look at whether AI tools help with these updates?
No. The study explicitly did not evaluate the impact of generative AI or other individual tools on the effort.
How representative are these numbers for other companies?
52 of the 54 packages were Go code chosen for internal business reasons, and Google's tooling shaped the process. Treat the numbers as a benchmark, not a universal rule.
Is the 400-hour update an outlier?
Yes. The median was 2.2 hours and the average was 13.9, so a small number of stragglers pulled the mean up sharply.