对开源模式演变的一些想法——写在开始参与开源 10 年后

Linux, Open Source, 中文, 开源 Comments

距离《大教堂与集市》初版已经过去二十多年了。那本书在 1997 年的开源运动初期，提出了一个极具启发性的比喻：软件开发就像建造建筑物，可以是大教堂式的，也可以是集市式的。 大教堂式的开发由少数人精心设计和构建，强调规划和秩序；集市式的开发则是开放的、分散的，强调试错和快速迭代。

在那时，Eric S. Raymond 讲的是同一套代码，落在不同组织方式里会长成完全不同的东西：在大教堂里，它是由少数“高端建筑师”关起门来雕琢的作品；在集市里，它是被一群摊主和路人不断摸索出来的结果。大教堂强调秩序、规划和统一愿景，集市强调碰撞、试错和快速反馈，这两种模式后来几乎成了“精英开源协作”和“分布式开源协作”的隐喻。

在非常广泛的例子里，我们确实看到了这两种模式的存在。但随着时间的推移，开源世界的格局已经发生了很大的变化。我们仍然可以用大教堂和集市来描述不同的项目，如 GNU 是大教堂，Linux 是集市；BSD 是大教堂，Apache 是集市；Emacs 是大教堂，Perl 是集市…… 这个二分法在当时的开源世界里非常有说服力，也成为了很多人理解开源的基础框架。但它们之间的界限已经变得模糊。

二十多年过去，软件世界看起来无比“开源化”：GitHub 上仓库指数级增长，Linux、Python、Node.js 这些基础设施几乎统治了一切。但如果把视角从许可证挪到协作方式，就会发现，我们早已不再生活在 Raymond 想象的那个单纯的大教堂 / 集市二分世界里。

开源模式的演变

最早那代开源黑客靠兴趣和声望驱动，代码写给同行看，希望人人都能自由使用软件。

而到了今天，很多项目一出生就带着产品和商业目标——云厂商、SaaS 公司、AI 实验室都在用开源做品牌、做生态、做渠道，结果是很多情况下的治理却越来越像一家公司对自己产品线的管理，而不是一个社区对公共物品的维护。中文社区知名开源爱好者 @tison1096（tisonkun）在他的文章里也提到了“开源诱饵切换”（bait‑and‑switch）：先用宽松开源许可抢用户，再改成更封闭的商业许可，留下一个“纪念版”旧仓库；MongoDB、Elastic 的路径在不少分析里都被当作教材。

在 AI 时代，又催生出了“仅开放权重”的 AI 模型：权重开放、数据和训练配方封闭，社区可以运行和微调，却很难参与模型本身的演化；Llama 和中国公司的开源模型就经常被拿来讨论这个问题。

当然，到了资本发达的今天，用爱发电已经是中性甚至负面的说法了。开发者、公司也需要赚钱，开源也不应该是无偿劳动的代名词，正如 tailwindcss 在 issue 里展现出的困境：他们裁员了 75%（当然实际上是 4 个人里面的 3 位）的维护者，因为没钱了。

在我参与过的 GitHub Accelerator 项目培训中，也大量传授了开源商业化的路径。我并不反对开源商业化，只是想通过这十年的经历，分享一些对开源模式演变的观察和思考，尤其是从协作方式的角度来看，开源世界已经发生了哪些变化，以及这些变化对参与者意味着什么。

大教堂、集市与地摊

如果说大教堂代表“精装修的写字楼”，集市代表“规划好的商业街”，在 GitHub 兴起后这些年的开源项目，实际更接近“夜市地摊”：

  • 任何人都可以摆上一个仓库，贴上开源许可证，就算是“出摊”了；
  • 你永远不知道维护者明天出摊会端上来什么；
  • 维护者今天兴致高就更新一版，明天消失也没什么成本；
  • 用户觉得满足了自己的需求，就付个买一杯咖啡的钱（buy me a coffee），觉得不满足了也可能会当众骂街；
  • 想参与进地摊经济的门槛也相对较低——只要会点 git、会提 issue 开 PR 就行了。

当然，有些地摊的摊主后期发家之后，也会把摊位升级成一个更正式的店面（开一个 org），可能就变成了一个集市；但更多的地摊则是一次性的、无门槛的、充满试错和偶然性的存在。

我愿意将之定义为除开大教堂与集市之外的“开源地摊模式”，我认为这促进了 GitHub 的极大繁荣。

为什么要给出一个新的、甚至有点“低端”的定义呢？因为“集市”——那些稳定运行、多方协作的大项目——门槛已经越来越。正如现实中的集市一样，它需要摊贩有一定的财力、可以长期保持它的货源和摊位，在开源世界里，就意味着它们需要稳定的维护者、清晰的路线图和严格的代码审查流程，这些都偏向有经验、有时间、懂社区潜规则的老手，而不是路过顺手交一个 patch 的新人。

集市的流动性枯竭

Asahi Linux 的故事，是这种结构如何把人推走的一个现实例子。项目负责人 Hector Martin 一边啃 Apple Silicon 这块硬骨头，一边在内核社区里为 Rust 驱动争取空间，最后选择先退出内核维护者角色，再辞去 Asahi 项目负责人，公开表示自己“已经对内核开发流程和社区管理方式完全失去信心”。

他在长文里提到的导火索很典型：

  • 一方面是多年维护带来的精疲力竭，用户期待和现实支持之间的失衡；
  • 另一方面是 Rust for Linux 遭遇的拉扯——有人当面支持、背后翻白眼，技术问题被裹挟进文化和权力结构的冲突。

当所谓“集市”的内圈变成一个只欢迎老江湖、对新技术高度防御、对新人高度苛刻的圈子时，对外看起来还是集市的招牌，内部运行逻辑却越来越像一座座小教堂——有着自己的规则、等级和门槛，甚至是排他性。对于那些想参与进来、贡献点东西的人来说，这样的环境无疑是令人望而却步的。

我自身也有一个例子——2019 年，我排查出 AX88179/178a USB 网卡驱动的一个 bug，写了长文记录现象、复现步骤和修复思路，把补丁发上去之后，邮箱却长时间一片寂静。这个问题并不是小众——后来在 openSUSE 等发行版的补丁说明里可以看到，同样的设备、同样的症状都有人报过，最后在 2020 年被网络子系统的维护者以 e869e7a17798d85829fa7d4f9bbe1eebd4b2d3f6 这个提交修掉，用的也是类似的思路。从系统视角看，这确实是一个“成功案例”：有人发现问题，有人给出线索，有人把补丁合进了主线。但从参与者视角看，它更像是一场单向输出：我完成了那一整套排查和验证，却没有兴趣、也没有精力去维持邮件列表上的人际关系，只为了让“谁来提交这个 patch”这件事有一个更漂亮的故事。我更享受的是创造本身——挖 bug、写分析、做 feature‑based 的 PR，而不是反复 ping 人、追进度、在不同维护者之间斡旋。

维护者精力吃紧

不过这都是可以理解的：开源项目的维护者们，尤其是那些核心维护者，往往是志愿者或者兼职的，他们在工作之余还要投入大量的时间和精力来维护项目，这种负担随着项目的规模和复杂度增加而增加。

Linux 内核就是这个趋势的极端版本。维护者列表很长，治理极其分布式，但 LWN 的讨论和研究都在反复提醒：补丁量年年上涨，真正有决策权、能 push 的人，其实就那么几十上百个。一个补丁从投到合进主线，经常要经历多轮 review、rebase、交叉验证，以月为单位在走。X（Twitter）上的内存管理（mm）子模块的维护者 @silsrc 也曾经吐槽过时长的问题。这的确广泛存在于很多大型开源项目里：维护者们需要处理大量的合并、issue、邮件列表讨论，还要兼顾项目的整体规划和技术方向，这些都需要投入大量的时间和精力。

对维护者来说，这意味着实打实的体力活和情绪劳动：既要审代码、写代码、发版、处理安全问题，又要在邮件列表里解释决策、调解争执、照顾新人的学习曲线。

对贡献者来说，这直接表现为门槛越来越高：

  • 你得会 git、会邮件列表礼仪、会理解子系统的隐性规则；
  • 你得愿意等几个月审查，期间不断根据 review 重写，甚至接受“这方向不行”从头来过。

取决于维护者本身，这甚至还会出现 credit 的纷争，Reddit 上就有一个关于 Linux 内核维护者以代码质量不行否决，然后转头就提交了另一个 commit 来修复这个问题的事情。

换句话说，集市还在那儿，但摊位的准入门槛越来越高，能进入社区的人其实早就被筛选了一轮又一轮。

与个人、公司的利益挂钩

如今越来越多的开源贡献和维护工作，已经和个人职业发展、公司商业利益紧密挂钩了。对于个人来说，参与开源已经成为了职业发展的重要组成部分：它可以提升个人的技术能力、增加行业影响力、甚至直接带来工作机会；对于公司来说，开源已经成为了品牌建设、生态构建、市场推广的重要工具：通过开源，公司可以吸引开发者社区的关注和参与，增强产品的竞争力和用户粘性。我理解，这种利益的挂钩在某种程度上是不可避免的：开源已经成为了软件开发的主流方式，参与开源也成为了职业发展的重要途径，所以它们之间的界限自然会变得模糊。

我个人更加享受的是一群有着共同兴趣的人围在一起，碰撞出一些有趣的想法、代码和 build 的过程，而不是修各种 bug、长期打杂维护，我想要的是能够交出一些功能相关的成果，而不是合并了多少 PR、新增多少行更改（在 GitHub 上，开源维护者在合并 PR 的时候，如果是 squash commit 的话，原 PR 改动的行数也会被计算到维护者的账户）。所以对于各种 SIG、TC、PMC 这些组织结构，我一直保持着距离——工作是工作，开源是开源，虽然它们之间可以有交集，但我不想让它们完全重叠。甚至对于 SIG 的翻译，我也一直觉得应该更注重于兴趣（Interest）小组，而不是大多数的 SIG 实质上在追求的公司或者组织在这方面的利益（Interest），虽然在英文中他们的确长得一样。

在这个章节中，我想分享一些这十年观察到的现象和思考，尤其是从个人参与者的角度来看。

贡献可以量化了，但问题也出在量化上

在开源的早期，贡献的衡量标准相对模糊：是修了个 bug？写了个文档？提了个想法？还是在社区里活跃？这些都可能被视为贡献，但没有一个统一的、量化的指标。但随着开源项目的商业化和职业化，贡献开始被量化了：PR 数量、commit 数量、issue 数量、代码行数……这些都成了衡量一个人对项目贡献多少的指标。这在一定程度上是有好处的：它提供了一个客观的标准，激励人们积极参与，也方便了项目维护者识别活跃的贡献者。但它也带来了一些问题：它可能会鼓励人们追求数量而不是质量，可能会导致一些“刷 PR”的行为，甚至可能会让一些真正有价值的贡献被忽视，因为它们不符合量化的标准。

一个国内的例子是华为——X（Twitter）上 @mawei_spoiler （maweiwei）喷过“为了 KPI 的开源贡献“，引起了不小的舆论——他们的 Linux 资深维护者也会刷一些 typo 的 commit 来保持提交数量，从而完成公司的绩效考核要求。当然，这也是可以理解的：在一个以量化指标为导向的系统里，维护者可能会觉得自己必须要保持一定的提交数量来证明自己的贡献，否则就可能被认为不够活跃或者不够有价值。我们纯兴趣驱动开源的人不屑于修 typo，觉得没有什么意义，并且可能会觉得这种行为很可笑，但对于那些在公司里需要通过开源贡献来证明自己价值的人来说，这可能是一种生存策略。

国外的例子也不胜枚举，比如为了鼓励参与开源，有很多项目会设立一些“good first issue”，这些 issue 往往是一些比较简单、容易上手的任务，目的是为了吸引新手参与。但是有些人可能会为了完成这些“good first issue”而不顾质量，甚至可能会提交一些无意义的 PR 来完成这些任务，从而获得一些“贡献”的认可。这也是量化指标带来的一个问题：它可能会鼓励人们追求数量而不是质量。并且像 Hacktoberfest 这种活动也被一些人批评为鼓励了这种“刷 PR”的行为，因为它的奖励机制是基于提交数量的，而不是基于贡献的质量。

相比之下，Google Summer of Code（GSoC）这类项目则更注重质量：它要求参与者提交一个完整的项目提案，并且在整个夏季期间进行持续的工作和交流，最终由导师评估贡献的质量和影响力，而不是仅仅看提交的数量。我自身在 GSoC 做过两次实习学生和一次导师，我觉得这种模式更好一些：它鼓励参与者深入思考和设计一个有意义的项目，而不是追求数量上的成就感；它也提供了一个更有结构化的学习和成长路径，让参与者能够真正理解和融入开源社区。但是可能作为一个老中，过于严厉了，还在末期评估挂过一个学生，觉得项目的完成度不够高，后面工作后对人的宽容度也提高了，觉得其实只要他在过程中学到了东西、并且积极构建就可以了。在这里对被我挂了的学生表示歉意。当然，这种模式也有它的局限性：它过于依赖提案的质量和导师的评估（并且没有一个统一的标准），可能会让一些有潜力但不善于写提案的人被排除在外。

所以说，贡献可以量化了，但问题也在量化上。我们需要找到一个平衡点，既要激励人们积极参与，也要确保贡献的质量和价值。

二道贩子

在这样一个“贡献可以量化”的世界里，必然也会长出另一种角色——我将之命名为：二道贩子。典型情节是：有人在 issue 里艰难排查出一个问题，写清楚复现、原因和 workaround，本意是想先搞明白方向，再讨论长期方案；还没等讨论展开，旁边就有人把这个思路原封不动打包成一个干净的 PR，抢先挂上自己的名字。

PR 区在统计面板里最显眼：它决定了谁是 “top contributor”、谁有勋章、谁能把这一行写进履历。issue 区却更像真正的自由集市：有试错、有争论、有渐进共识，也有那些最终没能写成补丁的探索。系统本身没有恶意，但默认的记账方式会不断奖励“谁开了 PR”，而不是“谁真正把问题想清楚”。于是，我们在协作链条里看到一种分工：有人负责在摊位上摸索出可行的做法，有人负责把摊位上的经验收购回来，包装成可以计入 KPI 的“贡献”。

我近期就遇到过这样的问题，在 vLLM 项目上。某次我在 issue 里详细分析了一个使用过程中遇到的问题，写清楚了复现方法和 workaround，本意是想和维护者慢慢讨论，看能不能一起设计一个更好的长期方案。很快，一个印度老哥的 PR 出现了，基本沿用了 issue 里的思路，把 workaround 包装成一个可以直接合并的补丁。这是一个典型场景：真正脏手试错的是 issue 里的那一摊人，PR 更像是在边上开了个小批发档，把经验打包成自己的“可量化的贡献”。

我在 X（Twitter）上分享了这个经历，有比较热心的老哥直接去喷了这位印度老哥，我倒觉得也没必要，表示理解：在一个以 PR 数量为导向的系统里，这位老哥可能觉得自己也需要提交 PR 来证明自己的贡献，可能就可以在简历上说自己参与了 vLLM 项目，方便他在 AI 时代找到工作。但类似这样的事情发生多了，我至少学会了利用规则：既然整个系统用“PR 上的名字”来记账，那就要求维护者在合并时加上我的 signed‑off-by，把 credit 至少部分拉回来。当然，这也很依赖于维护者的态度和习惯，如果维护者不愿意加上我的 signed‑off-by，那我也只能接受这个现实。

这并没有改变协作模式本身，但让价值链条稍微清晰了一点：从问题排查，到 workaround，再到补丁封装和最终决策，每一步都有人在付出，只是过去只有最后一步会被系统记下来。

回归大教堂的 AI 时代

AI 带来的 vibe coding，让开源也变得更微妙。表面上，vibe coding 把门槛拉低了：新人可以和模型对话，让它生成一整段“看起来能跑”的代码，很多教程甚至宣称“不用会编程也能做产品”。 但一旦进入真实团队，尤其是内部大教堂式的 vibe coding 流程，新人会发现门槛其实被抬得更高了：资深工程师和模型在私有仓库里进行高频重构，代码演化极快，却缺乏中间层的教学材料——没有细致的 commit 历史、也没有为新人写的设计文档，只有一堆已经长成现在这样的代码和几段难以复盘的对话记录。GitHub 的前 co-founder 创建了一个公司尝试解决这个问题，提供一个“vibe coding 的 git log”，但这只是一个补丁，真正的挑战在于：在 AI 时代，如何设计一个适合新人学习和成长的开源协作模式？

传统开源里，新人至少可以从 good first issue、文档修正、小 bug 修起，一步步往核心靠近；在内部 vibe coding 的世界里，很多“中间台阶”被 AI 一脚跨过去了，留下的学习路径反而更陡峭：你既要学会读和改 AI 写出来的复杂代码，又缺乏一个低风险的练习场景。

这和很多人在 vibe coding 时代对初级开发者的担忧不谋而合：当 AI 可以轻松完成很多基础的编程任务时，初级开发者可能会觉得自己没有什么可贡献的了，甚至可能会觉得自己被 AI 取代了。这也是一个很现实的问题：如果开源项目的维护者和核心贡献者都在使用 AI 来加速开发，那么对于那些没有 AI 资源或者不熟悉 AI 的人来说，他们可能会觉得自己无法跟上节奏了。

如果再叠加上商业开源模式的话，另一个问题也逐渐出现在我们面前：当公司内部可以让 AI 很快修复 bug、添加功能时，更多的改变会发生在大教堂内部，而不再接受外部的开源贡献？这一问题在 GitHub 推出“可以关闭 PR 功能”的特性时，便可管中窥豹——可见一斑。

从这个意义上说，vibe coding 在公司内部强化了大教堂——让那座建筑长得更快、更高、更复杂——而外部的集市和地摊，则更像这座建筑的影子：有人在影子里模仿梁柱的形状，却永远够不到真正决定结构的人，除非加入大教堂的内部，否则就只能在影子里摸索。

结语

开源的世界已经发生了很大的变化，从最初的兴趣驱动、社区协作，到现在的商业化、职业化，再到未来可能的 AGI 变迁，我们看到了一系列新的模式和挑战。大教堂和集市的比喻仍然有一定的启发性，但它们已经无法完全描述当下开源世界的复杂性。

无论是大教堂、集市还是地摊，每一种模式都有它的价值和局限，我们需要学会在不同的情境下灵活地运用它们，同时也要警惕那些可能会导致排他性、过度商业化或者技术垄断的趋势。开源的未来，仍然充满了无限的可能性，我们每个人都是这个未来的塑造者。

当 Vibe coding 让很多事情触手可及，做一些只有作为人类才能完成的事情——build、设计、决策，甚至是社区管理——就变得更重要了。我们需要思考：在 AI 时代，什么样的开源协作模式才能真正促进创新、包容和可持续发展？我们又该如何在这个新的世界里找到自己的位置，继续为开源贡献力量？

希望大家不因噎废食，不因为开源的问题就放弃开源和自由软件，继续在开源的道路上探索和前行。无论是作为维护者、贡献者还是用户，我们都可以在这个不断演变的开源世界里找到真正属于自己、而不是社会评价体系的价值和乐趣。共勉！

参考链接

这里放一些文中提到的链接，由于不是严肃论文，就不按照学术规范书写和标注啦。有些遗漏的会慢慢补上：

InokiComputer Scientist

Ph.D in Computer Science, major in Embedded System and AI.