企业官网建设流程全解析

Actual Budget 贡献者报酬机制全解：从 3 个月试点到永久化的社区资金运作

【免费下载链接】actualA local-first personal finance app项目地址: https://gitcode.com/GitHub_Trending/ac/actual

本篇以 Actual Budget（本地优先的个人理财应用，README）2025 年 10 月 6 日发布的公告《Continuing to reward contributors》为核心，结合仓库中完整的试点提案、正式支付细则、资金治理政策与后续演进公告，系统拆解一套"社区捐款 → 透明点数 → 按月发放给核心维护者"的开源项目可持续运营机制。读完你将掌握：点数系统如何设计与计算、预算池如何分配与兜底、经费审批流程如何治理、以及从"维护报酬"向"Bug/Feature 赏金"扩展的完整路线图。

一、背景：社区捐款与"看不见的维护工作"

Actual Budget 社区在 2025 年年中达到了一个关键节点：得益于捐赠者的支持，项目拥有了稳定的月度资金流入。2025 年 6 月 8 日，项目作者 MatissJanis 在《Spending community funds》提案中提出一个常被开源社区忽略的问题——支撑项目运转的"隐形劳动"：

• 评审 Pull Request（PR）
• 对 GitHub Issue 进行分类（triage）与打标签
• 准备与发布版本（release）

这些工作不产出炫目的功能，却是所有功能能够被合并、发布的前提。提案的核心主张是：承认劳动的经济价值，从 2025 年 7 月 1 日起，每月从项目资金中划出1,000 美元作为"评审津贴池"（review stipend pool），按透明点数系统分给核心维护者。

值得注意的是，该提案并非单方面决策，而是明确设定了"社区否决权"：如果社区存在强烈反对意见，项目就不会实施；反之才在 7 月启动试点。这一设计为整个制度的合法性奠定了基础。

二、试点设计：透明点数系统的原始规则

试点阶段的点数系统（详见试点提案）遵循以下规则：

这套设计刻意追求轻量、公平、易管理：不引入复杂工时系统，而是用 PR 大小代理工作量；预算控制在捐款收入之内，保证可持续。

提案还解释了"为什么先从管理类工作做起"：在引入功能赏金（feature bounty）或 Bug 赏金（bug bounty）之前，必须先承认并补偿那些让这些贡献得以合并与发布的日常劳动。如果只奖励新功能而让关键行政工作无报酬，既不现实也不公平。

三、试点结果：成功，并永久化

2025 年 10 月 6 日的关联公告宣布：三个月的试点取得了成功。在社区反馈、耐心与持续支持下，项目完成了三件事：

1. 打磨了系统细节——解决了点数跟踪过程中的 Bug；
2. 验证了模式的公平性与可持续性；
3. 将贡献者支付制度永久化。

永久化意味着三条承诺继续生效：

• 核心贡献者将根据其每月贡献继续获得津贴（stipend）；
• 透明的点数系统（覆盖 PR 评审、Issue 分类与发布）保持不变；
• 资金来源继续是社区在OpenCollective上的捐赠。

公告强调，这套机制确保"使其他一切成为可能"的维护工作被长期认可与支持。

四、正式制度落地：支付细则与 FAQ 全解

试点转为永久后，项目在贡献者支付正式文档中沉淀了完整的制度细节，与公告互为补充：

4.1 预算池与点数计算

正式文档确认，月度评审津贴池为2,000 美元/月（试点时为 1,000 美元，可见制度在迭代中扩容），按评审者所评审 PR 的代码变更行数（LOC）分配；同时认可围绕Issue 分类与解决的贡献。

点数由项目 GitHub Workflow自动计算，覆盖 Actual Budget 组织的所有公开成员，计算脚本为count-points.mjs（文档原文指向.github/scripts/count-points.mjs，具体点数值以工作流文档为准）。

官方示例计算（完全继承自文档）：

Jack 获得 10 点，Nancy 获得 15 点。 本月总点数：25 每个点数的价值：2,000 ÷ 25 = 80 美元 Jack 获得：10 × 80 = 800 美元 Nancy 获得：15 × 80 = 1,200 美元

这个"按点数值均分预算池"的算法是整套制度的核心：池子固定，参与者越多或越活跃，单点价值越低，天然形成预算自动兜底。

4.2 关键 FAQ（制度边界）

正式文档以问答形式明确了制度的边界，这些细节对理解系统至关重要：

• 收益能否累积？可以，但不能无限累积。每年 1 月 1 日与 7 月 1 日，未提取的收益归零，以减少"已预留但未支付"的记账成本。
• 能否放弃收益？可以。未提交支付申请即视为自动放弃。
• 如何收款？通过 OpenCollective 提交发票（invoice）领取。
• 谁有资格？目前仅限核心维护者，未来可能扩展。
• 税务如何处理？由收款人自行负责，纳税义务取决于当地法律。
• 会不会耗尽全部预算？不会。项目月均捐赠收入约 3,000～3,500 美元，本系统每月分配 2,000 美元，净结余 1,000～1,500 美元。
• 淡季还足额发放 2,000 美元吗？不会。若当月核心维护者总点数不足 20 点，总发放额降至 500 美元。
• 忙季会自动加薪吗？为保持简单，不会自动增加；未来将依据参与数据决定是否调整。
• 能否用礼品卡或加密货币支付？不能，所有支付透明公开，不使用任何替代支付方式。
• 现在为功能、Bug 赏金或其他贡献付费吗？不，当前只补偿维持项目运转的行政工作，未来可能扩展。
• 会不会有人刷"橡皮图章 PR"刷点数？理论上可能，但项目信任核心维护团队；多数核心维护者拥有仓库管理员权限，理论上可造成更大破坏，团队选择信任其尽责行事。

五、资金治理：经费申请与审批流程

"钱从哪来、怎么花"由资金政策约束。OpenCollective 资金仅用于与项目直接相关的运营成本，包括但不限于域名/托管费用与代码签名证书。报销流程设计得透明而克制：

1. 非维护者报销，必须先找到一位愿意"背书"（champion）的维护者；
2. 维护者在 Discord 的#funding-updates频道发布报销信息，包括：提交人是谁、用途（含对项目益处的简述）、最终收款组织、金额（尽量用美元）；
3. 除提交人外的所有活跃维护者投票：赞成（👍）、反对（👎）或弃权（🤷）；一周内未投票视为弃权；
4. 报销必须获得一致同意（弃权者除外）且至少一票赞成才通过。

对于周期性费用，提交时须注明"recurring"；周期性费用自动获批 6 个月，期满后须重新提交审批。这套机制既防止了预算滥用，也为持续性的基础设施开销（如证书续费）提供了低摩擦通道。

六、路线图：从"维护报酬"到全社区激励

6.1 公告宣布的扩展方向

永久化公告在"接下来做什么"中预告了三类扩展：

• Bug 赏金（Bug bounties）——奖励修复长期存在或高影响 Issue 的贡献者；
• 功能赏金（Feature bounties）——激励实现社区强烈要求的重要改进；
• 其他举措——让贡献对所有人（而不只是核心维护者）都更有回报、更可持续。

6.2 后续演进：2026 年 1 月的实施方案

后续的《Next Steps for Funding Contributors》公告披露了更多决策细节：

• 理想方案是定向捐赠（如"我捐 50 美元修这个 Bug"），但 OpenCollective 目前不支持定向捐赠，且此前的第三方工具要么停运、要么方向走偏、要么资金管理不善，故暂不采用；
• 务实替代方案：把现有点数系统扩展到功能类工作——每个被合并的 PR 为作者赢得固定点数，鼓励更小、更聚焦、易评审的 PR；月末汇总合并 PR、代码/文档评审、Issue 分类等活动的点数，按比例分配；
• 为此将月度资金池从 1,000 美元提高至 2,000 美元；
• 对非维护者，共识倾向采用提名制（类似周边纪念品分发方式）与Issue 赏金，而非逐个追踪每笔贡献；
• 同时计划将部分资金捐赠给项目依赖的上游项目或维护良好的插件。

公告也坦诚了顾虑：向所有人付酬可能鼓励低质量或肤浅的 PR，因此需要在"开放给更多贡献者"与"维持质量"之间寻找平衡，并公开征集"如何高效实施赏金而不增加沉重管理开销"的想法。

七、源码与工程佐证

点数系统的自动化并非纸面设计，仓库中留有工程痕迹：

• 正式文档《Paying Reviewers for Administrative Work》明确说明：点数由 GitHub Workflow 自动计算（脚本count-points.mjs），面向 Actual Budget 组织所有公开成员；
• 25.10.0 版本发布说明的 Bugfix 列表包含 PR #5791 "Fix deprecation warning in count-points script"，从侧面印证该脚本在 2025 年 10 月初（即永久化公告前后）仍处于活跃维护状态；
• 公告与配套文档位于 packages/docs/blog 与 packages/docs/docs/contributing 目录，均属于 Docusaurus 文档站（packages/docs/docusaurus.config.js）的内容源。

结语：可持续的开源，不只是代码

Actual Budget 的这套机制，给出了一个值得借鉴的开源可持续运营样本：用透明、轻量、可量化的点数系统补偿行政劳动，用预算池与兜底阈值控制成本，用一致同意投票治理经费，再逐步向 Bug/功能赏金扩展。它把"维护者的时间"也当作一种需要被认真对待的资源，让社区捐款真正回流到让项目持续运转的人手中——正如公告所说：我们不仅是在维持软件，也是在维持软件背后的社区。对希望了解开源治理、或正在为自己的项目设计贡献者激励机制的读者，这份文档连同试点提案、支付细则与资金政策，是一套完整可参考的制度范本。

【免费下载链接】actualA local-first personal finance app项目地址: https://gitcode.com/GitHub_Trending/ac/actual