Key points
- Packages with company-specific patches had a median update effort three times higher than those without.
- Most updates took four hours or less, but complex cases required days or months of remediation work.
- Familiarity with the programming language did not reduce the time needed to learn the specific package.
Google’s internal case study reveals that maintaining copies of open source software requires significant engineering effort, particularly when organizations apply local modifications. According to Help Net Security, the study titled “How much does it cost to maintain a copy of an open source software package (at Google)?” highlights that most updates should take four hours or less. However, packages with company-specific patches saw a median update effort three times greater than unpatched packages.
How it unfolded
- Google tracked engineering effort for 54 package updates between April and December 2024.
- Researchers surveyed employees to identify factors causing delays in the update process.
- Analysis showed that local modifications, dependencies, and repairs drove the additional workload.
Who is affected
System administrators and engineering teams managing internal copies of open source packages face increased maintenance burdens when they customize software. The study found that the median total effort was 2.2 engineering hours, while the average was 13.9 hours. One specific update required an estimated 400 hours of work. Employees identified patches and customization as the leading causes of additional work, as engineers must adapt changes and resolve compatibility problems when adopting new versions.
Larger numbers of external dependencies and upstream contributors were associated with greater update effort. Activity in the original project’s repository also showed a relationship with the effort required. Conversely, the timing of previous updates, version installations, and internal usage levels showed no consistent relationship with update complexity. This suggests that the structural complexity of the package and its dependencies matters more than how often it is updated or how widely it is used internally.
Sophia Vargas of Google Open Source explained that for updates taking more than two days, the majority of time was spent on remediation. This work involves resolving downstream dependency issues and repairing breakage in applications or components that rely on the package. Engineers must repair these affected areas before the update can be considered complete, adding significant overhead to the initial patching process.
Notably, in 52 of the 54 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 package-specific knowledge, learning enough to begin the work took less than an hour on average. This indicates that the barrier to entry is low, but the execution complexity remains high due to customization and dependency management.
What happens next
Organizations adopting open source software as a cheaper alternative to proprietary development must account for these hidden engineering costs. The data suggests that avoiding unnecessary local modifications can significantly reduce maintenance time. Teams should evaluate the trade-off between customization benefits and the increased effort required to merge future upstream updates. Without a strategy to manage dependencies and patches, update cycles can expand from hours to months.
What to do and how to stay safe: Google
- Audit internal repositories to identify packages with company-specific patches that may complicate future updates.
- Monitor the number of external dependencies for critical packages to anticipate higher update effort.
- Establish a process for evaluating whether customizations are necessary or if upstream features suffice.
- Track engineering hours spent on remediation to identify patterns in complex update cycles.
Step-by-step guide: Mobile Device Security for Small Business: Control Without Cost
General security guidance from the Circuit Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
How much longer do patched packages take to update?
Packages with company-specific patches had a median update effort three times that of packages without patches.
What causes the most delay in open source updates?
Employees identified patches and customization as the leading cause of additional work, along with dependency issues.
Does familiarity with the code reduce update time?
Engineers unfamiliar with the package but familiar with the language took less than an hour to learn enough to begin.
