开源在中国到底过得怎么样？
看数字，答案很乐观。
开放原子开源基金会发布的《中国开源发展深度报告（2025）》显示，2025 年中国活跃开源项目达到 425.38 万个，同比增长 40.58%；活跃开源开发者达到 263.03 万人。大会、基金会、代码平台和扶持计划都比过去多。
可只要真正维护过一个项目，体感往往没这么漂亮。
Issue 越积越多，兼容环境越来越杂，安全和合规要求越来越细。用户增长很快，愿意接手维护的人没有同步增长。仓库数量上去了，能稳定维护五年、十年的项目依旧少。
图片来源：开放原子开源基金会官网。
“免费”被理解成了“什么都该免费”
很多人使用开源软件时，默认只需要付出一次下载动作。
运行正常时，维护者是谁并不重要。系统出问题后，社区 Issue 立刻被当成工单系统：希望当天回复，希望马上修复，希望兼容自己的特殊环境。需要私有部署、权限改造、数据迁移、培训和正式文档时，还会有人问一句：“开源项目为什么收费？”
因为代码许可和工程服务是两回事。
服务器、测试设备、安全审查、文档、版本维护都需要时间和钱。开源许可证允许用户使用、修改和分发代码，没有要求作者提供无限期售后。
一些人最常见的支持方式只有 Star、催更和提需求。项目停更后，又感叹国内开源环境不好。问题当然复杂，但只拿不养肯定不会让环境变好。
企业从开源获得价值，却很少把价值送回上游
国内企业大量使用社区软件，这本身值得肯定。尴尬之处在于，很多组织长期停留在“下载、部署、内部修改”这一步。
一个组件可能支撑订单、数据处理、运维平台或内部协作。业务依赖它，研发靠它节约时间，预算里却没有上游维护的位置。企业愿意为宣传、咨询和采购流程花钱，轮到真正托住系统的软件基础设施，常常只剩“社区版先顶着”。
内部修改越来越多，又很少提交给上游。几年之后，版本无法升级，安全修复难以合并，维护成本翻倍。这个结果并不神秘，只是早期省下的钱换了一个时间回来收取。
Linux Foundation 在 2025 年全球开源研究中指出，企业对开源的依赖持续加深，治理、安全框架和长期投入仍有明显缺口。这个问题全球都有，在国内低价竞争、私有化交付和重度定制的环境中尤其显眼。
想要商业软件级别的响应、责任边界和服务承诺，就该支付相应费用。把社区维护者当成免费的外包团队，很难称得上支持开源。
很多项目在发布那天达到巅峰
国内大厂、高校和创业团队都在开源。项目数量增长很快，长期治理却没有同样热闹。
有些项目服务于招聘、品牌、课题或比赛。发布时新闻稿写得很大，负责人调岗后，仓库很快进入低维护状态。README 仍写着“欢迎共建”，外部 PR 几个月无人处理，路线图停在两年前。
开源社 2025 年调查中，超过六成受访者遇到过文档不足，约一半遇到依赖冲突，三成以上提到版本波动。这个结果很符合现实：发布代码只需要一次决策，维护文档、版本、兼容性和社区关系需要长期投入。
真正的开源项目要有贡献流程、版本策略、决策机制、维护者交接和安全响应。缺少这些，公开仓库更接近一个下载页面。
镜像仓库越来越多，协作反而被切碎
国内代码托管平台都在争夺项目、开发者和商业机会。竞争没有错，机械搬运和重复镜像却经常制造虚假的繁荣。
同一项目分散在多个平台，Star、Issue 和 PR 也跟着分散。用户在镜像仓库提问，真正的维护者可能完全看不到。平台多了一个仓库，项目没有多一个贡献者。
镜像能改善下载速度，无法自动形成社区。
社区依赖共同讨论、代码审查和治理。复制 Git 历史很容易，复制信任关系做不到。
开源贡献在公司里仍常被视为业余爱好
不少开发者愿意给上游修问题，却只能在下班后做。
白天，公司使用开源项目完成业务；晚上，员工替这些依赖修 Bug。修复完成后公司受益，到了绩效评审，这部分工作未必算正式成果。
这种安排不可能长期稳定。
开源社调查显示，推动贡献的主要因素仍是社区氛围、兴趣和技术成长，经济回报排在后面。热情很重要，可公共基础设施长期依赖少数人的业余时间，风险也很明显。
企业应当允许员工在工作时间参与关键上游项目，把漏洞修复、依赖维护和社区治理纳入绩效。它们直接降低公司的技术债和供应链风险，不是什么与业务无关的慈善活动。
责任越来越重，资源没有跟上
今天维护一个被广泛使用的项目，工作早已超出写代码。
许可证兼容、依赖审查、漏洞响应、版本生命周期、软件物料清单、国产环境适配，这些事情都需要专业人员。社会对开源项目提出了越来越接近商业软件厂商的要求，给维护者的资源却常常停留在几句感谢。
项目开始收费，社区里马上有人质疑“变味了”；项目坚持全免费，维护者又很难活下去。结果通常是维护者退出、项目停更，或者核心能力转入商业产品。
维护者也需要收入。通过托管服务、企业版、技术支持和定制开发获得收入，没有任何可耻之处。真正不合理的是，一边依赖开源挣钱，一边要求作者永久无偿劳动。
AI 把项目数量又推高了一轮
生成式 AI 降低了写代码和创建仓库的门槛，也带来了更多套壳项目、未经验证的依赖和低质量贡献。
现在改一个名称、换一个界面、生成一份 README 很快。仓库看上去完整，真正运行时可能没有测试，也没有清晰的维护计划。维护者收到的 PR 同样可能代码很多、解释很少，审查成本比亲自修改还高。
AI 提升了代码产量，没有同步提升工程责任感。
评价开源生态时，仓库数和提交数越来越不够用。更值得关注的是：项目持续维护了多久，外部贡献者能否进入治理层，企业向上游提交了多少补丁，核心依赖有没有稳定资金，安全问题能否在明确时限内处理。
该怎么改变
企业把开源项目放进生产，就应安排依赖治理、升级测试和安全响应。项目足够重要，可以购买支持服务、赞助维护者，也可以让员工直接参与上游。
采购方也该停止用“开源”压低所有服务价格。私有部署、迁移、培训、定制开发和 SLA 都是实打实的工作，应当单独计价。
代码平台少追求重复仓库数量，多解决跨平台同步、身份、Issue、PR 和发布协作。镜像服务应该把用户引回上游，而不是再造一个无人维护的社区入口。
维护者需要尽早写清支持范围、版本生命周期和治理规则，区分社区支持与商业服务。边界模糊只会让双方都失望。
普通用户也能做很多事：认真阅读文档，提供可复现信息，修正文档，提交测试，参与讨论，或者赞助项目。哪怕只做一件，也比催更有效。
写在最后
中国不缺开发者，不缺项目，也不缺大会。
真正稀缺的是长期投入，以及愿意为长期投入付账的人。
我们已经习惯把开源当作随手可取的公共资源，却没有形成供养公共资源的习惯。大家都想从井里打水，很少有人愿意修井、清淤和换泵。等井枯了，再开一场生态大会，水也不会自己回来。
开源软件可以免费分发，维护成本不会消失。
没人承担这笔成本，它迟早会以停更、漏洞、迁移和系统故障的形式回来。通常还会更贵。
评论