谷歌把自己当成样本，算了一笔开源的账：在内部维护成千上万个开源软件包，究竟要耗掉多少软件工程小时。答案分成两半------绝大多数包的更新在 4 小时以内就能完成，但那条长尾能拖到数天，甚至数月才真正落地。
长尾才是谷歌开源团队真正想弄清楚的地方。值得一提的是，研究社区过去更多考察的是「维护」一个开源项目本身的持续成本；谷歌要回答的却是另一个问题------在企业内部「使用」数千个开源包，到底需要多少资源。他们把研究拆成两问：RQ1，一个并非上游维护者的工程师，在谷歌内部升级一个开源软件包需要多久；RQ2，复杂度指标能否预测升级的相对工作量。
企业为什么值得算这笔账？因为开源包在企业里的数量往往以千计，每一个都要在依赖更新、安全补丁和上游破坏性变更之间保持同步。这份「跟版」工作分散在大量工程师身上，通常不进采购单、也不出现在预算表里，但它是实打实的人力支出。
背景数字值得重读：有估计认为，超过 90% 的代码库里都含开源代码。多数团队选开源的理由是「免费」------不必自研一套专有替代品，自然更省钱。可社区那句老话点破了幻觉：「开源是像小狗那样免费，不是像啤酒那样免费。」把项目领回家只是开始，之后要喂、要遛、要看病。你或你的组织一旦采用某个开源项目，就得持续投入工程时间等成本，确保手里这一份既健康、又跟得上上游。
真正有信息量的是那些预测因子。研究显示，不同指标的预测力差别很大：
更管用的指标------本地补丁与定制化程度、包的依赖数量、上游贡献者数量。
不太管用的指标------包的年龄、内部有多少个团队在用这个包。
换句话说，一个包「老不老」、「内部用得多不多」，都说明不了升级它费不费劲。麻烦往往来自你为了让它在自家环境里跑起来所做的改动：本地补丁越多、定制越深，跟进上游新版本就越贵。定制本身就是一个成本项。这也解释了为什么有些把开源包嵌进自有系统并做过大量二次开发的团队，宁可长期停在旧版本上。
谷歌也主动列出了这项研究的局限，对准备自建开源治理流程的团队有参考价值：
-
抽样基于业务优先级。为了不影响工程排期，研究尽量只用现有数据、少做新采集；
-
没有规定升级过程中能用什么工具，包括带生成式 AI 的功能，因此无法评估任何特定工具的影响；
-
数据明显偏向 Go 语言，样本多样性不足，无法比较不同语言生态的差异；但其他内部工作显示，语言可能显著影响维护工作量；
-
只覆盖活跃项目，对停滞或归档的包没有收集多少数据。
完整报告的标题很直白：《How much does it cost to maintain a copy of an open source software package (at Google)?》，也就是「在谷歌，维护一份开源软件包副本要花多少钱」。
对中国团队来说，这份数据的价值在于把「开源等于零成本」的默认假设拆开来看：选型时除了许可证和社区活跃度，还得掂量自己会打多少本地补丁、会拉进多少依赖，以及后续跟版的人力预算。免费领回来的那只「小狗」，养起来才是账单。