Google study reveals open source update costs driven by custom patches
Google’s internal audit shows that local modifications and dependency repairs significantly increase the engineering hours required for open source maintenance.
Key points
- Custom patches triple the median engineering effort for open source updates.
- Most updates take under four hours, but complex cases require up to 400 hours.
- Familiarity with the programming language does not reduce the time to understand specific packages.
Google tracked the engineering effort involved in fifty-four package updates between April and December 2024, according to a report by Help Net Security. The tech giant analyzed these updates to quantify the labor required for routine software maintenance within its infrastructure, as detailed in its case study on open source package maintenance costs.
The study indicates that the median total effort for these updates was 2.2 engineering hours, while the average effort reached 13.9 hours, Help Net Security reported. Most updates required four engineering hours or less to complete. However, a single update demanded an estimated 400 hours of work, highlighting the significant variance in maintenance complexity across different software components.
What drives maintenance complexity?
Company-specific patches emerged as the primary factor increasing update duration, according to the Google case study titled “How much does it cost to maintain a copy of an open source software package (at Google)?” Among forty-seven packages with usable patch-detection results, those containing custom modifications had a median update effort three times higher than unmodified packages.
Employees surveyed identified these patches and customizations as the leading causes of additional workload, Help Net Security noted. When organizations modify their copies of open source packages, engineers must carefully account for those changes when adopting new upstream versions. This process often requires adapting existing patches and resolving compatibility problems that arise from the new codebase.
Larger numbers of external dependencies and upstream contributors were also associated with greater update effort, the study found. Activity levels in the original project’s repository showed a clear relationship with the labor required. However, the timing of previous updates, version installation dates, and internal usage levels showed no consistent relationship with update complexity.
Impact on engineering teams
Sophia Vargas from Google Open Source explained that for updates taking more than two days, the majority of time was spent on remediation work, according to Help Net Security. This remediation involves resolving downstream dependency issues and repairing breakage caused by the update. An update can affect applications and other components that rely on the package, requiring extensive repairs before the update is considered complete.
The study also highlighted the learning curve associated with maintenance tasks, Help Net Security reported. In fifty-two of the fifty-four updates, engineers were very familiar with the programming language but completely unfamiliar with the specific package and its internal usage at Google. Despite this lack of specific knowledge, learning enough to begin the update took less than an hour on average.
What should you do?
Organizations should audit their open source dependencies to identify packages with extensive local modifications, as these will require disproportionate engineering effort during updates. Security teams should prioritize maintaining a clear record of all custom patches to streamline the adaptation process when new upstream versions are released.
What to do and how to stay safe: Google
- Inventory all internal open source packages to identify those with significant local modifications or custom patches.
- Document all custom changes and dependencies to reduce the time required for future version updates.
- Monitor upstream repository activity for critical packages to anticipate potential compatibility issues.
- Allocate additional engineering resources for packages with high dependency counts or complex integration points.
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
How much time does a typical open source update take at Google?
The median effort was 2.2 engineering hours, with most updates taking four hours or less, according to the study.
What makes some open source updates take significantly longer?
Custom patches, local modifications, and resolving downstream dependency issues are the main drivers of increased effort.
Does familiarity with the programming language help speed up updates?
Engineers were often unfamiliar with the specific package but could learn enough to begin in under an hour on average.
