2025 年 11 月，PHP 解决了一个重要的治理问题：一位 RFC 作者不能仅因耐心耗尽，便把仍在热烈讨论中反复改写的提案匆匆送入投票。项目以 24 票赞成、6 票反对、1 票弃权通过新规，正式规定了最短讨论期、投票前通知、实质性修改后的计时延长，也让投票截止日避开年末假期窗口。[1]

选票之下的另一个问题仍未解决：究竟谁属于选民群体？ 现行有效的投票文档所描述的人群，根基仍是早期拥有 php.net 版本控制账户的人，外加若干来自更广泛 PHP 社区的特选代表。2024 年的一项提案计划以明确的活跃（active）与荣退（emeritus）名册取代这份历史遗产，页面状态至今仍标为 Draft。[2][3]

这种不对称，构成了 PHP 在 2026 年最能说明问题的维护者信号。项目已经把语言变更的节奏写得更加清楚，决策群体的成员资格却还没有达到同等透明度。与此同时，PHP 基金会如今出资聘用的核心开发者已足以影响哪些工作能够启动，基金会又明确声明自己无权控制语言决策。[4] 由此可以看到 PHP 的三种权力：把工作做出来的时间、检验提案的程序，以及投出选票的资格。它们经常落在同一批人身上，性质仍各自有别。

封面照片拍下了 PHP 创始人 Rasmus Lerdorf 出席 2014 年社区大会的情形。[7] 照片里是一位创建者和一场社区大会，治理机构没有入镜，这恰好契合本文。早在现代基金会或持续维护的选民名册出现以前，PHP 的权威已经从贡献者、邮件列表争论、仓库访问权、代码编写与线下聚会中逐渐积累起来。

新时钟把惯例写成公开承诺

2025 年的流程 RFC 从一个令人尴尬的事实出发：PHP 的成文政策已经无法对应资深贡献者所期待的实际流程。若干重要做法只存在于惯例中，新参与者往往到了冲突发生时才会发现；规则写得含糊，也给参与者留下了争辩空间，让人可以声称规则允许走一条更快的路。[1]

获通过的更新让这套未成文程序可以公开查验。如今，每项 RFC 都至少要经历两周讨论，其中也包括不会直接改变语言语法的提案。重大修改需要留出更多审阅时间。作者须在 Internals 邮件列表公布实质性改动，在开启投票前发送投票意向通知，并附上相关的讨论与投票档案。政策也纳入了搁置过久的讨论以及年末时段；后一种情况下，形式上开放的投票足以在实际参与上排除正在休假的成员。[1]

这些规则直接关系到语言变更的效力。RFC 可以定义新运算符、改变类型行为、弃用 API，也可以把兼容性成本推入下一个版本。文本若在临近投票时改动，选民回应的很容易是昨天那份约定。讨论若发生在 RFC 没有链接的帖子里，未来的维护者便难以还原某项取舍为何获准。冷静期为扩展维护者、工具作者、框架开发者与实现人员留出时间，让他们在 Yes 或 No 将提案的公开含义固定下来以前，看清其中的后果。

这次流程更新的投票还展示了一项有用属性：程序本身也要走完它正在修订的程序。6 人反对，1 人弃权；接受结果没有被包装成轻松达成的共识。[1] 这些异议没有削弱规则，反倒留下了社区衡量各项成本的证据，包括延误、作者负担，以及为每一种例外情况制定规则的难度。

沿袭至今的投票政策规定了数值门槛。主要 RFC 投票需要达到三分之二多数：Yes 票数至少是 No 票数的两倍。主要提案越过门槛后，次要实现选项可以采用相对多数制。投票开放时间至少为两周。[2] PHP 现在同时拥有审阅时钟与超级多数制刹车。前者保护投票前的审议，后者确保微弱胜势不足以改变一门使用范围远远超出讨论帖参与者的语言。

选民定义仍然指向过去

同一份投票文档在分母问题上远没有这么精确。它列出两类合格人群：拥有 php.net VCS 账户并贡献过代码的人，以及由这些账户持有人选出的社区代表，例如基于 PHP 的项目负责人或经常参与 Internals 的成员。[2] 这段描述传达了制度意图，却没有给出当前名册、活跃度门槛，也没有规定日常吸纳与移除流程。

这项批评早已来自项目内部。仍处草案状态的 Who Can Vote RFC 指出，原有 VCS 账户系统已经停用，原先设想的社区代表通道也从未成为进入选民群体的实际途径。草案提出的办法，是把 2021 年 8 月至 2024 年 8 月之间投过票的约 140 人列入初始活跃名册，把约 1,650 名早期账户持有人列入荣退名册，再由活跃选民经公开提名和他人附议吸纳新成员。连续三个日历年未投票的选民将转入荣退状态。[3]

这些数字描述的是一项提案，尚未成为现行章程。页面仍是草案，没有投票记录，而且有意把接纳成员的实质标准留给未来的成员群体制定。[3] 若把这套名册设计视为已经通过，提案试图建立的治理区别本身也会随之消失。

LWN 于 2020 年发表的 PHP 治理史，有助于解释项目如何走到今天。仓库凭证一度在缺少严格把关的情况下发放；随着项目采用 RFC 流程、逐渐离开以创始人为中心的决策方式，这些凭证又成了投票资格的依据。参与重大投票的人数远少于理论上符合资格的账户总数，实际权威因此经常掌握在真正参与投票、并愿意为自身立场辩护的贡献者手中。[6] 这段历史既产出了持续运转的软件，也让知名人物在投票中落败；与此同时，制度记忆被绑在了另一个时代为其他用途创建的凭证上。

明确的选民名册不会自动让 PHP 更具代表性。活跃度规则可以清理沉睡的特权，也容易偏向那些因工作安排而有时间追踪 Internals 的人。提名可以扩大参与范围，由选民自行挑选继任者的做法也会复制既有关系网络。至少，公开名册能让这些取舍得到量化。今天，观察者可以统计某项 RFC 的票数，却很难说清谁原本有资格投票、谁刚刚取得资格，以及生态内哪些群体仍在制度上缺席。

受薪时间改变议程，却不改变选票

PHP 基金会构成了第二层治理安排，因为它把捐款转化成开发者工时。基金会的 2025 年透明度报告记载，2026 年初共有 11 名签约开发者；2025 年 PHP 核心提交中约有 42%由基金会开发者署名；赞助商与个人捐助者共计 536 个。基金会报告的捐款总额为 $730,534，扣除费用后实际收到 $645,191，支出为 $784,376。为了在筹款期间维持技术人员规模，基金会有意让当年支出比收入高出约 $139,000。[4]

这些数字显示的是实质性开发能力，所有权并未随之转移。同一份报告声明，基金会既不控制 PHP 的社区决策，也不治理这门语言。签约开发者负责修复缺陷、审阅代码、处理安全工作、编写功能代码，并以个人贡献者身份参与 RFC 讨论。[4] 赞助商买不到选票，基金会董事会的决定也不能把一项语言功能直接并入代码库。

形式上的中立仍然伴随实际影响。受薪时间会决定哪个高难度原型有人编写、哪份迁移分析能够进入邮件列表、哪个长期受忽视的子系统得到审阅，以及哪项已通过的构想有人写成代码。2025 年，基金会资助的开发者贡献了很大一部分核心提交；即使每项 RFC 投票在程序上保持独立，这些劳动仍会改变哪些提案有条件成为现实。[4] 这是根据贡献数据作出的推论，不能用作赞助商控制项目的证据。

这种影响的良性形态，是让议题进入公开议程的能力。签约开发者公开撰写 RFC、披露设计、等待同一段冷静期、回应反对意见，并和其他人一样争取超级多数支持。风险形态比企业接管更不显眼：有时间提出替代方案、审阅基金会资助项目，或在投票开启前挑战某个方向的人太少。流程的正当性依赖两方面条件，一方面要有足够资金维持维护工作，另一方面要保留足够的独立关注来检验这些工作。

2025 年的一次投票把这项区别具体摆在了眼前。基金会签约开发者 Gina Peter Banyard 撰写了一项 RFC，并附有可工作的 php-src 实现，计划弃用函数调用与类型化属性中同 bool 相互发生的隐式类型转换。提案得到 10 票 Yes、11 票 No，最终遭到否决。[5] 受薪时间让这项棘手的兼容性提案完成了规范与代码编写、辩论和测试，却没有让它越过投票关口。与单独一份使命宣言相比，这一结果更有力地证明了机构之间的分离。

因此，报告释放的筹款信号十分重要。赞助参与度较上一年大幅下降，支出按计划超过收入，在支出规模与长期稳定资金之间取得平衡也成了明确的 2026 年目标。[4] 依靠储备金度过一年，可以保护工作的连续性；长期运营仍要建立稳定的资金基础。基金会需要扩大资金来源并维持捐助续期，同时防止大额捐赠者变成隐形路线图的制定者；Internals 也要维持足够广泛的审阅能力，避免受薪完成的代码借助惯性直接转成批准结果。

更强的治理信号会是什么样

PHP 的下一步治理改进不以设立中央技术委员会、取代公开争论为前提。重点在于完成 2025 年那只时钟开启的账目梳理。

首先，无论最终方案是否接近 2024 年草案，项目都需要正式通过一套选民生命周期规则。一项有效的政策应当公开活跃选民群体，为当下的贡献者提供切实可达的加入通道，在保留历史记录的同时终止长期休眠者的投票资格，并记录移除与恢复。其次，RFC 页面应继续把讨论、修订、实现状态和最终投票保存成一条可追溯的链。再次，基金会报告应持续区分受薪产出与正式语言权力，同时披露赞助集中度、签约开发能力、审阅工作和储备金使用情况。

对下游维护者而言，各类状态可以按其实际含义来读。基金会公告表示资源正在流动。标为 Under Discussion 的 RFC 说明约定仍会变化。进入 Voting，说明文本已经抵达定义明确的决策窗口。Accepted 确立了社区批准，具体实现仍未必已经合并。到了发布阶段，这项行为才进入用户所用的软件。若把所有状态一概归入“PHP 已经决定”，谁在何时做了什么便会隐没。

乐观看法也有清楚的证伪条件。如果临近投票的 RFC 改写经常躲过新一轮审阅，选民群体草案长期悬而未决，或者独立审阅能力萎缩，使基金会资助的工作越来越难受到挑战，那么新时钟写进规则的就只剩等待时间，正当性并未随之拓宽。PHP 若能让明确的审议规则配上一套同样明确的选民生命周期，并维持检验提案所需的人力，得到的将超出整洁的治理包装：决策程序中的时间、工作与权力都可以分别查验。

来源

1. Tim Düsterhus，PHP RFC，“Clarify discussion and voting period rules”——2025 年 11 月以 24–6、1 票弃权获通过；涵盖适用范围、冷静期、修订、通知、档案与假期窗口规则。
2. PHP Wiki，“Request for Comments: Voting on PHP features”——现行提案启动规则、投票时长、主要投票三分之二门槛、次要投票与合格人群说明。
3. Jim Winstead，PHP RFC 草案，“Who Can Vote (2024)”——分析沿袭 VCS 账户的投票资格，以及尚未通过的活跃／荣退选民名册提案。
4. Elizabeth Barron，PHP 基金会，“Impact and Transparency Report 2025”，2026 年 5 月 27 日——披露签约开发者、贡献、赞助、财务、治理与 2026 年可持续性信息。
5. Gina Peter Banyard，PHP RFC，“Deprecate type juggling to and from bool type within the function type juggling context”——虽有可工作的实现，仍于 2025 年 8 月以 10–11 遭否决。
6. John Coggeshall，“The history and evolution of PHP governance”，LWN.net，2020 年 6 月 2 日——独立梳理仓库访问、RFC 投票、超级多数制改革、参与情况与贡献者影响。
7. William Stadtwald Demchick，“Rasmus Lerdorf August 2014 (cropped)”，Wikimedia Commons——2014 年 8 月 28 日摄于新西兰 PHP 大会的档案照片。