
ALT Google Open Source Research card 01/04: "How Much Does It Cost to Use Open Source Software?" Subheadline: "Open source is 'free as in puppies, not free as in beer.' Beyond upstream maintenance, we studied the engineering effort required to use and update OSS packages at Google." Features portrait of Sophia Vargas, Google Open Source, with two bullets: "Evaluates software engineering hours required to update OSS packages within Google" and "Shares observational findings, complexity indicators, and study limitations." Study Overview box: "How long do package updates take—and which metrics predict relative effort?" Footer: Inside the post: Research questions, update complexity observations, study scope, and limitations. goo.gle/cost-of-oss

ALT Google Open Source Research card 02/04: "What the Study Examined & Observed in Practice." (1) RQ1 — How Long Do Package Updates Take? (<= 4 Hours vs. Long Tail): "We evaluated how long it takes an engineer (not an upstream maintainer) to update an OSS package at Google: most take 4 hours or less, while a long tail takes days to months." (2) RQ2 — What Predicts Update Complexity? (Stronger Effort Indicators): "Results suggested local patches and customization, number of package dependencies, and number of upstream contributors were better indicators of update complexity than other metrics evaluated." (3) Observed Comparison — Package Age & Internal Usage Profile (Inconclusive Results): "Analysis did not yield any conclusive results regarding package age or how many teams were using that package internally. While upstream breaking changes can significantly impact update complexity, this was not detectable by package age or version alone."

ALT Google Open Source Research card 03/04: "Survey Context & Study Limitations." Top callout: "2024 Employee Survey Chart (346 Respondents): Top-Ranked Characteristics Making Updates Take Longer — 1st: Google-specific patches or customization (49%); 2nd: Upstream breaking changes (37%); 3rd: Google breaking changes (31%)." Four-box grid of study limitations: (1) Business Priority Sampling: Designed around existing data to minimize the impact to engineering roadmaps. (2) Did Not Dictate Tooling: Did not specify tools (including genAI features) or isolate specific tool impacts. (3) Sample Bias Towards Go: Data had significant bias towards Go; future studies encouraged on language ecosystems. (4) Only Active Projects: Focused on active packages.

ALT Google Open Source Research card 04/04 for X/Twitter (@GoogleOSS): "Explore the Approach & Full Research Report." Top box ("What's in the Blog Post & Research Paper"): Author Sophia Vargas (@sophia_iv), Google Open Source; Paper: "How much does it cost to maintain a copy of an OSS package?"; Contents: Study design and overview of topline results; Scope: Observational study of internal OSS package updates. Middle box ("Research Questions Explored"): 1. RQ1: How long does it take for an engineer (not an upstream maintainer) to update an open source software package at Google? 2. RQ2: Can complexity metrics predict the relative effort or amount of time required to update a package at Google? CTA: First reply below: https://goo.gle/cost-of-oss

ALT Stage photo from the Maintainer Roundtable at AGNTCon + MCPCon Europe in Amsterdam. Five speakers sit on black chairs beneath a wall-mounted screen titled "Maintainer Roundtable" displaying circular headshots and logos for Gartner, Anthropic, Solo.io, Google, and OpenAI. From left to right: moderator Nitish Tyagi (Gartner) speaking into a handheld microphone, David Soria Parra (Anthropic), Idit Levine (Solo.io), Kuba Herczyński (Google), and Nick Cooper (OpenAI).













