Many organizations adopt open source software because they see it as a cheaper alternative to proprietary development. Maintaining it, however, still requires engineering effort, according to Google’s case study, “How much does it cost to maintain a copy of an open source software package (at Google)?”
Study suggests that most updates to its internal copies of open source packages should take four engineering hours or less. More demanding updates can require days or months of effort, with local modifications, dependencies, and repairs to affected software contributing to the workload.
Google tracked the engineering effort involved in 54 package updates between April and December 2024. It also surveyed employees about the factors that make updates take longer.
Local changes create recurring work
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. The average effort was the same for both groups. Employees identified patches and customization as the leading cause of additional work.
In your experience, what characteristics of an OSS package or the update process make it take longer than average? (Source: Google)
When a company modifies its copy of an open source package, engineers must account for those changes when adopting a new version. They may need to adapt the patches and resolve compatibility problems.
Larger numbers of external dependencies and upstream contributors were associated with greater update effort. Activity in the original project’s repository showed a relationship with effort. The timing of previous updates and version installations, along with internal usage levels, showed no consistent relationship with update complexity.
Repairs drive lengthy updates
The median total effort was 2.2 engineering hours, while the average was 13.9 hours. One update required an estimated 400 hours.
“For updates that took more than 2 days, the majority of time was spent on remediation,” Sophia Vargas, Google Open Source, explained.
That work involves resolving downstream dependency issues and repairing breakage. An update can affect applications and other components that rely on the package, requiring repairs before the update is complete.
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.
Google’s setup limits broader conclusions
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.
Google generally maintains one version of each imported package in its internal repository. Its tools and processes influence maintenance effort, including the work required to repair affected software.
The study did not prescribe which tools engineers could use or evaluate the impact of individual tools, including generative AI. Stale and archived packages received limited coverage.
Must read:
Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
