一个悖论
现代软件严重依赖开源：一个应用可能包含数百个开源依赖，而其中很多是被极少数人维护的。
但这些项目往往没有可持续的资金来源。
困境的表现
一、维护者倦怠（Maintainer Burnout）
很多关键项目由志愿者在业余时间维护。
维护者要处理：
- 大量 issue 和 PR；
- 用户提问（很多是重复的基础问题）；
- 安全报告；
- 依赖更新和兼容性问题。
而且往往是无偿的。
当维护者精力耗尽或失去兴趣，项目可能陷入停滞——但依赖它的系统仍在运行。
二、"搭便车"问题
企业大量使用开源软件获利，但不回馈（资金、代码贡献、人力）。
研究显示：许多关键基础设施的开源项目由极少数开发者支撑，而使用者是数以百万计的公司。
三、资金分配的扭曲
即便有赞助，资金往往流向：
- "热门"的、有曝光度的项目；
- 新项目；
而那些不性感但至关重要的底层组件（如某个被广泛依赖的小工具库、构建工具、安全相关的基础组件）却鲜有资助。
风险点往往在这些默默无闻的底层依赖上。
典型案例
Heartbleed（2014）：
OpenSSL 的一个严重漏洞，影响了大量互联网服务。事后人们发现，这个被广泛使用的加密库当时只有极少的全职维护者和微薄的资金。
事件之后：业界成立了 Core Infrastructure Initiative，加大了对关键开源基础设施的资助。
xz 后门事件（2024）：
有人在 xz-utils（一个被广泛使用的压缩库）中植入了后门。这一事件引发了关于开源供应链安全的广泛讨论——攻击者通过长期参与项目、获得信任、最终成为维护者，然后植入恶意代码。
警示：开源项目中"信任"的形成机制本身，也可能成为攻击面。
尝试的解决方案
一、资金支持
- 赞助平台：GitHub Sponsors、Open Collective；
- 企业资助：大公司资助关键项目（如 Google、Microsoft、AWS 对多个基金会的投入）；
- 基金会：Apache 软件基金会、Linux 基金会、CNCF、Python 软件基金会等，为项目提供治理和资金管理。
二、商业化模式
- 开放核心（Open Core）：核心开源，企业版/附加功能收费（如 GitLab、Elastic）；
- 托管服务：提供云托管版本（如 MongoDB Atlas、Confluence Cloud）；
- 双许可：开源许可 + 商业许可（如 Qt、MySQL）；
- 支持与服务：卖技术支持、培训、咨询。
注意：商业化模式常与"纯粹开源"产生张力。近年有多个项目因商业化压力而修改许可证（如 Elastic、Redis、Terraform 的许可变更），引发社区争议。
三、治理与规范
- 明确的贡献指南和行为准则；
- 安全响应流程（如何报告漏洞、如何协调披露）；
- 关键项目多人维护（避免"巴士因子 = 1"）；
- 供应链安全实践（签名、SBOM、依赖审查）。
四、企业参与（而非只索取）
最有价值的回馈不只是钱：
- 贡献代码（尤其是修复 bug 和补充文档）；
- 让员工在工作时间参与维护；
- 响应维护者的问题（报告 bug 时提供最小复现）；
- 资助或赞助。
作为使用者能做什么
- 了解你的依赖：关键路径依赖了哪些项目？它们由谁维护？活跃度如何？
- 回馈：报告高质量的问题、提交文档改进、小额赞助；
- 评估依赖的风险：对关键依赖，考虑其可持续性（维护者数量、资金状况、社区活跃度）；
- 减少不必要的依赖：每多一个依赖，就多一份供应链风险和维护负担。
一个认知
开源软件不是"免费的劳动力"，而是公共基础设施。
它需要像桥梁、道路一样被维护——而维护是有成本的。
说明：本文为开源生态的知识整理。