副标题：或者，实现一键赞助的圣杯
原文作者：vriad.com/about
发布时间：2020年7月29日
请看这里的HN讨论。
本文已被翻译成日文。
现有的开源资助模式对小项目并不适用。
大项目--操作系统、框架、CMS或完全可自我托管的应用程序--处于特权地位，可以从用户，尤其是企业用户那里获取更多价值。由于整个API和产品都是建立在它们之上的，所以它们能激发足够的欣赏性（或者，更有可能是对过时的恐惧！），从而从一次性或每月的捐赠中获得可持续的收入。¹
但大多数OSS项目并不大。GitHub 上的典型项目最好被描述为实用工具 - 一个恰当的术语，因为这些项目在世界中扮演着基础设施的角色。它是一个小工具，它能很好地完成一件事。在构建一个复杂的应用程序的过程中，你可能最终会使用几十个这样的实用程序--它们会为你节省数百小时的开发时间。
不幸的是，像这样的实用程序很少能从捐赠中带来任何有意义的资金，无论它们是多么广泛的使用或受到喜爱。考虑一下 reacter-router。即使在GitHub上有4.13万颗星，每周有3M次从NPM下载，并且在基于React的单页应用中几乎被普遍采用，它每年也只能带来约1.7万美元的捐款。
问题的根源在于，开源捐款是以每个项目为单位²。如果要通过GitHub Sponsors或OpenCollective来支持一个项目，你必须为每个你想支持的项目再创建一个自动更新的月度订阅。此外，在关键时刻（"我要赞助X！"），很容易 "逻辑化 "地让自己放弃捐赠（"但如果它下周被一些新的热门项目取代怎么办？"）。这对开源的捐赠总额有很大的抑制作用。最后，只有那些巨大的、疯狂的、无可争议的有用的项目才会得到资助。而这些项目通常都是 "大项目"--框架、自托管软件等。
我们需要一种新的模式，一种适用于中小型项目而不仅仅是大型项目的模式。因此，我提出了一种新颖（-左右）的OSS可持续性方法。
引入 "赞助商池"
- 每个月，您都会向 "钱包 "中捐献一些金额。
- 您的资金会被分配到您的 "赞助商池 "中的项目。你的赞助池就是你想支持的一组开源项目。
- 将新项目添加到你的赞助池中应该只需要点击一下--就像在GitHub上启动repo一样简单。
就是这样。这并不巧妙，这也是为什么没有一个开源软件的主要玩家实现它来促进开源捐赠的原因。³
这将实现开源软件可持续发展的圣杯：一键赞助.⁴一旦一个人资助了他们的赞助商池，只需要一键就可以在财务上支持另一个项目。**支持额外项目的边际成本--包括心理和财务成本--将降为零。**这是一个游戏规则的改变。
为什么这样做效果更好
为什么我认为这将大大增加对开源的捐赠总额？要回答这个问题，请考虑一个假设性的问题。
你愿意每年将收入的多少捐给开源软件？
我猜测读到这个帖子的典型高薪HN网友（👋）得出的数字是数百美元。比较一下你实际捐了多少钱--有区别吗？对我来说是有的。那是因为目前还没有办法对 "开源软件 "这个抽象的概念进行捐赠。但有了赞助商池，捐赠金额将反映出对上述问题的诚实回答。
GitHub
在我看来，最好的情况是GitHub原生支持这种模式，作为GitHub赞助商的延伸。这里是大多数项目的生存地，所以它最有条件建立这样一个零摩擦的捐赠系统。
当然，如果GitHub实现了这样的功能，他们很可能会将捐赠机制从星星中剥离出来。或许，对于已经创建并资助了赞助池的用户，可以用一个 "添加到赞助池 "按钮来代替当前的 "赞助商 "按钮。
添加到赞助池按钮
GitHub有一个经济上的激励机制来改用这种方式--算是吧。他们目前正在吃掉GitHub赞助商上所有交易的处理费用。因此，如果你以1美元/月的价格赞助一个项目，维护者就能得到1美元/月......而GitHub则向信用卡公司支付0.3美元。捐款规模越大，意味着GitHub支付的费用比例越小。
请注意，我说的是按比例缩小。如果处理的捐款总额更多（这是这个提案的目标！），即使费用与捐款的比例更小，他们最终可能还是要支付更多的总费用。如果赞助商池的概念大获成功--比如说，每年累计捐款 10 亿美元--GitHub 将会吃掉近 2000 万美元的卡费。我猜想这将会激起微软的一些怒火。
最后补充一点--我很想看到可嵌入的 "徽章"，在不同级别的捐赠者身上解锁。想象一下，如果你在某人的网站页脚看到一个 "GitHub赞助商金徽章"，表明他们每年为开源捐款1000美元以上。点击这个徽章会把你带到一个可信的网站，让你验证这个说法。这是我在徽章设计上的快刀斩乱麻的尝试。
有些人可能会喊 "美德信号"，但像这样的方法是建立正向强化循环的一种行之有效的方式，a)提高意识，b)鼓励更多的人捐赠给开源。
总结
这是一个困难的问题，有大量的潜在解决方案。我并不是要批评任何现有的方法；它们都为维护者做了很多工作，包括我自己，我并不是要贬低这一点。在构建这样的东西时，也可能存在我不知道的重大实施或监管障碍。这仅仅是一个假设性的练习。
我每隔一个月左右就会写这样的提案。把你的电子邮件放在盒子里，让未来的建议送到你的收件箱。✌️
脚注
¹一些财务上成功的大型项目的例子。
- 操作系统。红帽、基本操作系统
- 框架。Livewire, Next.js
- CMSs: Ghost, Wordpress
- 全功能的应用程序。Sentry、Blender、Discourse
² 值得注意的是，目前GitHub的赞助实际上对应的是某个用户或组织，而不是某个仓库或项目。
我认为赞助池本身由项目而不是用户或组织组成是很重要的。如果多个实体/组织被列为某个项目的维护者，这就变得很复杂。需要有一个机制，在一组维护者之间按照他们认为合适的方式来分配所收到的捐赠资金。
³ 有人向我指出，Flattr使用的正是这种模式! 遗憾的是，他们并不是专门为开源软件准备的，根本没有足够的意识去真正动用。为了让这种模式发挥它的潜力，需要由一个可见的、值得信赖的、成熟的玩家来实现。
其他尝试有趣事情的组织。Snowdrift ("众筹"... 非常酷的概念), Flossbank (类似Tidelift的模式), Gitcoin.
⁴ 更神圣的圣杯：零点击的赞助! 这种方式的一个例子是Brave浏览器的基于代币的微支付系统。Brave让你用各种加密货币为你的 "钱包 "提供资金，然后按照你在他们网站上花费的时间按比例分配给创作者。
这是一个伟大的想法，但为了收集必要的信息，监控是必要的。这是由Brave在道德上实现的，但这只是因为他们控制了全部的浏览器体验。要想在各浏览器中实现这一点，就需要一个能够完全访问你的浏览模式的扩展。所以可能是不可能的。
通过( www.DeepL.com/Translator )（免费版）翻译
