Sourceware 很容易被误认成一批古老主机名的集合。它其实是 GCC、GDB、glibc、Binutils、Cygwin、elfutils、SystemTap、Valgrind 等项目共用的底层基础设施；源码托管、邮件列表、发布镜像和构建节点，都需要长期、严肃的维护，无法只当作随手可取的便利设施。[5] 因此，它面对的治理问题比“谁在管理服务器？”更尖锐：谁可以接收资金、签署合同、选择基础设施合作方并代表平台发言，同时让各托管项目的自主权保持原状？

Sourceware 加入 Software Freedom Conservancy 三年后，现有证据已经足以读出答案。观察对象应从新的 forge 或更大的机器移向一组明确的职责界线：托管项目保留技术独立；项目领导委员会（Project Leadership Committee，PLC）管理共用基础设施；Conservancy 提供法律与财政载体；赞助方投入资源，各项目路线图的席位仍按项目自身规则分配。[1][3][5]

这套安排已经让 Sourceware 从非正式照管走向按预算运作，也让风险更容易辨认。委员会有停摆风险，财政托管机构有成为瓶颈的风险，受赠硬件也带着资源集中的风险。这里的治理要持续运转，前提是各处职责衔接不断产出决定、资金、维护工作与公开证据。

缺失的那一层是授权，Git 一直都在

Sourceware 自 1998 年起运行至今。志愿者懂得如何达成技术共识，也能让开发者服务持续在线，公司与机构则提供硬件、网络容量和托管条件。更棘手的问题在于，怎样在保留社区控制权的同时，让这些支持延续得更久。[1]

这份张力在 2022 年公开显现。当时，Open Source Security Foundation（开放源代码安全基金会，OpenSSF）提出 GNU 工具链基础设施现代化方案，争议随之落在企业影响、安全投入，以及新平台应由谁控制。同期的独立报道显示，社区各方都承认基础设施需要维护，分歧集中于哪一种机构关系既能供给支持，又能让关键工具链免受赞助方支配。[6]

经过九个月的治理讨论，Sourceware 最终于 2023 年 5 月加入 Software Freedom Conservancy。项目组建了八人 PLC，并在财政托管协议中写入雇主多元规则：与同一实体存在经济关系的委员会成员不得超过两人。项目还采用了利益冲突政策。委员会随后开始每月举行公开办公时间，确定优先事项，安排项目资金，并与 Conservancy 员工一起同硬件及服务合作方谈判。[1]

现任 PLC 有七名成员。协议要求成员至少四人，继续维持同一雇主最多两人的上限；成员均以个人身份任职，企业没有派驻代表的席位。[3][5] 这项设计细小，却很重要。Sourceware 正视雇主因素：已有多家机构提供机器、带宽、云容量或付费贡献者工时。项目选择限制雇主代表比例，没有把希望寄托在一项未写明的承诺上，即各方隶属关系永远无关紧要。

PLC 的职责也有明确范围：它管理 Sourceware 共用服务，以及项目与 Conservancy 的关系。GCC 的发布管理、glibc 的维护和各托管项目的技术指导，仍归各项目自身。Sourceware 的使命页面说明，这些项目保持独立，通常也自行管理本项目专用资源。[5] 基础设施权力与代码权力会相互接触，归属依然分明。

财政托管是一项运作接口

志愿者集体有能力合并补丁，数据中心合同和慈善银行账户则需要具名的法律主体。若由一名维护者以个人名义持有捐款，项目也会随之承担此人的税务状况、时间安排、接班风险，以及此人对每笔付款的判断。若商标、域名或服务器租约掌握在一家供应商手中，基础设施分歧就会演变成所有权问题。

Conservancy 的全面财政托管（fiscal sponsorship）模式让项目有了法律归属，成立并管理独立非营利机构的负担也不会落到开发者身上。Conservancy 可以接收指定用途捐款；对符合条件的美国捐款人，这些捐款在满足税法规定时可以抵税。它还可以保管项目账目与资产、签署合同、安排法律协助，并支付合规的项目费用。项目负责人在 Conservancy 的慈善宗旨和法律义务约束下决定资金用途；只要项目处于这一范围内，技术和艺术决定仍归项目自己。[2]

这套服务伴随成本。新成员项目须把 Conservancy 经手收入的 10% 交入其一般基金；Conservancy 表示，这一比例仍不足以覆盖财政托管背后的员工工作。申请页面也提醒，需求已超过有限的人手，因此现有成员享有优先级。[2] 这些事实同样属于治理评估的一部分。项目用一部分收入和一定的交易等待时间，换取记账、合同、延续性、咨询，以及超越维护者个人钱包的法律身份。

退出渠道存在，也伴随约束。项目可以在通知后离开，依照慈善规则持有的资产则必须转至另一家性质相容的非营利机构，个人或普通公司不能接收这些资产。[2] 这项约束明载于规则，也让可抵税的项目资金始终属于公共用途资金。团队在移交域名、商标或储备金之前，应先弄清资产日后的流向。

Sourceware 的案例说明，技术服务商与财政托管机构的区别直接关系到治理。双方的关系聚焦法律与组织事务，Git 设备采购属于另一类服务。Conservancy 让银行、捐款人、法律顾问、会议场地、承包商和基础设施合作方能够识别 PLC 及其权限。源码托管技术栈可以更换，这层组织关系仍可延续。

三年时间把治理转成日常运作

Sourceware 在 2026 年 5 月发布的报告以日常运作为线索，回顾 Conservancy 托管下的第三年：常设 PLC、每月公开办公时间、多家硬件和服务合作方、更广的募款来源、持有资产与签署协议的能力，以及定期公开规划。[3] 这些都属于维护信号，因为它们改变了志愿者能够稳定作出的承诺。

物理基础设施给出了最清楚的例子。2025 年末至 2026 年初，Sourceware 把服务器迁入 Red Hat 的 RDU3 设施和 Oregon State University Open Source Lab（俄勒冈州立大学开源实验室，OSUOSL）数据中心。公共服务如今采用 VM-first（虚拟机优先）模式，取代直接在裸机上运行；另有 x86-64 与 Arm64 OpenStack 容量可用于计算、冗余和备份。[4] 迁移改变了技术架构，协调两家机构托管方并决定支出的能力则来自组织安排。

服务范围十分具体。Sourceware 以 cgit 和 gitolite 运行 Git 托管，以 Mailman 和 public-inbox 运行邮件列表，此外还有 Bugzilla、Patchwork、Buildbot、发布镜像、快照，以及各项目专用的自动化服务。[5] 每项服务都会产生维护工作队列：账户恢复、垃圾信息控制、存储扩容、证书续期、安全更新、滥用处理、备份、迁移和事故沟通。受赠机架留下的这些队列，最终仍要由具名人员和有资金保障的工时处理。

因此，2026–2027 年预算讨论格外重要。硬件更新完成后，PLC 提议把重心从“硬件”转向服务与人力：向 OSUOSL 支付服务费用，聘用员工或顾问升级服务和迁移虚拟机，并资助 Forgejo 上游的实用工作。PLC 先经三场社区预算讨论公开方案，随后发布捐款、赞助与财务页面。[3][8]

随后一份季度更新报告了 84 人参与的调查，估算约占 400 个拥有 SSH 或 gitolite 推送权限的活跃账户中的 20%。约 70% 的受访者自称活跃提交者；人数较少的群体则报告了 Bugzilla、wiki、Forge、Patchwork 或管理岗位。[8] 这份调查的代表性达不到普查标准，Sourceware 对它的定位也止于此。与仅凭流量猜测哪些服务重要相比，它仍是更好的规划依据。回复缺口也指出一项治理任务：决策必须始终区分这批参与最积极的五分之一与全体成员。

独立是一种关系拓扑，孤立是另一回事

Sourceware 依然倚赖外部机构。Red Hat 与 OSUOSL 托管主要系统；大学和公司提供横跨 x86-64、Arm、Power、s390x、SPARC 与 RISC-V 的工作节点；志愿者运行服务；捐款人和企业赞助方资助工作；Conservancy 处理法律事务。[4][5] 这里的成果体现为一种关系拓扑：任何一段资源关系都无权自动控制整个平台或托管代码。

PLC 的同一雇主最多两人规则限制了一条显而易见的权力俘获途径。公开办公时间与财务页面留下观察点。两处数据中心关系和多个计算合作方缓解了部分物理集中。PLC 与托管项目维护者相互分开，也防止基础设施委员会借服务器迁移介入工具链路线图决定。[3][5]

这些制衡都要靠人落实。纸面上的雇主多元与社交关系集中可以同时存在。两座设施尚不足以证明恢复流程经过测试，也回答不了同一赞助方是否同时出现在两条故障链中。公开预算未必列出每项服务所依赖的无偿劳动。Conservancy 的法律能力可以保护志愿者，也会让紧急交易进入一个人员有限的处理队列。

最能推翻这一信号的变化，是治理逐渐失去可查验性：PLC 停摆或成员集中于同一雇主，财务更新停止解释优先事项，公开办公时间中止，重大基础设施承诺在社区审议之前已经作出，或恢复计划在多方合作图上依旧依赖单一捐款人。到了这种状态，财政托管在法律上仍然成立，作为维护信号的价值却已消失。

其他项目该借鉴什么，又该舍下什么

Sourceware 的做法适合这样的成熟项目：以公共利益为使命，拥有活跃的贡献者社区、需要管理的资产或收入、需要签署的合同，以及愿意承担技术责任却不想成为非营利机构行政人员的负责人。若多家商业用户依赖项目，同时又不宜由任何一家公司拥有其机构层，这套做法尤其有价值。[2]

一个只接收少量捐款的小项目，可以合理地认定 10% 分成与全面流程成本过高。达到基金会规模的大型项目体系，可以考虑配置自己的员工和法律实体。尚未形成稳定社区的年轻项目，也未必达到 Conservancy 的接纳标准。财政托管不等于成熟徽章，PLC 也代替不了维护者。

可复用的经验范围更窄。把以下事项写清楚：谁控制共用基础设施，谁可以支配项目资金，雇主关系受到怎样的限制，技术权力止于何处，人员离开时如何处理，以及哪些报告能让外界检验这套安排。随后，为硬件带来的工作队列安排资金。

Sourceware 第三年的信号令人鼓舞，因为文件已经转成日常运作：合作方协议、公开预算、开放会议、多站点迁移，以及把重心转向付费人力的提案。关键工具链继续由各项目维护。它们下面的基础设施如今有了持久的合同归属，也有公开负责的人决定一份合同是否应当签署。

来源

1. Sourceware Project Leadership Committee，“Sourceware thanks Conservancy for their support and urges the community to support Conservancy”，Software Freedom Conservancy Blog（2023 年 11 月 27 日）——成员项目决定、PLC 设计、雇主关系限制、公开办公时间、募款与早期运作变化。
2. Software Freedom Conservancy，“Applying to Join Conservancy as a Member Project”——财政托管模式、技术自主、资产与资金处理、10% 收入分成、人员限制与退出范围。
3. Mark Wielaard，“Sourceware @ Conservancy Year Three”，Sourceware 邮件列表存档（2026 年 5 月 16 日）——三年治理回顾、数据中心迁移、财务、PLC 组成及下一年度维护重点。
4. Sourceware，“Sourceware Servers and Services 2026”——RDU3 与 OSUOSL 迁移、VM-first 运作模式、主机清单、OpenStack 容量与备份拓扑。
5. Sourceware，“Our Mission”——现任 PLC 成员与限制、托管项目独立性、财政托管机构的职责范围、服务目录和基础设施合作方。
6. Thomas Claburn，“Sourceware support proposal divides open source community”，The Register（2022 年 11 月 16 日）——关于 OpenSSF 提案、基础设施安全论点及社区对赞助方影响之担忧的独立报道。
7. Sucheta Ghoshal，“Karen Sandler with an Outreachy alum at LibrePlanet”，Wikimedia Commons（2015 年 3 月 22 日）——本文题图所用会议存档照片。
8. Mark Wielaard，“Sourceware infrastructure updates for Q2 2026”，Sourceware 邮件列表存档（2026 年 7 月 5 日）——调查回复数量与角色、社区预算讨论、当前资金重点和 PLC 限制。