只要握有相应凭证，一个人就能创建 Git tag。Apache 的官方发布则要经过另一套程序。按照 Apache 软件基金会现行政策，一次发布属于基金会的行为：至少三名项目管理委员会（Project Management Committee，PMC）成员须投出具有约束力的 +1 票，赞成票总数须多于反对票；每一名赞成者还须下载已签名的源代码包，核验、编译并测试。投票通常至少开放 72 小时。[2]

发布这条界线，是理解 Apache 治理最清楚的入口。权力由此进入一套可供审查的流程，不再依附于创始人、雇主或仓库所有者。提交者可以修改项目；PMC 负责治理项目，并批准公众最终收到的内容；基金会董事会承担法人层面的监督，同时不会成为统管所有项目的架构委员会。[1][3]

这套程序仍会伴随糟糕的发布、停滞的项目和过度集中的影响力，它无法杜绝这些问题。积极信号来自分层且有名有据的责任，也来自过程留下的证据：投票讨论串、签名源代码制品、委员会名册、季度报告；对于新项目，还有孵化记录。当这些材料显示多人都在运用判断，Apache 模式的治理能力最为鲜明。若程序清晰可见，参与者却只是在履行仪式，这一信号便会减弱。

图片背景：封面照片拍下 2019 年 ApacheCon Europe 的四位圆桌嘉宾，一人发言，其余人侧耳倾听。基金会官方会议很适合讲述治理：Apache 既是一组制品的集合，也是一个社区；权力在其中依赖人们提出论据、听取异议并共同承担责任。[7]

PMC 是项目权力的基本单元

小型代码仓库常把三种角色集中在一个维护者账号下，Apache 则将它们分开。贡献者没有写入权限也能参与；提交者可以修改代码和文档；PMC 成员则是经选举进入委员会的提交者，负责项目治理、发布，以及吸纳新的提交者和 PMC 成员。[1][3]

这种区分直接对应实际责任。合并代码是短期技术操作，发布则把一份以 Apache 软件名义出现的软件包交给公众，也让基金会承担相应责任。因此，具有约束力的发布投票由 PMC 集体掌握。发布经理个人可以准备候选版本，却不能独自赋予其官方身份。同样，基金会成员负责选举董事会；公司成员身份不会自动带来对其他 Apache 项目的技术权力。[1]

这套设计也为雇主的权力划出一条重要界线。Apache 把项目角色称为由同行授予个人的“帽子”，付薪公司无权占有这些席位。商业影响依然存在：一个项目仍会高度依赖某家供应商的贡献者，而个人名义的正式投票也无法证明判断彼此独立。不过，赞助方即使资助多名工程师，也不会自动掌握相应的项目权力。

对采用者而言，真正有用的问题在于相关 PMC 是否仍像委员会一样运作：重要讨论中能否看到多个组织，多人是否能够准备和核查发布，新贡献者是否在逐步进入受信任的角色，决策是否在可长期保存的渠道上得到解释。法律架构给项目留下了展示健康状况的位置，单凭这套架构还不能证明项目健康。

发布投票是软件供应链的检查点

Apache 的发布政策划出了一条比许多用户预想更严格的线。夜间构建、快照或候选版本可用于测试，官方身份则只属于获准发布的制品。获准制品必须包含足以构建和测试软件的源代码、分离式密码学签名，以及按软件包实际内容编写的 LICENSE 和 NOTICE 文件。批准之后，制品经由规范的 downloads.apache.org 分发渠道发布，并永久复制到 Apache 档案库。[2]

投下具有约束力的 +1 之前，PMC 投票者必须核验签名，使用所提供的源代码完成构建，在自己的平台上测试结果，并检查是否符合政策。因此，至少三张约束性赞成票分别对应三次明确的审查行动；三个表情符号不足以满足这项要求。常规的 72 小时窗口，让分布在不同时区的志愿者团队有机会参与。遇到严重安全漏洞修复等特殊情况，投票可以加速；缩短期限的原因须得到说明，这次偏离常规的处理也须上报董事会。[2]

这项程序无法保证构建可复现，也无法覆盖所有安全审查。三名投票者会共享同一个盲点，测试会遗漏某个平台；签名只能证明制品由谁签署，无法证明每一项依赖都安全。即使便捷的二进制包对应已经批准的源代码，它也会引入另一道核验关口。政策的价值集中在更窄的范围内：它明确候选版本何时成为基金会面向公众的正式行为，并在这一刻为具体人员安排责任。

这条界线会改变采购方式。平台团队需要区分 GitHub tag、由身份不明的自动化账号发布的容器镜像、供应商重新构建的版本，以及 Apache 项目官方下载页列出的制品。这些内容各有用途，所经历的批准流程却各不相同。对来源要求严格的团队可以记录源代码归档包、分离式签名、发布投票讨论串和自己的构建结果，由此查验每一步信任依据，避免把“Apache”当作一枚涵盖一切的信任徽章。

董事会监督项目，但不编写项目路线图

每位 PMC 主席同时也是基金会官员，正式职衔为该项目的副总裁。主席负责确保 PMC 每年四次向董事会报告，并回应董事会的问题。报告应说明项目健康状况，包括社区活动、版本发布、法律或商标事务，以及需要关注的问题。刚从孵化阶段毕业的 PMC 在最初三个月里按月报告。[3][4]

这里存在一次有意安排的职责交接。PMC 掌握技术方向；董事会监督非营利法人的事务，并检查委员会是否仍有能力依照公共利益治理项目。主席承担双方的联络职责，其职权有别于项目 CEO。董事会可以要求采取行动，也能以法人权力设立或终止 PMC；日常架构判断仍由项目社区掌握。[1][4]

季度报告是一项低带宽监督手段，这也在设计预期之中。它无法发现每一次充满敌意的评审交流，也无法预知唯一一名发布工程师何时离开。它的价值在于要求项目定期回答另一类有别于“CI 通过了吗”的问题。提交者名册长期停滞、版本迟迟未发、投票缺席、法律事务悬而未决，或人员集中于一家雇主，这些情况都会成为治理事项，从项目日常开发循环之外提出来讨论。

反证条件很清楚：报告若沦为套话，人手不足的同一小群人仍在批准每次发布，报告链在形式上完整，实际运作却已薄弱。主席头衔只提供形式证据；应当观察 PMC 能否尽早提出令人不适的能力缺口，让新贡献者、相邻项目或基金会来得及响应。

孵化检验权力能否延续到代码导入之后

Apache 孵化器常被描述为把代码带入基金会的通道。它更重要的任务，是教会候选社区如何运行这条治理责任链。孵化中的项目称为“podling”，最初三个月每月向孵化器 PMC 报告，此后改为按季度报告。podling 自己的委员会会与导师共同准备报告，并须说明毕业进展和遇到的问题。[5]

这一过程把代码到来与组织准备程度分开考察。技术上出色的代码仓库仍会缺少独立决策的社区、清晰的知识产权记录、规范的发布纪律，或足够多能够承担受信任角色的人。导师可以示范 Apache 程序，却无法凭空创造长久的参与。因此，毕业所证明的是社区已经能够治理顶级项目，不能把它当作功能完整度或商业采用情况的标尺。

独立研究为 Apache 的正式说明补上了一组有用的外部参照。一项 CHI 2024 研究考察了孵化器内 208 个项目通过邮件列表开展治理的情况。研究发现，对于已有明确规定的正式要求，社区往往会遵守；日常治理的注意力却未必集中在相同议题上，制度的正式化程度与项目能否延续之间也只有有限关联。[6] 直白地说，规则可以塑造可见行为，却无法保证一个社区长久存在。

这项发现没有抹去孵化的价值，它进一步说明孵化记录能够证明什么，又有哪些内容超出其证明范围。报告、投票和角色选举表明项目懂得如何在基金会制度内运作。项目要延续下去，仍取决于评审者投入的时间、新人加入的通道、冲突处理、雇主多样性，以及初次代码转移完成后贡献者继续回来的理由。

采用之前如何读取这些信号

有些组织长期依赖一个项目，却无法决定它的路线图，Apache 治理对它们尤其重要，其中包括基础设施团队、公共机构、把相关代码随产品交付的供应商，以及需要上游保持连续性的小型工程团队。这些采用者可以保留自己的制度，同时应有足够的运作能力，能够查验基金会程序公开的信息。

先查看发布环节。确认正在考虑的版本出现在项目官网和 Apache 规范分发路径上；检查近期发布是否有多名约束性投票者，也检查是否有不止一人能够担任发布经理。阅读一次重要变更在开发邮件列表中的讨论，不要只看问题跟踪器。查看最新 PMC 名单，并寻找不断有贡献者进入受信任角色的证据。随后明确组织内部由谁核验制品、跟踪安全通知、测试升级，并在上游进度与你方不一致时维护补丁。[1][2][3]

两人组成的应用团队可以采用官方二进制包，并依靠有支持服务的发行版完成大部分制品核验工作。若平台团队要把一个 Apache 组件嵌入数百项服务，则需要更完整的责任链：固定源代码和签名、内部重新构建或证明、升级负责人、事件联系人，以及为贡献修复预留的预算。即使上游治理健康，受监管产品团队也存在需要商业供应商的情况，因为志愿者 PMC 不会承诺私有的服务等级协议。

反复出现的失效方式清晰可辨。项目可以拥有有效的 PMC，却只有一个人理解发布工具；三张约束性投票会来自利益诉求几乎相同的同事；季度报告会一直显示绿灯，用户群体却已转向官方渠道以外的制品；制作精良的供应商发行版也会跑在上游前面，悄然用公司专属补丁集取代社区来源。

Apache 模式没有消除这些风险，它为采用者标出了观察风险的位置。因此，发布投票比熟悉的羽毛标志或庞大的项目目录更有分量。tag 说明一组字节已经得到命名，投票则说明一个界定清楚的群体已经接受发布这些字节的责任。当多人仍在公开履行这项责任时，治理便成为软件维护面的一部分。

来源

1. Apache 软件基金会，“How the ASF works”——基金会架构、个人角色、PMC 权力、董事会权责范围、异步沟通，以及独立于雇主的“帽子”。
2. Apache 软件基金会，“Release Policy”——官方发布的定义、三张约束性投票、核验职责、72 小时审查窗口、已签名源代码包、许可文件和规范分发渠道。
3. Apache 软件基金会，“Project Management Committee Guide”——PMC 职责、主席与基金会官员的角色、项目报告、发布权力和法律政策责任。
4. Apache 软件基金会，“Board Reporting Guidelines for Project Chairs”——季度健康报告、提交程序、董事会监督，以及新毕业项目的月度报告期。
5. Apache 孵化器，“Incubation Policy”——podling 所受约束、最初三个月的月度报告、此后的季度报告、导师参与和进展报告。
6. Mahasweta Chakraborti 等，“Do We Run How We Say We Run? Formalization and Practice of Governance in OSS Communities”，CHI 2024——对 Apache 孵化器 208 个项目治理实践的独立研究。
7. Jan Michalko / newthinking communications，“ApacheCon Europe 2019 — Day 2”，Wikimedia Commons——文章图片的来源、活动背景，以及会议原始存档照片。