开源软件已渗透至几乎所有主流代码库，估计在商业项目中的占比超过90%。企业青睐开源往往因其下载零成本，但开发者圈流传着一句名言：开源像小狗一样“免费”（意指需精心照料），而非像啤酒一样真正免费。
一旦采纳，维护工作便随之而来。工程师需花费大量时间保持副本更新、应用补丁并处理新版本带来的意外。Google开源博客发布的最新研究详细揭示了大型组织内部这些工时的累积过程。由Sophia Vargas领导的团队结合内部数据与工程师调查，衡量了使用数千个开源包的真实开销，远超单纯的维护成本。
更新耗时：中位数与平均值的巨大鸿沟
研究结果引人深思。虽然大多数更新耗时在四小时以内，看似简单，但长尾效应可延伸至数天甚至数月。这种差异将原本可预测的费用转化为难以预算的项目风险。
Vargas团队重点考察了两个问题：非上游维护者的工程师更新一个包需要多久？标准复杂性指标能否预测所需精力？通过追踪Google“依赖项仪表板队列”中的54个包，并结合经常处理第三方代码的工程师调查，数据呈现出明显分化：
- 一半的更新在两小时内完成，31%的受访者反馈耗时两小时或更少。
- 然而，各阶段平均总时间接近14小时，中位数仅为2.2小时。
- 这一差距表明，少数顽固案例大幅拉高了平均值。
工作被划分为三个阶段：引入新包平均耗时0.4小时；更新本身平均5.4小时；修复阶段（修复破坏及调整本地代码）平均需9.4小时。极端情况下，修复工作长达280小时，个别案例甚至达到400小时。
定制化：隐性成本的主要推手
定制化是造成痛点的主因。当上游变更到来时，本地补丁和修改使合并变得复杂。依赖项更多的包需额外关注，上游贡献者数量也具有预测性：活跃社区有时简化更新，有时却引入冲突。相比之下，包的年龄和跨团队内部使用情况与工作量的相关性较弱。
数据明确显示，重度定制会将例行更新演变为重大项目。严重分叉或添加大量本地更改的团队，将在后期付出高昂代价，表现为工程工时增加、功能开发延迟乃至生产环境故障。
行业视角：隐性成本与投资回报
Google的研究并非孤例。Linux基金会针对500多名IT领导者的调查显示，将开源视为真正免费的组织，面临高达每家350万美元的隐性替代成本，相当于重写或购买专有替代品的费用。与此同时，积极贡献的公司回报可达投资的5倍。2018年至2025年间，排名前100的贡献者从39亿美元支出中获得了232亿美元利益，回报率约6倍。
被动消费代价同样沉重。近半数受访领导者为缺失功能构建内部变通方案，年均成本67万美元；维护私有分叉在每个发布周期消耗5,160个劳动小时，约合25.8万美元。这与Google的内部观察一致：保持定制版本健康的工作量正在不断累积。
在Google之外，自托管开源工具也呈现类似模式。Ravoid分析指出，对于15人工程师团队，综合考虑服务器、设置、升级及事故处理，自托管Sentry年成本约9,500美元，而SaaS版本低于2,200美元。Plausible Analytics的案例也显示，开源路线因持续升级时间投入，总拥有成本高于托管替代方案。
策略建议：将依赖管理视为核心工程
这些比较并非反对开源，而是强调许可成本仅是起点。基础设施、集成、安全补丁及人员时间构成了其余部分。对于资源受限的组织，协调需求有时等于甚至超过商业许可价格。
Google研究提供了实用视角：基于本地更改、依赖项数量和上游活动的复杂性指标，比简单的年龄或流行度更能预测工作量。团队可利用这些信号决定何时减少自定义补丁，或何时将更改贡献给上游以简化未来更新。
拥有深厚上游经验的工程师更新速度更快，对原始项目的了解能使过程更顺畅。尽管专家也会遇到耗时数月的极端案例，但变化仍是常态。该研究虽局限于Google特定的单体仓库环境，但其模式足以指导更广泛的实践。
当前，构建广泛使用组件的供应端成本约为41.5亿美元，而需求端替代价值达数万亿美元。这一差距推动了创新，但维持运行的每小时工作不容忽视。将依赖项管理视为核心工程工作、限制传递性依赖、倾向积极维护项目并战略回馈贡献的团队，能有效降低长期开支。
Google的最新分析为技术领导者提供了新的预算依据。许多更新只需四小时，看似可控，但当涉及数千个包和数百名工程师时，数字将被放大。加上偶尔的多月级项目，总额变得显著。确实如“像小狗一样免费”：采纳容易，但多年的照料需要关注、资源和深思熟虑的选择。理解这些工时的组织，才能在控制下载后成本的同时，充分捕捉开源的全部优势。