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