译自 Dries Buytaert 博客原文：Open Source is a cost-allocation system（2026 年 8 月 27 日）。

开源通常被描述成一种许可模式、一种开发模式，或者一种生产模式。这三种描述都有用，但都漏掉了一点：每一个开源生态，同时也是一个成本分摊系统。

要让软件保持可用、可靠，就需要有人写代码、评审贡献、准备发布、调查安全报告、运营基础设施、写文档、回答问题，还要支持升级和迁移。这些成本总得有人承担。

专有软件的厂商可以把访问权和付费绑在一起：卖出的每一份许可或订阅，都在为开发者、安全工作、基础设施和发布提供资金。

开源打断了访问与付费之间的链接。任何人都可以以任意价格（包括零）再分发这个软件。因此付费不是使用或再分发的前提，而这些权利本身也提供不了"持续资助生产与维护"的机制。

但把付费和访问分开，并不会让成本消失。成本被分摊到维护者、雇主、基金会、赞助者和用户身上。维护者可能贡献自己的时间；雇主可能付钱让开发者去贡献；基金会可能运营基础设施。

由于这些成本是被分摊的，而不是通过某一笔交易收上来的，它们更难被看见，也更难被筹到钱。

技术选择往往会决定这些成本落在哪里。这种分配不总是有意为之；它可能慢慢从一个个单独看都合理的决定里长出来，几年之后才变得显眼。

Drupal 的更新服务最近给了我一个很好的例子。Drupal 站点会定期联系 updates.drupal.org，询问 Drupal 本身或已安装的任何附加组件有没有新版本。Drupal 把这些附加组件称为"贡献项目"，比如由社区成员维护的模块和主题。

当前的设计是：给 Drupal 自己发一个请求，给站点上每一个贡献项目各发一个请求。所以一个装了 100 个贡献项目的站点，每次检查更新会发出 101 个请求——默认每天一次。

当初这么设计是有道理的。每个项目的发布历史可以存成静态文件，被反复请求，而不必为每次请求重新生成。这个设计直接，而且管用。

但 Drupal 长大了。今天 updates.drupal.org 每月要响应将近十亿次请求。仅 Drupal Core 发布历史那个文件本身就有大约半兆字节。按这个文件的请求量估算，光是 Drupal Core 的更新检查，每月可能就占掉大约 50 到 75 TB 的流量。贡献项目的流量还要再加在这上面。

没有人主动选择让 updates.drupal.org 每月传输几十 TB 的发布数据。这个量级是随着 Drupal 长大逐渐出现的，来自一个在生态还小的时候完全合理的设计。

部分难点在于：在开源里，受益的人、决策的人、承担成本的人常常不是同一批人，而且他们彼此之间可能没有任何正式义务。

站点所有者从可靠的更新通知中受益，通常并不为此向 Drupal 协会付费。Drupal 协会的员工在运营更新服务，协会承担它的流量和基础设施成本。但决定站点如何发出这些请求的代码住在 Drupal Core 里，改动它需要 Core 提交者参与。Core 提交者并不向 Drupal 协会汇报，所以协会没法自己改掉这个行为。

在实践中，Drupal 协会的员工和 Core 提交者合作得很紧密。这种协作之所以重要，正是因为决策权和成本承担分属不同的群体。

承担实质成本的人，需要一条途径让这些成本被看见、并影响决策——即使他们并不掌控决策。

这个例子说明了为什么每一个开源架构同时也是一个成本分摊系统。好的治理会在事前考虑这种分配，持续观察它的影响，并在它变得不可持续时重新审视它。

因此，理解一个开源系统，需要的远不止理解它的代码或许可证。我们还需要理解：随着系统成长，谁受益、谁决策、谁承担成本。一旦这些关系变得可见，一个社区才能判断这种分配是否可持续，或者架构是不是该改了。