将开源软件视为关键基础设施：软件企业必须补上的一课

现在随便打开一个软件企业的技术栈，从开发工具、CI/CD部署流水线到媒体处理堆栈、网关入口层再到内部平台，几乎找不到没有开源软件的角落。这与云原生开源治理息息相关。这与开源资助策略息息相关。这与企业开源管理息息相关。这与开源供应链风险息息相关。这与开源项目健康度息息相关。这与软件公司息息相关。这与开源软件息息相关。这是软件公司的重要体现。这种依赖其实由来已久，但真正发生变化的是：随着软件企业对开源的依赖程度越来越深，所有压力都开始集中到了项目背后那寥寥无几的维护者身上。

北京心玥科技在为上百家软件企业提供云原生和数字化转型服务的过程中，最深的一个感受就是：开源早已不是“可选的免费工具”，而是真正支撑软件企业业务运转的关键基础设施。但绝大多数软件企业，还在用对待“免费赠品”的方式对待它。

本文基于我们与CNCF指导委员会成员Kat Cosgrove、Buoyant联合创始人兼CEO William Morgan的深度对话，探讨当前开源项目面临的生存危机，以及依赖开源的软件企业该如何建立更负责任、更可持续的使用方式。

开源生态的致命问题：单向消费

现在整个开源行业都面临一个非常严峻的“单向消费”困局。绝大多数软件企业对开源的使用，本质上还是一笔只进不出的交易：公司拉取软件包，基于它构建自己的商业产品，遇到问题就提交issue，然后就理所当然地等着维护者来解决。

但很少有软件企业会反过来为这些项目贡献代码，更不用说提供资金支持了。很多我们每天都在使用的、家喻户晓的开源项目，至今仍然是由少数志愿者在业余时间维护。抛开公平性不谈，这种模式对于依赖这些项目的软件企业来说，本身就是一颗随时可能爆炸的定时炸弹。

三个真实案例，看清开源的真正风险

过去两年发生的三件事，给所有依赖开源的软件企业敲响了警钟。它们清晰地告诉我们：开源风险从来都不只是代码质量或者CVE漏洞那么简单，真正致命的风险，永远来自代码背后的人——以及他们还能不能继续把这个项目做下去。

Ingress-NGINX：核心组件的突然退休

Ingress-NGINX是什么？它是Kubernetes生态中最主流的入口控制器，超过半数的云原生环境都在直接依赖它。但就是这样一个堪称“云原生基石”的项目，却在2025年11月被CNCF宣布进入退休阶段：最佳努力维护将持续到2026年3月，之后不会再有任何新功能发布、错误修复，甚至连安全更新都会彻底停止。

退休公告里最扎心的一句话是：这个项目从头到尾，只有两个人在工作之余和周末进行开发维护。

“有两个人负责维护着全球一半云原生环境都离不开的东西，但没有任何一家公司愿意站出来帮他们一把。”Kat Cosgrove的这句话，道尽了开源维护者的无奈，也暴露了整个行业的短视。这绝不是什么边缘案例，而是整个开源生态治理和人员配置的系统性失败。

FFmpeg：差点停摆的全球音视频基石

FFmpeg的名字可能很多非技术人员没听过，但你每天刷的短视频、看的在线电影、听的音乐，几乎都离不开它。这个项目支撑着全球数十亿人的音视频体验，但在2024年，它也曾一度走到了难以为继的边缘。

当时FFmpeg的维护者公开警告，项目的开发速度已经无法维持，现有的人力和资金根本撑不起这么大的工作量。幸运的是，德国国家科技基金及时出手，成为了FFmpeg的首个政府赞助商，才让这个项目转危为安。直到今天，FFmpeg的开发者文档首页，仍然用醒目的文字提醒所有用户：请支持你所依赖的开源项目，这样它们才能继续活下去。

“我们现在已经把软件供应链的安全分析做得非常好了，但对于资助这些项目的人来说，也需要一套类似的评估体系。这个项目是在蓬勃发展？还是在勉强生存？它还有没有未来？”William Morgan的这个问题，值得每一个软件企业IT领导者深思。

Flux：当公司倒闭，开源项目该何去何从

2024年1月，Flux的创始公司Weaveworks突然宣布关闭，这个被广泛使用的GitOps工具的未来瞬间蒙上了阴影。很多已经把Flux深度集成到自己部署流程中的软件企业，一下子慌了神。

但好在仅仅两个月后，ControlPlane等多家专注于云原生的公司联合宣布，将接手Flux的持续维护和开发工作。截至2026年2月24日，Flux已经顺利发布了2.8版本，项目重新回到了健康的发展轨道。

这个案例告诉我们：开源项目的经济问题不是一次性就能解决的，但只要维护者能获得稳定的支持、连续的发布保障，以及上游代码库的商业化路径，即使经历重大变故，项目也能重新站稳脚跟。

“任何有责任心的公司，都应该主动关注自己依赖的开源项目的健康状况。如果发现某个依赖项已经出现了不健康的迹象，哪怕每周派一两个工程师花几个小时帮忙贡献代码，也比最后项目停摆了再手忙脚乱地迁移要好得多。”Kat Cosgrove建议道。

仅凭安全可见性，远远不够

现在很多软件企业都已经建立了软件供应链安全体系，会用OpenSSF Scorecard给开源项目做自动化安全评分，用OpenSSF重要性评分识别生态关键项目，用SLSA规范来保障制品完整性。这些工具确实帮我们解决了很多安全问题，但它们有一个共同的致命盲区。

它们回答不了这些最关键的问题：

- 这个项目是谁在资助？资金能维持多久？

- 目前有多少活跃的全职维护者？

- 有没有一家雇主为整个项目的发布流程负责？

- 项目的开发节奏是否健康？有没有陷入停滞？

- 如果上游维护团队集体 burnout，有没有商业支持的替代方案？

因此，软件企业必须在现有的安全审查之外，增加一项开源项目健康审查。安全审查只能告诉你“这个代码现在有没有漏洞”，而健康审查才能告诉你“这个项目明天还能不能用”。只有提前发现项目的脆弱性，才能在问题还能解决的时候采取行动。

一个简单有效的内部健康审查，可以从这几个维度入手：

1. 维护者团队的深度和雇主多样性（避免单一公司或个人掌控整个项目）

2. 过去12个月的稳定发布节奏

3. 重大bug和安全问题的平均修复时间

4. 项目治理是否清晰，有没有明确的路线图和负责人

5. 是否有可用的商业支持、官方捐赠渠道或基金会背书

6. 如果项目突然停滞或关闭，软件企业的迁移成本和周期是多少

制定你的开源管理行动计划

领导者不需要给所有依赖的开源项目平均捐钱，但也不能再抱着“生态系统会自己调整好”的侥幸心理。一个明智、可落地的开源管理计划，应该遵循分级治理的原则：

1. 按运营重要性给依赖项排名，而不是按包的数量。一个支撑核心交易系统的依赖，比一百个无关紧要的工具包重要一万倍。

2. 把项目健康检查纳入标准审查流程，和安全风险、许可证风险放在同等重要的位置。

3. 为核心依赖预留上游贡献时间。对于那些直接影响收入、系统正常运行时间和客户数据安全的项目，安排工程师定期贡献代码、修复bug，这是性价比最高的投资。

4. 为关键项目购买商业支持或直接资助。用少量的资金换取稳定的版本发布和长期维护，远比最后出了事故再付出高昂的停机成本划算。

5. 提前制定迁移预案。对于那些已经表现出明显困难的项目，尤其是替换成本很高的核心组件，尽早开始技术储备和迁移规划，不要等到最后一刻。

把开源当成“免费的库存”随便拿，是过去几十年软件企业养成的坏习惯。但在今天，这个习惯已经越来越难以为继了。

未来的开源生态会自然分化：有些项目会因为基金会、大厂商和社区的持续投入而保持健康；有些项目需要更多软件企业的直接支持才能活下去；还有一些项目会不可避免地进入退休阶段，而迁移的成本，最终会落在那些一直指望“别人来维护”的软件企业身上。

真正的问题从来都不是“我们要不要用开源”，而是：我们是否真正了解自己依赖的每一个开源项目的健康状况？我们是否愿意在警告变成停机之前，主动付出一点代价，去维护这个我们所有人都赖以生存的基础设施？

北京心玥科技一直认为，健康的开源生态是所有科技软件企业共同的财富。我们不仅自己积极参与开源社区的贡献，也帮助很多客户建立了完善的开源治理体系。只有当更多软件企业把开源视为需要共同守护的关键基础设施，而不是免费的午餐，整个行业才能实现真正的可持续发展。