早段时间看到FFmpeg官推直接开撕Google，我当时就震惊了。
这可是全球视频处理的底层依赖啊，YouTube、Netflix、Chrome哪个不用它？
结果现在维护者公开怼金主，说"要么给钱，要么别再发bug报告了"。
搞笑的是AI能发现Bug，但没法修复Bug，只能人工修复。
但是Bug越来越多，而人工和薪水却越缩水……
作为一个写了十几年代码的老程序员，看到这个我是既心疼又无奈。
万亿市值的公司靠着几个志愿者的业余时间撑起自己的核心业务，这事儿本来就不对劲。
这次争议的导火索是Google用AI工具发现了一个1995年游戏编解码器的漏洞，然后按照他们的90天披露政策要求修复。
FFmpeg维护者直接急眼了，说这是"CVE垃圾"，AI生成的报告比他们能处理的速度快太多了。
但事情远不止表面这么简单。
我仔细研究了下，发现这背后是整个开源生态的系统性危机。
不是FFmpeg作，也不是Google坏，而是当年那套"用爱发电"的模式，在2025年的AI时代已经彻底玩不转了。
FFmpeg，可能很多人都不知道有多强多重要，或许你在这篇文章能找到答案。
双方到底在吵啥
FFmpeg这边的核心诉求其实很简单：如果Google有资源投AI工具大规模扫漏洞，就应该也投资源修复或至少帮忙排优先级。
他们觉得"资助我们或停止发送bug报告"不是不讲理的二选一，而是对失衡关系的必要纠正。
维护者指出，Google的行为模式创造了一种新型的劳动外部化：通过自动化降低了漏洞发现成本，但把所有人工密集的修复工作转嫁给无偿劳动者。
这外部化在AI时代特别严重，因为它打破了传统安全研究中发现成本与修复成本的自然平衡。
以前一个人工研究员发现漏洞，他通常也有能力修复，贡献补丁的边际成本不高。
但AI发现漏洞后，它不具备理解项目架构、编写符合代码风格的补丁、跑回归测试的能力。
所有这些工作还是得人来干。
Google这边强调他们对开源生态的整体贡献以及安全披露的公共利益属性。
他们的安全主管在推特发了详细历史记录，列举了Google自2014年以来对FFmpeg的多次资金支持、通过Google Summer of Code资助的开发工作、以及Project Zero和OSS-Fuzz项目为整个开源社区提供的免费安全测试。
他们认为把FFmpeg视为单纯受害者不公平，因为Google的安全研究实际上帮项目发现了如果任其存在可能被恶意利用的漏洞。
安全研究人员的普遍观点是：漏洞的存在是独立于谁发现它的客观事实。
隐藏已知漏洞不能降低其被恶意行为者发现的概率，反而让用户在不知情下持续暴露于风险中。
从这角度看，公开披露即使缺乏补丁也有价值，因为它至少让下游用户和分发者有机会做知情决策，比如临时禁用有问题的编解码器或加强沙箱隔离。
但这两种立场的对立本质上反映的是更深层的系统性困境：当前开源生态缺乏机制来将商业价值的产生与维护成本的承担连接起来。
Google的论点在法律和传统开源伦理框架内完全站得住脚——LGPL许可明确授予无条件使用权，没任何条款要求使用者必须贡献代码或资金。
FFmpeg维护者的愤怒同样有其合理性，当他们的业余时间被外部设定的截止日期和优先级绑架时，开源协作的自愿性质实际上已经受到侵蚀。
这困境没有简单的道德判断能解决，因为它涉及两套原本互不冲突但在规模化后开始产生张力的价值系统：
- 软件自由运动强调的无条件使用权
- 可持续开源实践强调的责任共担原则
大厂白嫖，维护者吃土
商业巨头的单向榨取有多离谱！
先说个真实的故事。
Mark Atwood在Amazon工作时，反复跟老板们强调FFmpeg的重要性。
他说的原话我记得特别清楚：“FFmpeg不是供应商，没有NDA协议，我们没有杠杆，你们的VP拒绝资助他们，而他们明天就能用一封邮件摧毁三条主要产品线。”
你看这话说的多无奈。
Amazon的产品架构完全依赖FFmpeg，但企业决策层就是不肯掏钱。
这种态度在科技圈太普遍了！
YouTube的视频处理、Chrome的媒体解码、Netflix的内容转码，全建在FFmpeg之上，但回馈？呵呵。
更搞笑的是，这些公司不是没钱。
Google市值3.5万亿美元，给FFmpeg团队拨个几十万美元对他们来说就是九牛一毛。
但就是不给，宁可让维护者在推特上公开抱怨。
AI工具让不平等指数级放大！
这次事件的特殊之处在于Google用了个叫Big Sleep的AI安全工具。
这玩意儿发现了FFmpeg里SANM ANIM v0编解码器的漏洞！
这是个专门用来解码1995年LucasArts游戏Rebel Assault 2前10到20帧的格式。
技术上说，这是个UAF（Use-After-Free）漏洞，在特定条件下可能被利用实现远程代码执行。
问题在于，这个编解码器在FFmpeg默认编译配置里是启用的，可以通过文件魔术头自动触发。
听起来挺严重？
但实际上这格式几乎没人用了。
维护者私下地跟一个大佬讲，要不是Google的AI扫出来，他们可能这辈子都不会注意到这个角落。
关键问题来了：AI发现漏洞的成本趋近于零，但人工修复的成本一点没降。
以前一个人工研究员发现一个漏洞，顺手写个补丁也就那么回事。
但现在AI一天能扫出几十个问题，每个都需要维护者投入大量时间理解上下文、评估影响、设计修复方案、跑回归测试。
一位FFmpeg维护者在X上透露，过去7个月他从安全工作只拿到7560欧元的税前收入，但期间要处理大量自动化工具提交的漏洞报告。
这收入跟依赖FFmpeg的公司赚的钱比起来，简直是个笑话。
更深层的矛盾在于，维护者参与开源项目是因为热爱技术、想为数字保存做贡献、享受社区认可。
他们不是为了满足Google的合规需求。
FFmpeg官推公开质疑这些"CVE slop"（CVE垃圾）时，用词特别直接：针对1990年代业余编解码器的安全报告就是在浪费宝贵的开发时间。
说白了，Google的AI工具在用企业的优先级强制重新分配志愿者的注意力。维护者本来想优化H.265编码器性能或者改进AV1解码器稳定性，结果被迫去修一个25年前游戏格式的漏洞。
这就好比你周末想在家写自己的开源项目，结果一堆大公司的AI机器人不停给你发工单：“这有个bug”、“那有个安全问题”，还规定你90天内必须处理，否则就公开披露。
你说烦不烦？
很明显就是大公司疯狂获取，维护者只能吃点残渣。
90天倒计时，志愿者哪来的企业响应速度
Google Project Zero在2025年调整了披露政策：发现漏洞后一周内通知项目存在问题（但不说具体是啥），然后启动标准的90天披露倒计时。
这政策对Microsoft、Apple这种有专职安全响应团队的企业来说还算合理。
但套在FFmpeg这种靠几个核心志愿者利用业余时间维护的项目上？
简直是开玩笑。
我算了一下，90天对每周工作40小时的安全团队来说是360个工作小时。但对只能晚上和周末搞开发的维护者，实际可用时间可能不到50小时。
这还没算上他们要处理其他日常维护工作、回答社区问题、审核PR的时间。
本质上，这是在用企业级的响应要求强加于个人能力之外。
就好比你跟马拉松冠军说"咱俩一起跑个5公里"，但你骑着摩托车，人家只能用腿跑。
在AI工具介入之前，安全研究员手动发现漏洞的过程本身就是个天然的节流机制。
一个人一年能找出几十个漏洞就算高产了。
但现在Google部署Big Sleep这种AI代理，在代码库里系统性扫描，漏洞发现的边际成本基本为零。一天扫出几十个问题轻轻松松。
问题是，每个报告都需要人工分类、验证、影响评估、优先级排序。
即使最后决定不修复，也得投入时间做出负责任的判断。
其中一位维护者描述的情况特别形象：他们面对的不是偶尔冒出来的重大安全问题，而是持续不断涌入的、覆盖各种边缘场景的报告流。
当报告生成速度超过处理能力几个数量级时，这就不是工作负荷增加的问题，而是一种系统性的淹没状态。
截止日期把技术决策优先级搞乱了！
FFmpeg团队最后还是在截止日期前修了SANM编解码器的漏洞。
但这是个在现代几乎没人用的格式。
维护者有提过的是：要是没有90天披露压力，他们肯定优先处理影响当代工作流的问题。
比如H.265编码器的性能优化、AV1解码器的稳定性改进。
但公开截止日期创造了一种人为的紧迫性，逼着技术资源向那些即将到披露窗口的问题倾斜，而不是向对用户群体影响最大的问题集中。
这种优先级扭曲有累积效应：每个因截止日期被提前处理的边缘问题，都意味着某个更重要但没有外部压力的改进被推迟。
长期下去，项目的发展路线图不再由维护者的技术判断和社区需求驱动，而是被外部披露时间表劫持了。
看这对比表就知道，这根本不是一个级别的较量。
就好比让业余足球队跟国家队比赛，还要求一样的成绩标准。
许可协议的道德真空地带
这就是权利与义务完全脱钩的制度设计！
FFmpeg用的是LGPL 2.1许可，里面有句特别经典的话：“本软件按原样提供，不附带任何形式的明示或暗示保证”。
这条款从法律上保护了维护者不用承担质量担保责任。
但同时也给使用者创造了一个无需承担任何对等义务的使用环境。
Google可以完全合法地把FFmpeg集成到YouTube里，构建价值数千亿美元的业务，而无需支付许可费或承诺任何形式的维护投入。
LGPL的设计初衷是保护软件自由——确保代码可以被任何人出于任何目的使用和修改。这在对抗微软、Oracle这些专有软件巨头的年代很有进步意义。
但问题来了：当开源软件从边缘替代方案演变为全球数字基础设施的核心组件时，这种单向自由开始显露制度性缺陷——它成功防止了代码被封闭，却没能建立起生态维护的责任机制。
FFmpeg始于2000年Fabrice Bellard的个人项目，最初目标就是给Linux提供个多媒体解决方案。
25年后，它已经是YouTube视频处理、Netflix内容转码、Chrome和Firefox媒体播放、无数操作系统发行版的底层依赖，每天处理全球数十亿次音视频转换。
但项目治理结构还是松散的志愿者协作模式，没有建立与其关键性相匹配的资金储备、法律保护或组织架构。
这演变路径本身就反映了开源生态的一个根本悖论，成功的开源项目因卓越的技术质量被广泛采纳，但正是这种成功把它推向了与初始设计不匹配的角色。
通俗而言，当一个周末项目变成全球基础设施时，它需要的不再是更多的周末时间，而是完全不同的治理模型。
就好比你本来只是想在家门口摆个小摊卖煎饼果子，结果莫名其妙发展成了全国连锁，但还是用夫妻店的管理方式——这能不出问题吗？
2024年12月，Nick Wellnhofer宣布不再维护libxml2！
这是个被所有主流浏览器、Apache和Nginx、LibreOffice以及无数Linux包依赖的XML解析库。
他退出的理由跟FFmpeg维护者的抱怨高度一致：持续的安全压力、有限的资源支持、日益增长的责任负担。这不是孤立事件，而是xz Utils后门事件后又一个关键基础设施维护危机的信号。
FFmpeg的多名核心贡献者在推特讨论中表达了类似的倦怠感。
有人直接说，如果当前趋势继续，他们也会考虑退出。
这些退出不会立即让软件停止工作，但会创造一个维护真空：新的安全漏洞无人修复、与新硬件和操作系统的兼容性问题持续累积、现有bug的修复周期无限延长。
最终结果是一个表面上还在运行，但实际上正在慢性衰败的基础设施层。
这时间线清楚展示了渐行渐远……
技术细节：这个漏洞到底有多严重
既然说到了，我就详细解释下这次争议的核心——SANM漏洞到底是咋回事。
UAF（Use-After-Free）漏洞的形成涉及内存管理的时序问题：当一块内存被释放后，如果代码路径中还持有指向该内存的指针并尝试访问，就会产生未定义行为。
最好的情况是程序直接崩溃。
但如果是精心构造的攻击场景，攻击者可以控制被释放内存的重新分配，把恶意数据填充到原位置，从而在后续访问时劫持程序控制流，实现远程代码执行。
SANM编解码器的问题在于它处理1995年游戏视频流时的内存管理逻辑有缺陷。
而FFmpeg的文件格式自动探测机制意味着，攻击者可以构造一个表面看似MP4的文件，通过魔术头触发SANM解码路径。
并且会有更深的问题，即架构问题。
FFmpeg为了实现"支持所有格式"的设计目标，把数百种编解码器以统一接口集成在一起，并默认启用了其中的绝大部分。
这设计在功能完整性上有优势，但从安全角度创造了巨大的攻击面：即使99%的用户永远不会用SANM编解码器，它仍然存在于几乎所有FFmpeg构建中，成为所有依赖FFmpeg的应用程序的潜在弱点。
行业最佳实践建议对不可信输入的媒体处理应该这么搞：
- 编译时只启用必需的编解码器
- 把FFmpeg进程跑在受限的沙箱环境中
Google内部几乎肯定已经做了这些防护。
这也部分解释了为啥他们愿意投资源找漏洞但不急着修——这些漏洞对他们自己的基础设施根本不构成威胁。
最后来看看Git提交记录揭示的真相，我查了下FFmpeg的Git历史，搜索包含http://google.com邮箱地址的提交，发现有643次代码贡献。
git clone https://git.ffmpeg.org/ffmpeg.git
cd ffmpeg
git log --pretty=format:"%ae" | grep -E "chromium\\.org|google\\.com" | wc -l
prints 643但仔细看这些提交，主要集中在VP9、AV1等Google主导的视频编解码标准的实现和优化上。
这反映了一种战略性的选择性投入模式：Google为直接服务于其业务需求的技术领域提供工程资源，但对项目的整体维护负担和安全债务不承担系统性责任。
fflabs.eu网站（这是FFmpeg核心维护者搞的商业咨询公司）的客户列表显示Google确实通过商业渠道向维护者付费。
但具体金额没公开。
即使假设Google是主要金主，这金额相对于YouTube每季度数十亿美元广告收入，在比例上几乎可以忽略不计。
真的是「河内凶，则移其民于河东，移其粟于河内；河东凶亦然」，把大量精力花在几乎不用的格式上。
解决方案：技术、资金、制度三管齐下？
从技术角度，FFmpeg可以采取的近期措施包括：
重新评估默认编译配置，把长期无人维护的历史编解码器移至可选模块。
这能显著减少攻击面，同时保持"支持所有格式"的长期承诺。
建立分级响应框架：影响现代广泛使用编解码器的高危漏洞进入快速通道；针对边缘格式的报告纳入长期积压队列，明确告知报告者这些问题将在资源允许时处理但不承诺时间表。
这种透明的期望管理可以避免外部时间压力对内部决策的扭曲。说白了，该快的快，该慢的慢，不要一刀切。
从资金上，fflabs.eu作为商业咨询实体的存在证明了一种可能性：核心维护者通过为企业客户提供定制服务、优先支持或专业培训获得收入，同时维持项目的开源属性。
但这模式的可扩展性受限于维护者的时间总量——当他们已经在处理日常维护时，很难再腾出大量时间搞付费咨询。
更系统的方案可能需要借鉴SQLite Consortium的模式：建立一个由主要商业用户组成的联盟，每个成员支付年度会员费资助专职维护团队，作为回报获得优先支持和功能请求权。
这模式的关键在于将维护工作从志愿劳动转变为专职工作，从而使其能承载企业级的响应要求。就好比把兼职变全职，这样才能跟企业的节奏匹配。
一些新许可模式开始探索如何在保持源代码开放的同时建立使用门槛。
比如对年收入超过特定阈值的企业用户要求付费许可，或要求商业用户必须将修改回馈上游。
这些限制使软件不再符合开源倡议组织的严格定义，因此被称为源码可用许可而非开源许可。Elastic和MongoDB已经试过了，虽然遭遇了云服务商的强烈抵制和部分社区分裂，但确实为项目带来了更稳定的资金。
FFmpeg若采取类似路径会面临更大争议，因为现有的LGPL许可使得任何人都可以fork一个维持旧许可的版本，导致生态系统碎片化。
开源软件的成功已经超越了其最初的制度设计容量。当一个周末项目演变为全球数字基础设施时，单纯依靠志愿者热情和大公司偶尔善意已经不足以维持运转。
需要的是一种新的治理模型，既保持开源协作的开放性和创新活力，又建立起与项目关键性相匹配的资源保障和责任分担机制。
这个转型不会自发发生，需要维护者、企业用户、政策制定者和整个技术社区共同努力，重新定义21世纪的开源生态应该是什么样子。
不然的话，我们可能会看到越来越多的libxml2式退出，最后整个开源基础设施层慢慢腐烂，那时候大家一起完蛋。
不是为了FFmpeg，也不是为了Google，而是为了整个技术生态的健康和可持续发展。大家都懂得都懂，就看谁先迈出那一步了。