做者 | Colin McDonnell
译者 | 弯月，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）react
现在的不少开源融资模式并不适合小项目。web
操做系统、框架、CMS或彻底可自我托管的应用程序等大型项目占据了主导地位，可以从用户（尤为是企业用户）那里得到更多的资助。因为不少API和产品都创建在这些项目之上，所以他们能够经过一次性或按月支付的捐赠得到持续性的收入。react-router
可是大多数开源软件项目的规模都不大。就GitHub上的大多数项目而言，考虑到在全世界基础设施方面发挥的做用，它们只能算是实用程序。在构建复杂的应用程序的过程当中，你会用到不少这样的实用程序，这些工具能够帮助你节省大量的时间。框架
不幸的是，这类的实用程序不多可以经过捐赠筹集到大笔资金，不管它们的使用范围多么普遍，也不管有多少人喜欢它们。好比说：react-router，即使在GitHub上得到了4.13万颗星，每周经过NPM的下载次数高达300万，并且基于React的单页应用程序的采用很是广泛，但这个项目每一年只能得到1.7万美圆的捐款。svg
问题的根源在于开源捐赠是以项目为单位。若是你想经过GitHub Sponsors或OpenCollective支持项目，则必须为每一个你想支持的项目单首创建一个自动续订的订阅。更大问题的是，即使你决定“我要赞助X！”，也很容易说服本身放弃捐赠，由于你会担忧“可是万一下个月我换成了另一个热门的新工具呢？”这极大地抑制了对开源的捐赠总数。最终，只有那些对全部人都有很大贡献的项目才能得到资金。这些项目一般都是大规模项目，好比框架、可自托管的软件等。工具
咱们须要新的融资模式，适用于中小型项目，而不只仅是大型项目的融资模式。所以，我想提出一种可以保证开源软件得到持续性融资的新方法。测试
每月，你向一个“钱包”捐款。网站
你的资金会被分配到“赞助池”中的各个项目。你的赞助池指的是你想要支持的一组开源项目。操作系统
只需单击一下鼠标就能够将新项目添加到你的赞助池中，就像在GitHub上给某个代码库加星同样简单。翻译
仅此而已。这个方法几乎没有什么独到之处，因此我有点惊讶为何主流的开源软件开发商至今没有为了促进开源捐赠而实现这个方法。
这种方法能够实现开源软件持续性的终极目标：一键式赞助。在某人创建了赞助池之后，只需单击一下鼠标便可支持另外一个项目。支持其余项目的边际成本（不管是心理上的仍是财务上的）都将降至零。这彻底能够改变现在的局面。
为何我认为这种方式会大大提升捐赠给开源项目的资金？为了回答这个问题，请考虑一个假设的问题。
你愿意每一年为开源软件捐赠多少资金？
我怀疑有些潜水的隐形富豪会说几百美圆吧。但你实际捐赠了多少呢？这是由于目前咱们没有途径给“开源软件”的抽象概念捐款。可是，若是有了赞助池，那么实际的捐赠额度就不会与你上述给出的数目相差太远。
我认为，最好可以将这种模型做为GitHub Sponsors的扩展。由于大多数项目的代码库都在GitHub上，所以GitHub是构建这类捐赠系统的理想之选。
固然，若是GitHub实现了这样的功能，那么他们极可能会将捐赠机制与给星分开。也许，建立了赞助池并进行了资助的用户可以看到的按钮会从“Sponsor”（赞助者）变成“Add to Pool”（添加到赞助池）。
GitHub有必定的经济动机换成这种方法。目前他们须要负担起GitHub Sponsors交易的全部处理费用。所以，若是你每个月向某个项目赞助了1美圆，那么项目的维护人员可以得到1美圆，同时GitHub还须要向信用卡公司支付0.3美圆。捐款额度越大，GitHub承担的费用就相对较少。
请注意，我说的是相对较少。若是处理的捐赠总数很大，即便费用较少，那么最终他们须要支付的总费用仍然很高。若是赞助池的概念成功（好比每一年累计捐款10亿美圆），那么GitHub须要承担近2000万美圆的信用卡费用。我相信这动了微软的奶酪。
最后，我但愿看到不一样程度的捐赠可以得到一些徽章。想象一下，你在某人网站的页脚中看到“GitHub赞助金徽章”，则代表他们每一年向开源捐赠的数额超过1000美圆。点击这个徽章，你就能够进入某个受信任的网站，并经过这个网站验证徽章。下面是我快速设计的一个徽章：
这种方法能够有效地创建积极的强化循环：a）加强意识；b）鼓励更多人为开源捐款。
开源软件的融资是一个难题，并且拥有大量的潜在解决方案。我并不想批评现有的一些方法，毕竟他们为开源作了不少工做，并且我也不想扼杀他们的努力。此外，实现我提出的方法还有不少我不知道的难题或法规障碍。本文只不过是一种设想罢了。
我但愿Youtube Red也有这样的机制。每一个人都有本身的赞助池。各个频道应该以观看时间来计算，这样一些小频道也能拿到捐赠。若是我观看了一个频道，那么这个频道就应该得到我捐赠的10美圆。
然而实际上，Youtube Red只有一个全局的赞助池，而且按照全局的流行度分配赞助，因此赞助主要流向了那些网红，即便我并不看他们的频道。对于那些观看数不足百万的频道，这点赞助收入彻底抵不过没法播放广告而致使的损失，所以这种赞助并不能起到资助的做用。
我但愿你提出的这个模型不会出现这个问题。若是有100我的愿意每个月支付10美圆来支持两个项目，那么这两个项目应该分别得到500美圆（减去交易费用）。这笔钱不该该转移到Angular、React、Vue等等，致使这两个项目每月只能拿到5美圆的零花钱。
我认为有两个问题。
首先，这样的模型已经存在：Flattr和Liberapay。后者不得不放弃赞助池的模式，由于实际上当你采用赞助池模式时，你实际上就是一家银行，这在法律上有必定难度。
其次，只有当用户实际访问你的的网站或Github时，这种模型才起发挥做用。目前我正在开发一款面向最终用户的应用程序，我敢打赌他们中有90%的人从未使用过Github，甚至不知道Github是什么。
我认为这个想法很是棒，但必需要说明一个事实：只有GitHub采用这个想法，它才能成为现实。
但别忘了，就连Github的赞助功能都仍在beta测试中。但尽管如此，你仍是不得不填写各类税务表格。
我想提一个小建议，赞助和赞助池能够并行采用。我相信，成为某个开发者的赞助者，以及成为开源世界的好公民并支持一些项目，这两个想法并不冲突。
我能够赞助一名开发者，知道他把我列为赞助者之一，我会以为很高兴；同时我也愿意每月支出一笔钱，来赞助个人项目中用到的全部工具，缘由仅仅是由于这样作能让这些项目活得更久。这是两种彻底不一样的出发点。
大概更重要的是，GitHub能够把大部分交易处理费用放到赞助，对于赞助池则仅扣除3%做为交易处理费用。我以为绝大部分人都不会反对这种作法。
对此，你怎么看？
原文：https://vriad.com/essays/a-new-funding-model-for-open-source-software 本文为 CSDN 翻译，转载请注明来源出处。