Linux基金会2025年度报告近日曝光，其中一个数据引发了开源社区的广泛讨论：在基金会的总预算中，仅有2.95%被直接用于Linux项目本身。其余97%以上的资金流向了哪里？这个数字背后反映了开源治理的什么问题？

2.95%的数据来源

Linux基金会是全球最大的非营利开源组织之一，托管了Linux内核、Kubernetes、Node.js等数百个重要开源项目。其年度报告披露了详细的资金分配情况。

报告显示，Linux基金会的预算主要分配在以下领域：

• 项目支持和基础设施：包括CI/CD、代码托管、安全审计等
• 活动和会议：如Linux Foundation开源峰会、KubeCon等大型技术会议
• 培训和认证：LFS系列认证课程的开发和运营
• 法律和合规：开源许可证合规、专利保护等法律服务
• 行政和运营：基金会自身的人员和办公成本
• 直接Linux内核支持：仅占2.95%

为什么只有2.95%

这个数字看似惊人，但有几个背景需要了解：

1. Linux基金会≠Linux内核基金会

Linux基金会的名称容易让人误解。实际上，它已经从最初的”Linux内核支持组织”演变为一个综合性的开源基金会，托管了数百个项目。大部分预算用于支持这些托管项目的整体生态。

2. 内核开发主要由企业资助

Linux内核的开发工作主要由各大科技公司的全职开发者完成。据Linux基金会的Kernel Development Report，超过85%的内核代码贡献来自公司雇佣的开发者。基金会的直接资金支持并不是内核开发的主要资金来源。

3. 间接支持

虽然直接用于Linux的预算只有2.95%，但基金会在基础设施、法律保护、活动组织等方面的支出，间接惠及了Linux内核项目。

开源社区的反应

这个数据在开源社区引发了不同观点：

批评声音：

• 认为基金会偏离了初心，更像一个商业活动组织机构
• 质疑高昂的会议和行政开支的必要性
• 担心核心基础设施项目得不到足够资金支持

支持声音：

• 认为基金会的多元化运营有助于整个开源生态的健康发展
• 指出活动和培训收入反过来资助了项目开发
• 强调企业合作模式是当前开源治理的最可行方案

对站长和开发者的启示

1. 了解开源治理现实

开源不等于免费，维护开源项目需要持续的资金和人力投入。作为开源软件的使用者，了解这些背后的运作方式，有助于做出更负责任的使用决策。

2. 考虑直接贡献

如果你的业务重度依赖某个开源项目，除了Star和口头支持外，考虑通过赞助、贡献代码、参与社区治理等方式给予实际支持。

3. 关注项目健康度

在选择技术栈时，不仅要看项目的功能和性能，还要关注项目的治理模式、资金状况和社区活跃度。一个资金充裕、治理健康的项目，长期维护的可靠性更高。

4. 理解基金会的角色

开源基金会的主要价值不在于直接资助代码开发，而在于提供法律保护、品牌信任、企业合作桥梁和社区治理框架。这些”软性”支持对开源项目的长期生存同样重要。

其他有趣的数字

Linux基金会2025年报告中还有几个值得关注的数据：

• 基金会托管项目的总代码价值估计超过200亿美元
• 成员企业数量持续增长，覆盖全球主要科技公司
• 新孵化项目集中在AI/ML、安全、边缘计算等领域

OpenAI在推出实时语音和视频功能时，遇到了一个不大不小的基础设施难题：WebRTC。这个为浏览器实时通信设计的技术栈，在面对OpenAI的规模和需求时，暴露出了不少问题。本文分析OpenAI遇到的WebRTC困境，以及这对整个实时AI通信领域意味着什么。

什么是WebRTC

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开放标准。它被广泛用于视频会议、直播、在线教育等场景。Zoom、Google Meet、Discord等产品的底层通信都依赖WebRTC或其变体。

当OpenAI推出GPT-4o的实时语音功能时，选择了WebRTC作为客户端与服务端之间的实时音频传输方案。这个选择看起来很自然——WebRTC是浏览器原生支持的、成熟的实时通信方案。但在实际落地过程中，问题逐渐暴露。

OpenAI遇到的WebRTC问题

1. 延迟和抖动

AI实时语音对话对延迟的要求比普通视频会议更高。用户说完一句话后，期望AI能在几百毫秒内开始响应。但WebRTC的网络自适应机制（如抖动缓冲区、丢包重传）在某些场景下反而增加了延迟。

2. NAT穿透问题

WebRTC需要通过ICE（Interactive Connectivity Establishment）框架来处理NAT穿透。在复杂的网络环境（如企业防火墙、运营商级NAT）下，连接建立的成功率和速度都不够理想。

3. 服务端扩展

传统的WebRTC架构中，SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）负责媒体流的转发和混合。当需要处理海量并发的AI语音会话时，服务端的扩展成本和复杂度急剧上升。

4. 浏览器差异

虽然WebRTC是W3C标准，但不同浏览器的实现细节存在差异。Chrome、Firefox、Safari在编解码器支持、API行为等方面的不同，给跨平台兼容性带来了额外工作。

替代方案探讨

有开发者提出了几种可能的替代方案：

• WebSocket + 自定义音频流：绕过WebRTC的复杂性，直接通过WebSocket传输PCM或Opus编码的音频数据。实现简单，但需要自行处理网络自适应。
• Media over QUIC (MoQ)：IETF正在标准化的新一代媒体传输协议，基于QUIC协议，目标是替代WebRTC用于大规模实时媒体分发。这也是那篇HN文章的讨论重点。
• gRPC Streaming：Google的gRPC框架支持双向流式传输，可以用于音频数据的实时传输，但浏览器端支持有限。
• 专有协议：像Discord那样，开发针对特定场景优化的专有协议。

对站长和开发者的启示

如果你在开发涉及实时AI语音交互的应用，以下几点建议：

1. 评估实际需求：如果你的应用不需要浏览器端实时音频，WebSocket方案可能更简单可靠。
2. 关注MoQ进展：Media over QUIC是未来方向，但目前标准化和实现都还不成熟。
3. 做好降级方案：即使使用WebRTC，也要准备WebSocket降级方案，确保在WebRTC连接失败时用户仍有基本体验。
4. 测试真实网络环境：在开发环境中的低延迟网络下测试没问题，不代表在用户的4G/WiFi环境下表现良好。

实时AI通信的未来

随着AI语音交互、AI视频通话等功能的普及，实时AI通信基础设施的需求会越来越大。WebRTC虽然是目前最成熟的选择，但确实需要演进才能满足AI场景的特殊需求。

OpenAI遇到的这些问题，其实也是整个行业需要解决的。未来可能会出现专门为AI实时交互优化的通信框架，或者WebRTC本身会针对AI场景进行扩展。