SecurityNot yet confirmed elsewhere1 publisher2 min readPublished
Google finds local patches triple the median effort of updating an open-source package
Google measured 54 updates to its internal copies of open-source packages and found a median effort of 2.2 engineering hours. Private patches raise the cost of a typical update in that data, but the longest updates trace to repair work.
The Watch · Security desk
Three figures from Google's case study. Median total effort per update: 2.2 engineering hours. Average total effort per update: 13.9 engineering hours. One update needed an estimated 400 hours.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Median effort per update | 2.2 eng. hours | 6 | |
| Average effort per update | 13.9 eng. hours | 7 | |
| Longest single update (estimate) | 400 hours | 8 |
What happened
- Google's employee survey named patches and customization as the leading cause of extra update work.
- In 52 of the 54 updates the engineers knew the language but not the package, and learning enough to begin took under an hour on average.
- The updates studied were under 1% of Google's package updates in the period, were chosen by internal business priorities, and 52 of the 54 packages were written in Go.
Why it matters
- decision A team weighing a private patch on a dependency has a measured penalty for the typical update on Google's numbers: about triple the median hours of an unpatched copy.
- contradiction Staff survey answers and the medians point at patches. The equal averages and the finding on updates over two days point at remediation.
- cost One 400-hour update would be about 53% of all logged hours if the 13.9-hour average covers all 54, so a single package can decide the budget.
- constraint Google keeps one version of each imported package and did not evaluate tools, including generative AI, so the figures describe its setup; a shop running several versions has less reason to trust the 3x.
The equal averages complicate the patch story. Packages with company-specific patches had triple the median update effort of unpatched ones [3], yet the average effort was the same in both groups [4]. Taken at face value, that puts the unpatched group's mean-to-median ratio at three times the patched group's [18]. The unpatched group, in other words, holds the heavier tail. The study as reported does not give group sizes, and seven of the 54 updates sit outside the comparison [17].
Across all updates the picture is the same shape. The median was 2.2 hours [6] and the average 13.9 [7], a gap of about 6.3 times [16].
Sophia Vargas of Google Open Source described what fills the long updates. "For updates that took more than 2 days, the majority of time was spent on remediation," she said [9]. Remediation means resolving downstream dependency issues and repairing breakage in the applications and components that rely on the package [10].
We think the supportable claim is narrow. Local patches add cost to the typical update, and Google's staff say so. The hours that blow up a schedule went to remediation, according to Vargas, and the averages do not separate patched from unpatched packages.
Two other factors tracked with effort: more external dependencies and more upstream contributors [11]. The timing of previous updates and internal usage levels showed no consistent relationship with update complexity [11].
What to watch
- Whether Google publishes group sizes and the effort distribution for patched and unpatched packages, which would settle the equal-averages puzzle.
- Any follow-up that covers stale and archived packages, which this study covered only thinly.
- Any evaluation of the tools engineers used, including generative AI, which this study did not assess.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap+15
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Google tracked the engineering effort involved in 54 package updates between April and December 2024.
ReportedSupportedSource: Help Net Security, summarizing Google's case study 'How much does it cost to maintain a copy of an open source software package (at Google)?'View cited source - [2]
The study suggests most updates to Google's internal copies of open source packages should take four engineering hours or less.
- [3]
Of the 47 packages with usable patch-detection results, those with company-specific patches had a median update effort three times that of packages without patches.
- [4]
The average effort was the same for both the patched and unpatched groups.
- [5]
Employees surveyed by Google identified patches and customization as the leading cause of additional update work.
- [6]
The median total effort per update was 2.2 engineering hours.
- [7]
The average total effort per update was 13.9 engineering hours.
- [8]
One update required an estimated 400 hours.
- [9]
"For updates that took more than 2 days, the majority of time was spent on remediation," said Sophia Vargas of Google Open Source.
ReportedSupportedSource: Sophia Vargas, Google Open Source, quoted by Help Net SecurityView cited source - [10]
Remediation involves resolving downstream dependency issues and repairing breakage, because an update can affect applications and other components that rely on the package.
- [11]
Larger numbers of external dependencies and upstream contributors were associated with greater update effort; the timing of previous updates and version installations, and internal usage levels, showed no consistent relationship with update complexity.
- [12]
The observed work represented less than 1% of Google's package updates during the collection period, updates were selected according to internal business priorities, and 52 of the packages were written in Go.
- [13]
Google generally maintains one version of each imported package in its internal repository, and its tools and processes influence maintenance effort.
- [14]
The study did not prescribe which tools engineers could use or evaluate the impact of individual tools, including generative AI, and stale and archived packages received limited coverage.
- [15]
In 52 of the 54 updates, the engineers were very familiar with the programming language but completely unfamiliar with the package and how it was used inside Google; learning enough to begin took less than an hour on average.
- [16]
The average update effort (13.9 hours) is about 6.3 times the median (2.2 hours).
- [17]
Seven of the 54 tracked updates fall outside the patch comparison.
- [18]
If the patched median is three times the unpatched median and the means are equal, the unpatched group's mean-to-median ratio is three times the patched group's.
- [19]
If the 13.9-hour average covers all 54 updates, the 400-hour update accounts for about 53% of all hours logged.
Sources
1 independent publisher whose own reporting we read for this story.
- helpnetsecurity.comWhat makes some open source updates so difficult?
1 article · October 11, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.