你的开源技术栈也有一个「董事会」,却从没人对它做尽职调查
Linux 6.15 终止了三十年来买家一直默认存在的支持,而承担代价的人从未被征询过意见。企业会对每一家商业供应商做尽职调查,却唯独放过了真正支撑自己基础设施的开源基石。
2025年5月,Linux内核6.15版本发布时,不再支持英特尔486及早期586处理器,终结了一项自上世纪90年代初就存在、却从未被写进任何正式文件的兼容性默契。官方给出的理由很务实:维持这些芯片所需的仿真代码占用了维护者本可以用在别处的精力,而且内核邮件列表其实早在2022年就已经公开讨论移除这项支持。单独看,这个理由站得住脚。但请追问一句:谁被征询了意见?那些仍在工业控制器、实验室仪器和早已停产供应商所遗留的嵌入式系统中运行这类芯片的企业,没有收到通知期,没有看到公开的时间表,更没有在讨论中占有一席之地。填补这个空白,正是开源尽职调查该做的事,而几乎没有人真的去做。
你的公司不会在没搞清楚股东背景、资金来源以及利益变化后果的情况下,和一家供应商签一份五年合约。可同一家公司,却会在一个开源平台上构建十年的基础设施,却从不追问一句:掌舵这个项目的组织到底是谁。即便做了尽职调查,通常也只停留在许可证文本上,而许可证只约束你今天能拿这份代码做什么,维护方明天想把代码改成什么样,完全在许可证的管辖范围之外。没人会为一次弃用开发票,但预算里那笔支出,还是会不请自来地出现。
开源项目对你负有向后兼容的义务吗?
没有。路线图、弃用政策和平台支持完全由维护方自行决定,没有商量余地。面对商业供应商,你有通知期、服务水平协议和违约救济;面对上游维护方,你有的只是与你投入的资金和参与度成正比的"影响力",而大多数企业两样都没投入。用治理的语言说,你是一家供应商的"非付费客户",对方对你没有任何义务。这套安排在双方利益恰好一致时运转得很漂亮,问题在于,很多人误把这种利益一致当成开源的固有属性,而它其实只是一个需要持续盯着的巧合。维护方也从来不是什么中立的抽象存在:Linux基金会的白金会员名单,几乎就是芯片厂商、云服务商和设备制造商的花名册,每一家都带着自己的商业算盘,业内其他治理机构的成色大多也差不多。
开源弃用的通知期到底有多长?
维护方的政策写多长,就是多长,一天也不会多。横向比较的结果值得细看,因为跨度大到惊人。最慷慨的例子是Python。PEP 373早在2008年发布时,就把Python 2.7的退役日期定在了2015年;后来社区显然还没准备好,项目方索性把日期顺延到了2020年1月1日。这是超过十年的书面公开预警,期间修订过一次,而且是朝着对用户更有利的方向修订。
另一端是CentOS。企业在2019年采用CentOS 8,依据的是一份比照RHEL、明确写着2029年才到期的生命周期承诺。2020年12月,官方宣布CentOS Linux 8的支持将提前到2021年底结束,资源转投CentOS Stream。用户原本按"还有近十年"来做预算和规划,结果这份承诺缩水到大约十二个月的通知期,所有基于原计划制定的迁移方案,一夜之间提前了七年到期。
Node.js则介于两者之间,教会的道理更微妙。按官方发布计划,Node 16原定于2024年4月停止支持,后来项目方把这个日期提前了七个月,改到2023年9月11日,原因是它底层依赖的OpenSSL 1.1.1库先一步停止维护,没人愿意让一个运行时继续跑在没有安全补丁的加密库上。这份时间表是真实的,维护方也严格履行了自己的流程,但用户还是白白损失了七个月,原因出在另一个维护方的时钟先走完了。
把这些记录摆在内核的案例旁边,规律就很清楚了:通知期是政策选择,不是自然规律。跨度从十年到一年不等,公开日期既可能顺延也可能提前,而你实际拿到的预警期,取决于整条依赖链里最短的那一环。486支持移除算不上什么丑闻,它只是这个区间最靠外的那个数据点。内核硬件支持从来没有正式的生命周期文件,所以唯一存在过的"通知",就是一场几乎没有哪个采购团队会去关注的邮件列表争论。
什么时候是文书工作在制造问题?
还有一种风险正在浮现,需要先说清楚:它与486的移除决定无关,那个决定是工程团队用了好几年时间在公开场合争论出来的。这种新风险在于,"维护负担过重"这种证据,现在可以按需生产。一段代码在生产环境里安安稳稳跑了好几年,没有一个真人用户投诉过;一个自动化扫描工具生成了一份听起来煞有介事的理论漏洞报告;报告进了问题跟踪系统;这段代码名下多了几个"未解决问题",而移除它,读起来就成了例行清理,而不是变相弃用。curl项目正站在这股浪潮的前沿。维护者Daniel Stenberg早在2024年1月就发出过关于AI辅助安全报告的警告,到2025年7月他透露,curl收到的安全报告里大约五分之一是AI生成的"水货",截至当时没有一份靠AI生成的报告被证实真实有效,但每一份都在消耗资深审阅者宝贵的时间。对任何一个无法分辨"机器臆想的理论漏洞"和"真实用户踩过的坑"的项目而言,"靠文书工作把代码悄悄弃用掉",是完全可能发生的事。
在关于"范围该不该收窄"的争论里,凡是拿"因为有AI了"当理由的说法,都值得格外警惕,因为同一个前提可以在一个论证里变成"产能"(维护者更少也能扛更多代码),又在下一个论证里变成"负担"(生成的垃圾报告淹没了问题跟踪系统)。一个既能支持某个结论、又能支持其反面的前提,本身说明不了任何问题。
开源尽职调查具体要看什么?
和审查商业供应商一样,只是把镜头往下移了一层。上面这几组对比,已经把该问的问题摆在了眼前。
是否有成文的生命周期政策。维护方到底有没有公开发布过这类文件?Python的十年预警之所以存在,是因为PEP 373这份文件存在。内核在硬件支持这件事上从来没有对应文件,这本身就提前告诉了所有人:通知与否,全看邮件列表的心情。
过往记录与变化方向。这个维护方上一次修改日期时,是往哪个方向改的?Python的修订对用户更有利,CentOS的修订则让用户损失惨重。维护方上一次的修订方向,是判断它下一次会怎么改的最好依据。
传导性通知期。你真正拿到的预警期,是整条依赖链里最短的那一环,不是包装盒上印的那个数字。Node 16的时间表一直被严格遵守,直到OpenSSL的时钟先走完。把自己平台继承自更上游的那些"时钟"都梳理清楚。
治理结构与资金来源。谁在给这个维护方出钱?当你被迫更换硬件或重新搭建平台时,这些出资方是不是恰好从中受益?
风险敞口与退出路径。提前弄清楚,自己技术栈里哪些功能、平台和硬件世代,处在上游可能划入"过时"的合理区间内,现在就冷静地把分叉、锁定版本或迁移的成本算出来,而不是等支持真的被砍掉的那个季度再手忙脚乱。一条你已经算清楚成本的退路,才是唯一能真正增加你谈判筹码的退路。
这些做法一点也不玄乎。它和我们在技术战略评估中使用的激励机制分析方法完全相同,只是这次把镜头对准了大多数企业从未认真审视过的对象,而且它理应和支撑你业务的平台纳入同一份生命周期规划。它也呼应了我们在AI就绪度话题上一贯坚持的原则:任何主张在被采信、被行动之前都要先经过检验,不管这个主张来自上游社区,还是来自你自己董事会里的某个人。支撑你技术栈的这些基石,是一群不承担任何供应商义务的"供应商"。像审查供应商一样审查它们的维护方,它们随时可能改变主意,而代价,最终都会落在你头上。
常见问题
我怎么判断自己依赖的开源项目会不会突然砍掉支持?
盯着维护方,而不只是盯着代码本身。没有成文的生命周期政策、资金来源和董事会构成正在转向新的商业优先级、把弃用说成"减轻维护负担"、你所依赖的那部分代码维护者稀少,这些都是早期信号。486支持移除,内核社区其实提前近三年就在讨论。把一个项目的治理讨论帖,当成供应商的财报电话会议来看待:枯燥、公开,却全是信号。
AI生成的漏洞报告真的会威胁到成熟软件的稳定性吗?
会,curl项目的经历说明了它的具体样子:收到的安全报告里有相当一部分是机器生成的,而几乎没有一份被证实真正有效。真正的风险出在分诊环节。一个由机器生成的理论性缺陷,证据力天然弱于一个真实用户在生产环境中踩到的故障,而如果项目把两者一视同仁,就会一点点把能正常运行的代码重新归类为"负担"。评估一项依赖时,应该问清楚它的分诊流程能不能分辨"机器臆想"和"真人报告"。
一份开源治理评估应该包含哪些内容?
四件事:维护方是否公开生命周期政策,以及过去是如何履行或修改这些日期的(跨度从Python 2十年的预警,到CentOS 8从2029年骤然收缩到2021年的对比);谁在治理、资助这个维护方,其收入来源正在流向何处;梳理清楚自己有哪些系统依赖着可能被划入"过时"范畴的功能,包括从更上游继承来的通知期;以及一条已经算清楚成本的退出路径(分叉、锁定版本或迁移)。每年更新一次,因为维护方的利益变化速度,通常比你的技术刷新周期要快。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。