Open source software runs through nearly every major codebase. Estimates put its presence above 90% in commercial projects. Companies grab it because the download costs nothing. Yet the phrase heard in developer circles holds: it is free as in puppies, not free as in beer.

Once adopted, the work begins. Engineers spend time keeping copies current, applying patches, and handling the surprises that arrive with new versions. Google Open Source Blog published fresh research on exactly how many of those hours add up inside a large organization. Sophia Vargas led the effort. Her team examined both internal data and engineer surveys to measure the real expenditure of using, not just maintaining, thousands of open source packages.

The findings land with force. Most updates take four hours or less. Simple enough. But a long tail stretches into days or even months. That variance matters. It turns a predictable expense into something harder to forecast and budget.

Vargas and her colleagues asked two direct questions. How long does it take an engineer who is not an upstream maintainer to update a package at Google? And can standard complexity metrics predict the effort involved?

They combined two approaches. One drew from Google’s Dependency Dashboard Cohort, a set of 54 packages tracked for updates. The other came from a survey of Google engineers who regularly handle third-party code in the company’s massive monorepo.

Results from the tracked cohort showed half the updates finished in two hours or less. The survey echoed this pattern. Roughly 31% of respondents reported updates taking two hours or less. Yet the full picture includes outliers. Average total time across phases reached nearly 14 hours. Median sat at 2.2 hours. The gap reveals how a few stubborn cases pull the mean higher.

They broke the work into three phases. Onboarding a new package averaged 0.4 hours. The update itself took 5.4 hours on average. Remediation, the work to fix breaks and adjust local code, demanded 9.4 hours on average. Some remediation efforts stretched to 280 hours. One case hit 400 hours total. Those numbers come straight from the full research report released alongside the blog post.

Customization drives much of the pain. Local patches and modifications complicate merges when upstream changes arrive. Packages with more dependencies also demand extra attention. The number of upstream contributors proved predictive too. More active communities sometimes ease updates. Sometimes they introduce conflicting changes. Package age and internal usage across teams showed weaker correlation with effort.

But. The data makes one outcome plain. Heavy customization turns routine updates into major projects. Teams that fork heavily or add extensive local changes pay for that choice later. In engineering hours. In delayed feature work. In occasional production headaches.

This Google study arrives at a moment when other recent analyses highlight similar tensions. A Linux Foundation survey of more than 500 IT leaders, covered by GCN in August, found that organizations treating open source as truly free face hidden replacement costs reaching $3.5 million per company. That figure represents what it would take to rewrite or buy proprietary substitutes. Meanwhile, companies that actively contribute see returns up to 5x their investment. The top 100 contributors between 2018 and 2025 generated $23.2 billion in benefits from $3.9 billion spent, a roughly 6x return.

Passive consumption carries its own price. Nearly half the surveyed leaders build internal workarounds for missing features, at an average annual cost of $670,000. Maintaining private forks eats another 5,160 labor hours, or about $258,000, per release cycle. These numbers align with Google’s internal observations. The effort to keep customized versions healthy accumulates.

Self-hosted open source tools show comparable patterns outside Google. An analysis on Ravoid compared error tracking and analytics tools. Self-hosted Sentry for a 15-engineer team ran roughly $9,500 per year once server, setup, upgrades, and one major incident were factored. The SaaS version came in under $2,200. Plausible analytics told a similar story. The open source route required ongoing upgrade time that pushed total ownership higher than the hosted alternative in the example.

These comparisons do not argue against open source. They illustrate that license cost is only the start. Infrastructure, integration, security patching, and staff time fill the rest. For NGOs the redistribution of costs can feel especially heavy. A July report discussed on ICTworks noted that coordination demands around open source sometimes match or exceed commercial license prices for resource-constrained groups.

Recent coverage on ZDNet also touched the willingness to pay. In “7 open-source apps worth paying for in 2026”, Jack Wallen explained that while most open source remains free, certain tools deliver enough value that one-time purchases make sense. The piece underscores a maturing view. Free code still carries operational weight. Some users choose to support developers directly to reduce their own maintenance burden.

Google’s research adds a practical layer. Complexity metrics based on local changes, dependency count, and upstream activity offer better signals than simple age or popularity. Teams can use these signals to forecast effort. They can decide when to reduce custom patches. Or when to contribute changes upstream to ease future updates.

Engineers with deep upstream experience update faster. That finding repeats across the survey responses. Knowledge of the original project smooths the process. Yet even experts encounter cases that stretch for months. Variation remains the rule.

The study carries limitations. It focuses on one company’s environment, with its particular tooling and monorepo practices. Results may differ for smaller organizations or different languages. Remediation time in the tracked cohort often reflected work on downstream systems rather than the package itself. Still, the patterns hold enough weight to inform broader practice.

So companies now face clearer data. Open source delivers enormous value. The supply-side cost to build widely used components sits around $4.15 billion, while the demand-side replacement value reaches trillions. That gap fuels innovation. But the hourly work to keep it running cannot be ignored.

Teams that treat dependency management as core engineering work, rather than side tasks, reduce long-term expense. They limit transitive dependencies. They favor actively maintained projects. They track customization debt. And they contribute back when it makes strategic sense.

The Google analysis, released just yesterday, gives technology leaders fresh numbers to bring into budgeting conversations. Four hours for many updates sounds manageable. Multiply across thousands of packages and hundreds of engineers. Add the occasional multi-month project. The total becomes material.

Free as in puppies indeed. The adoption is easy. The care over years demands attention, resources, and deliberate choices. Organizations that understand those hours position themselves to capture the full advantage of open source while controlling the costs that arrive after the download.