捐助者赏金：一种新型的功能赏金

我们之前曾撰文论述赏金如何损害开源项目，因为即使赏金的主题符合项目维护者的意愿，它仍然会以牺牲合作为代价助长竞争，并且总的来说，它只是提供合同工作的更糟糕版本，因为当事情不按计划进行时，赏金往往会导致潜在不公平的解决方案，等等。

正如我们过去也曾指出，这只是一些特定类型赏金的问题，而非全部。一个积极的例子是错误赏金（bug bounties），在这种情况下，工作的非协调性远非一个大问题（或者至少它是一个问题，而不是系统的一个“特性”）。

社交媒体上的评论指出，我们所遇到的这类赏金通常被称为“功能赏金”（feature bounties）。

因此我们进行了一些思考，并找到了一个方法来弥补功能赏金的所有缺陷。这项改变微乎其微，却极大地改变了赏金的性质，那就是：资金不再提供给实现者，而是作为捐款捐赠给开源项目本身。

通过将赏金提供给开源项目，开源工作的合作性质得以完全保留。当然，将资金给予项目而非具体执行工作的人，这在性质上截然不同，但当项目由一个支付开发人员薪资的非营利组织运营时（例如 Zig 软件基金会），这样做就非常有意义。

我想把这种新型赏金称为“捐助者赏金”，并将其作为一项服务提供给 Zig 项目的支持者。以下是它的实际运作方式

您可以通过 donations@ziglang.org 联系我们，表达您希望为某个已接受的提案提供捐助者赏金的意向（即同时带有 proposal 和 accepted 标签的 GitHub Issue）。
我们内部会讨论该功能是否适合此流程（例如，没有尚未解决的设计问题），以及当前是否是合适的时机。
如果双方同意继续，我们将讨论捐赠金额、预期时间表，并发布捐助者赏金公告。
如果在赏金截止日期前，工作完成并合并到 Zig 中，您将捐赠商定的金额。

需要注意的一点是，我们接受捐助者赏金的门槛很高：我们只接受针对已接受提案的捐助者赏金，即使如此，我们也只会在该功能从多个角度来看都合适时才同意设立捐助者赏金，包括我们有高度信心该功能在语言未来的迭代中被取消的风险非常低，因为捐助者赏金不保证该功能将成为 Zig 最终设计的一部分。

捐助者赏金并非个人与 Zig 软件基金会之间的合同协议；它们是建立在双方互信和善意基础上的。

我们也很高兴地宣布，我们已经接受了首个捐助者赏金！

此致，
Loris Cro