为何钻石赞助 Apache 社群峰会：我的开源观
下周五到周日，也就是 7 月 25 日到 27 日，一年一度的 Apache 社群峰会（CommunityOverCode Asia 2025）将在北京海淀举行。
峰会的最后一天，我和 Rust 社群的伙伴们组织了 Rust 分论坛，讨论开源生态以及 Apache 项目中 Rust 的发展和应用。同样在 27 日的早晨，我会做一个题为《七年之痒：我的 Apache 故事》的主题演讲，介绍 Apache 软件基金会如何深刻地影响了我的开源之路，以及每一位工程师如何从 Apache 社群中受益。
关注峰会的朋友可能会发现，今年峰会在企业赞助商之外，还开辟了个人赞助的通道，而我就是第一位个人钻石赞助者。
这次个人赞助的动机，可以追溯到去年我参与峰会的纪实：
我在这里承诺，如果明年开通了个人赞助的渠道，我将以本人的名义或届时所在公司的名义，捐赠不少于十万元人民币以作支持。期待明年 CommunityOverCode Asia 越办越好！
应当说，今年的个人赞助渠道也是因为这个 FLAG 开通的，钻石赞助对应的也正好是十万元人民币的捐赠。意料之外但是也令人开心的是，这也激发另一位开发者通过个人赞助支持峰会。
再往前溯源，我会动个人赞助的念头，是因为去年主办方写了一篇文章讲述社群会议组织举办不易，需要更多支持。我想今年的赞助状况，应该能至少让活动主办方不赔钱。
说回个人赞助的动机，出发点可以分两个方面来讨论。第一是为什么我希望 Apache 社群峰会能一直举办下去，第二是开源生态在中国如何持续发展。
Apache 社群峰会是一个以开发者为中心，开源项目做主角的技术峰会。
我在跟其他 Apache 成员交流的时候，曾经提到过：
TBH, in the past few years, I have several times been tired of tracking discussions and feeling the malice on the list. However, the ASF is still a good place that greatly benefits many open-source enthusiasts, and I’d stay to help it move forward.
Apache 软件基金会（ASF）独特的志愿者（Volunteer）文化和造福大众（For Public Good）的目标，使得它在某种意义上成为一个开发者的乌托邦。ASF 关心的是项目的存续和社群的发展，不被笼罩在营利的阴影之下，也不用让步于企业的利益。实际上，The Apache Way 强调了基金会项目供应商中立的属性（Independence），并将所有参与者视作独立的个体（Community of Peers）。
在这样的理念指导下，ASF 的各个项目都是开发者自治的社群在运营，开发者是绝对的主体。当然，人不可能脱离环境而存在，同一个公司的雇员大量参与某个项目可能会导致公司的大手试图把持项目的发展；开发者并非天生的管理者，完全依靠自治可能出现各种治理难题。但是，毫无疑问，ASF 是最具影响力的以开发者为中心，开源项目做主角的开源软件基金会。
我很喜欢这样的开源社群运行模式，也就是常说的“集市”模式：天南地北的开发者来到这里，乱糟糟的发表自己的看法，提出自己的改进方案，项目管理委员会就像集市的协调员，或许自己也要动手开发，但是必须投入很大精力促进来到集市的成员创造价值，自行解决问题或为项目发展添砖加瓦。
显而易见，Apache 社群峰会就是一个传播这样理念的大会，它的存在本身就能给予开源开发者足够的激励：这个世界上有人这样创作软件，而且干得不错，影响力不小。峰会上做分享的嘉宾，几乎清一色的也都是开发者，讲述他们参与 Apache 社群的故事，讲述他们对某个开源项目、某个技术领域的探索和成就，鲜见市场营销人员和销售专员。
所以，我很乐见这样的峰会能够持续举办下去，激励更多的开发者参与开源社群，发现更多有趣、有价值的开源项目。
经济基础决定开源是否可持续。
第二个问题，并非个人赞助的动机，更多是藉由活动主办方需要“化缘”维持运作衍生开来考虑的一些问题。
开源项目的开发者，开源活动的组织者和参与者，大多是一个个平凡的人。人都要生存，然后才能考虑自我实现。参与开源运动，开发开源软件，显然是较高层次的需求，我们很难想象开发者在难以维持生计的情况下坚持投入开源。实际上，已经有许多过往案例，生动地演示了开源开发者如何因为开发和维护开源项目需要大量投入，导致个人生计都受影响，从而燃尽退出（Burn Out）的故事。
因此，参与开源的人，一定以某种形式先满足了个人生存的需求。
比如，通过知名开源项目名声大噪，出现企业或组织雇佣保证开源项目的维护。例如 Linux 基金会每年给 Linus 发超过 90 万美元的工资，Apple 雇佣了 Netty 目前的核心维护者 Norman Maurer 并允许他将维护 Netty 作为工作的一部分，LanceDB 雇佣了 Apache OpenDAL 的原作者 @Xuanwo 支持它们深入使用 OpenDAL 和全面改进数据访问体验。即使没到“名声大噪”的程度，深度参与特定开源项目也有机会解决个人收入问题。例如，Apache Flink 的 Committer 很容易在使用 Flink 构建数据流水线的企业找到一份工作。
比如，基于开源项目打造商业产品，出于商业产品发展的需求支持开源项目；或者，在构建商业产品的过程中，生产出了开源效益最高的副产品，随手将其开源。前者例如 Confluent 和 Aiven 都基于 Apache Kafka 构建出自己最大的营利产品，于是各自通过贡献上游争夺标准话语权，以及将客户问题中需要在上游解决的推往上游处理。后者例如 ScopeDB 在开发过程中，伴生了一系列开源效益最大的软件库：我们发现这些基础库、简单通用的应用没有独立的商业价值，开源反而能促进软件的迭代和收获更多反馈，于是就随手将其开源。
还有少部分人是经济自由，或者以跟开源完全无关的方式解决了个人生计问题，又还有闲暇时间贡献开源，纯粹为了自我实现或者造福大众的。
以上这些方式跟具体的案例，或许我会在未来的文章里，结合某个项目再做展开。
回到开源生态在中国如何发展，以及结合上面的案例和讨论，可以看到，开源生态要想蓬勃发展，充分的经济支持是不可或缺的，而要想让开源生态本身获得经济支持，可靠的方式是开源项目本身有足够的价值。
我们看到，世界上最有影响力的开源软件基金会，你都能够快速说出若干个家喻户晓的项目。例如 Apache 软件基金会的 Apache Web Server 和 Apache Hadoop 等，Linux 基金会的 Linux 操作系统，CNCF 的 Kubernetes 和 Prometheus 等，Eclipse 基金会的 Eclipse IDE 和 Jakarta EE 等。很多基金会本身就是以它成立时核心的开源项目来命名的。
当然，还有很多有名的开源组织重在制定标准或进行研究。可是，开源的世界是生产力为王，制定的标准是否得到认可，很大程度上取决于最有影响力的项目选择遵循什么标准。Linux 选择了 GPLv2 又取得了巨大的成功，大家才来研究它为什么成功。Rust 编译器选择了 MIT/Apache 2.0 双许可，大量的 Rust 项目也就不假思索的跟随了这个“标准”做法。制定标准而无人遵守，恐怕难免沦为某种自娱自乐；开源项目成功之后再做研究归纳，也未免有点事后诸葛。而且，参与开源本身，不才是开源开发者最大的乐趣所在吗？
所以，我认为，开源生态在中国的发展，正在等待一个具有足够影响力的开源项目的诞生。
应该说，中国不缺有足够影响力的项目，甚至不缺有足够影响力的开源项目。富有经验的开源开发者、各类开源人才在庞大的基数下，绝对值也绝不会少。然而，我们印象中似乎没有一个项目符合“具有足够影响力的中国开源项目”的描述[^1]。究其原因，不外乎以下两点：
- 某些具有足够影响力的项目，有深刻的中国烙印，甚至托管在国内平台，完全利用国内资源运作。可是，它们在“开源”上却并不显眼。它们认知的开源，就是字面意义上的开放源代码，用开源协议发布软件。然而，这跟开放社群运作的开源协同仍有很大不同。我们一般称之为“橱窗开源”，除了最后开源发布以作展示这一步，其他开发者认知当中开源社群应有的要素，很多都不具备。
- 某些具有足够影响力，就是按照开源协同的社群玩法建设起来的项目，哪怕项目的主力玩家是中国人，但是除此以外几乎没有什么“中国元素”，例如代码往往托管在 GitHub 等平台上，甚至只提供英文文档，整体给人的印象有点像中国开源开发者的壁外调查。
关于第二点，其实可以衍生出不少有趣的讨论。
例如，中国开源开发者是天生喜欢海外的平台吗？并不见得。只是在充分竞争的市场环境下，某些平台和工具的体验更好。国内有没有对标的产品？大多是有的。然而在定位和开发者体验上，往往有比较大的偏差。比如，国内似乎并没有这样一个共识：GitHub 自己并不是一个赚钱的公司。它在被微软收购之前，其实平台能力非常弱，且几乎连年亏损。现在 GitHub 的平台能力，很大一部分是微软直接投入支持的，其产生的价值，很大一部分也是跟 Copilot 和 VS Code 联动带来的。如果希望代码托管平台本身赚钱，恐怕是做不出来 GitHub 这样的社群驱动的平台的。开发者体验就不用说了。
例如，添加中文文档的需求，开源项目维护者们会如何评估？这个问题看起来简单，实际比较复杂。因为讨论门槛太低，导致一直没有太有效的推动。我提一点就是添加中文文档的收益和成本，比如谁会对中文文档有强需求，目前多语言、本地化的工作要如何做，推出中文文档以后，谁来维护。Jeff Tao 前几年发过一篇文章，可做背景参考。
例如，开源项目的作者们想要提高巴士因子，在国内寻求组织支持的时候，有哪些选择？
上面提到，Apache 软件基金会的运营目标是造福大众（For Public Good），其实体是美国的一个慈善组织（Charitable organizations）。另外一个耳熟能详的开源组织 Linux 基金会，其实体是美国的一个行业联盟（Business League），因此它的运营目标是服务供应商（For Vendor’s Good）。
国内也有一些民间的开源组织，但是它们的运营目标和自身定位，往往比较模糊。
例如，某个开源组织的目标是把挂到组织名称下的项目最终送进 ASF 孵化器孵化。从 ASF 的角度看，我是乐见更多项目相信 The Apache Way 并通过孵化成为 Apache 顶级项目。但是从这个开源组织的角度看，它就没有什么独立的宗旨，其价值主张被 ASF 的价值主张框定了。
例如，某个开源组织缺少核心项目，挣扎多年后将自身价值定位在举办活动和生产行业报告上。当然，举办活动和生产行业报告是有价值的，但是对于开源驱动软件创新的目标来说，这些工作恐怕很难促成开源项目的诞生或支持其发展。
还有一些共通的常见问题。例如，民间的开源组织缺少法律支持，要么没有法人实体，要么法人实体是一家普通的公司，开源项目的作者很难用面对国际基金会的预期来跟这些组织打交道。从开源组织的角度说，缺少法律文件的支持，很多制度化组织化的工作也难以开展。例如，开源项目今天为了声量挂靠到某组织下面，所谓的挂靠只是一个口头声明，其商标所有权和知识产权仍然是作者完全保留，随后作者的想法发生改变，回收原先的开源项目或搞出其他操作，开源组织没有任何制衡手段强制进行协商。
我曾经开玩笑地说，我很乐意在国内尝试运营一个以造福大众为目标的开源软件组织。首先，我会找到有价值的项目，组成它一开始的引力中心。如前所述，这样的项目并不少，只是此前没有什么更好的去处，要么自己运营，要么最好是进入 ASF 孵化器孵化，或者有企业支持，可以走 LF 的行业联盟路子。然后，为了维持运营，需要在法律上能够支持这个组织成立一个法人实体，允许合法接受捐赠。最后，以某种手段保证组织的运行是非营利的，治理模式是开放的。从可持续性的角度说，如果能在后续发展的过程中配合上捐助开源组织抵税等政策，就更好了。
这样的一个组织，不用想得太多太复杂，还没成立就想着好处利益如何瓜分，只是以开发者为中心，让开源项目做主角，真的把这个品牌立住了，自然会有想要运营好开源项目的开发者们愿意尝试，出一份力。
[^1]: DeepSeek 很有影响力，也很中国。但是不是开源软件，也没有什么项目本身的协同。它是开源模型，跟橱窗开源相似，但是模型的开源完全是另一个话题。