有一种流行叙事把开源描写成「纯洁社区 vs 邪恶公司」。
它好用，但常常失真。
更贴近制度史的说法是：公司进入开源之后，权力从「志愿声誉」与「合并门文化」旁边，又长出一套「工时、路线图与合规」的硬杠杆——两边并不总是对抗，很多时候是共生；但共生也会重写账本。
赞助与基金会：钱从哪来，议程就从哪长
Linux Foundation、Apache Software Foundation、CNCF……各自章程不同，不能一锅炖。共同点只有一层：
当基础设施级项目需要全职维护、会议、认证、合规与品牌，钱就必须来；钱一来，议程设置就会变重。
这不等于腐败叙事，而是一个朴素事实：人类的时间有限，付费工时会挤占志愿工时所能覆盖的议题边界。
读 Apache 的治理自述，至少能拿到一套「基金会如何自洽地解释自身」的官方语言：How the ASF works。
写作纪律是：把每家基金会当作独立样本，用它的公开章程、年报、治理页面做锚，而不是用「基金会 = 洗绿」一句带过。
雇员维护者：同一封邮件，两种忠诚
当一个维护者从「晚上写代码」变成「白天也写代码」，邮件列表里的语气未必变，但风险模型会变：
- 公司的专利组合、产品线节奏、客户合同条款，会进入 ta 的潜意识。
- 「这个补丁合不合」不仅是技术判断，也可能牵动发布窗口与竞争关系。
这不是道德指控，而是组织结构：雇主为员工的注意力买单。
于是社区里会出现一种长期张力：
- 社区想要共同体自治与多利益方平衡；
- 公司想要可预测的上游与可控的合规边界。
「上游优先」口号很政治正确，但落地时仍要问：谁的「上游」、以谁的发版节奏定义稳定？
CLA 与 DCO：不是「仪式感」，而是权利与风险的分配
贡献者许可协议（CLA）与开发者来源证书（DCO）之争，表面是流程，底层常常是：
- 版权归属与追索路径（出现纠纷时找谁）
- 专利暗示与许可范围（是否能覆盖贡献中的隐含权利）
- 公司治理是否要求「可签字的链条」
DCO 的极简文本可见 Developer Certificate of Origin。
本篇不给「CLA 坏 / DCO 好」的站队结论——不同项目、不同法域、不同风险承受度会走向不同选择。只强调一条：
当开源从志愿火堆变成工业默认，流程就会变厚；变厚不一定是变坏，但一定是在重新分配权力。
小结
- 公司与社区最常见的关系不是黑白对立，而是共生中的权力重写。
- 基金会与赞助改变议程设置；雇员维护者改变议题权重。
- CLA/DCO 等流程是风险分配机制，不能用「麻烦」一笔抹掉。
关键人物速览
- Jim Zemlin：Linux 基金会长期公共面孔之一；理解「钱、品牌、合规基础设施」如何叠在 Linux 生态之上，常会在公共材料里遇到他（区分个人与机构叙事）。
- Brian Behlendorf：Apache 软件基金会与 Apache HTTPd 路线的关键人物之一；理解「基金会章程 + 贡献流程」这一治理模板，绕不开 Apache 传统。
- Nadia Eghbal：《Working in Public》等；理解「维护者劳动、可见性与资助结构」的当代讨论，她的研究常被当作入口（属于近史与观察，非 1990 年代一手）。
参考与延伸阅读
How the ASF works | Apache Software Foundation
https://www.apache.org/foundation/how-it-works.htmlDeveloper Certificate of Origin
https://developercertificate.org/The Linux Foundation — About
https://www.linuxfoundation.org/aboutCNCF — About（云原生基金会与「企业—上游」叙事的当代样本之一）
https://www.cncf.io/about/who-we-are/Working in Public: The Making and Maintenance of Open Source Software（图书信息入口）
https://press.stripe.com/working-in-public
下一篇进入 法庭与合规：当邮件列表说不通，诉状与和解结构会把争议翻译成另一种语言。