Actual Budget 贡献者报酬机制全解从 3 个月试点到永久化的社区资金运作【免费下载链接】actualA local-first personal finance app项目地址: https://gitcode.com/GitHub_Trending/ac/actual本篇以 Actual Budget本地优先的个人理财应用README2025 年 10 月 6 日发布的公告《Continuing to reward contributors》为核心结合仓库中完整的试点提案、正式支付细则、资金治理政策与后续演进公告系统拆解一套社区捐款 → 透明点数 → 按月发放给核心维护者的开源项目可持续运营机制。读完你将掌握点数系统如何设计与计算、预算池如何分配与兜底、经费审批流程如何治理、以及从维护报酬向Bug/Feature 赏金扩展的完整路线图。一、背景社区捐款与看不见的维护工作Actual Budget 社区在 2025 年年中达到了一个关键节点得益于捐赠者的支持项目拥有了稳定的月度资金流入。2025 年 6 月 8 日项目作者 MatissJanis 在《Spending community funds》提案中提出一个常被开源社区忽略的问题——支撑项目运转的隐形劳动评审 Pull RequestPR对 GitHub Issue 进行分类triage与打标签准备与发布版本release这些工作不产出炫目的功能却是所有功能能够被合并、发布的前提。提案的核心主张是承认劳动的经济价值从 2025 年 7 月 1 日起每月从项目资金中划出1,000 美元作为评审津贴池review stipend pool按透明点数系统分给核心维护者。值得注意的是该提案并非单方面决策而是明确设定了社区否决权如果社区存在强烈反对意见项目就不会实施反之才在 7 月启动试点。这一设计为整个制度的合法性奠定了基础。二、试点设计透明点数系统的原始规则试点阶段的点数系统详见试点提案遵循以下规则维度试点规则2025-07 起月度预算池1,000 美元 / 月点数依据按所评审 PR 的大小计算以代码行数LOC作为工作量代理额外点数为 Issue 打标签、整理分类、关闭重复 Issue、管理发布封顶与兜底系统设有上限活动少的月份发放额降至 500 美元支付渠道通过 OpenCollective 处理仅限核心维护者这套设计刻意追求轻量、公平、易管理不引入复杂工时系统而是用 PR 大小代理工作量预算控制在捐款收入之内保证可持续。提案还解释了为什么先从管理类工作做起在引入功能赏金feature bounty或 Bug 赏金bug bounty之前必须先承认并补偿那些让这些贡献得以合并与发布的日常劳动。如果只奖励新功能而让关键行政工作无报酬既不现实也不公平。三、试点结果成功并永久化2025 年 10 月 6 日的关联公告宣布三个月的试点取得了成功。在社区反馈、耐心与持续支持下项目完成了三件事打磨了系统细节——解决了点数跟踪过程中的 Bug验证了模式的公平性与可持续性将贡献者支付制度永久化。永久化意味着三条承诺继续生效核心贡献者将根据其每月贡献继续获得津贴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,0003,500 美元本系统每月分配 2,000 美元净结余 1,0001,500 美元。淡季还足额发放 2,000 美元吗不会。若当月核心维护者总点数不足 20 点总发放额降至 500 美元。忙季会自动加薪吗为保持简单不会自动增加未来将依据参与数据决定是否调整。能否用礼品卡或加密货币支付不能所有支付透明公开不使用任何替代支付方式。现在为功能、Bug 赏金或其他贡献付费吗不当前只补偿维持项目运转的行政工作未来可能扩展。会不会有人刷橡皮图章 PR刷点数理论上可能但项目信任核心维护团队多数核心维护者拥有仓库管理员权限理论上可造成更大破坏团队选择信任其尽责行事。五、资金治理经费申请与审批流程钱从哪来、怎么花由资金政策约束。OpenCollective 资金仅用于与项目直接相关的运营成本包括但不限于域名/托管费用与代码签名证书。报销流程设计得透明而克制非维护者报销必须先找到一位愿意背书champion的维护者维护者在 Discord 的#funding-updates频道发布报销信息包括提交人是谁、用途含对项目益处的简述、最终收款组织、金额尽量用美元除提交人外的所有活跃维护者投票赞成、反对或弃权一周内未投票视为弃权报销必须获得一致同意弃权者除外且至少一票赞成才通过。对于周期性费用提交时须注明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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考