当 JavaScript 标准样式 (StandardJS) 项目1决定在安装期间显示广告时，强烈反对迅速而严厉。该项目是一个自以为是的 JavaScript 样式指南、格式化程序和 linter，它也是第一个尝试通过在命令行中插入广告来筹集资金的 npm 项目。 2 “实验”刚开始不久就终止了。 3但是对我来说，这引发了一个大问题：鉴于 StandardJS 只是 ESLint 的一个包装器，它禁用了自定义，StandardJS 对 ESLint 有什么责任？
开源维护者应该能够接受对其工作的赞助，但是该资助项目是否有责任将部分资金传递给它所在的项目？毕竟，如果你的项目的大部分收益是基于别人项目的工作，那么你获利真的公平吗？
当一个项目获得资金来帮助它所依赖的所有项目时，难道没有某种程度的责任吗？
分层的开源生态系统
当人们说“开源”时，它可能意味着任何数量的东西。 Vue， 4构建许多现代 Web 应用程序的 UI 框架，是一个开源项目，每周 npm 下载量为 280 万次； he 5是一个小型 npm 包，可帮助对字符串中的 HTML 实体进行编码和解码，它也是一个开源项目，每周有 1350 万次 npm 下载。你更愿意捐给哪一个？一个人天生就应该比另一个人获得更多的资金吗？
有人可能会说，这两个项目都有责任找到自己的资金。他们都同样有能力建立一个网站来接受捐赠。他们同样有能力向个人和公司寻求资金。他们都同样有能力就他们的项目进行演示以吸引兴趣。但这两个项目之间存在根本区别。
现实情况是，我们生活在一个分层的开源生态系统中。最重要的位置是为那些获得大量知名度和使用的项目保留的。像 Vue 这样面向最终用户的项目（结果对最终用户直接可见，因为用户界面是用它构建的）和面向开发人员的项目（开发人员特别选择使用该项目）得到了很多关注，因为人们分享他们的经验、最佳实践、工具、测试以及其他提示和技巧，以最好地使用该项目。因为 Vue 不断被提及，所以该项目获得了更多的关注，这使得它更容易吸引赞助；因为 Vue 是面向最终用户的，所以使用它的公司更容易理解它的价值主张。公司和开发人员都更有动力在财务上和通过代码贡献来支持这些项目。
另一方面，有一些生态系统项目提供实用程序或低级功能，比如he ，大多数人永远不会听说过。这些项目被公司和开发人员选择使用的项目作为依赖项包含在内，因此处于后台，没有太多可见性。即使公司和开发人员听说了像he这样的依赖，他们会认为它足够重要吗？你能想象找一家公司寻求资金并解释你的实用程序对 HTML 实体进行编码和解码吗？他们可能会认为你在开玩笑，而且无论如何都会大笑。
毫无疑问，Vue 比he需要更多的持续维护和开发，所以he显然不需要那么多资金，但它值得零吗？然而，Vue 依赖于he ，所以显然它对 Vue 有价值。那么 Vue 对he有什么责任呢？
分层开源的后果
我们已经在没有得到适当资助的开源项目中看到了重大的安全问题。 OpenSSL 中令人心碎的错误本质上使网络不安全，直到它可以修复为止。 6当时（2014 年），OpenSSL 每年仅收到 2,000 美元的捐款，并且有一名开发人员在从事这项工作。 OpenSSL 仍然是互联网技术的基础部分，嵌入从 Web 浏览器到 Web 服务器软件的所有内容中，但最终资金不足。最终，Linux 基金会加紧承诺支持，以确保这样一个重要的项目永远不会再没有资金。
更接近 JavaScript 生态系统，faker.js 和 colors.js 的创建者 Marak Squires 因缺乏资金而故意破坏了7个项目。引用他的话说，他“不再会用我的免费工作来支持财富 500 强（和其他小型公司）。”他曾尝试建立一个 GitHub Sponsors 帐户和一个 Open Collective 帐户，但仍然无法赚到足够的钱。
如果像 OpenSSL 这样的互联网安全基础部分多年来一直因缺乏资金而苦苦挣扎，那么您认为对话会如何要求赞助 faker.js（一个用于创建假数据的项目）和 colors.js（一个项目将颜色和样式添加到控制台应用程序中）会消失吗？
严酷的现实是，并非所有开源项目都有相同的融资机会。那么我们怎样才能期望这些项目能够生存下来呢？
以强大的力量…
项目分层这么清晰，说每个项目都应该负责自己的资金，太容易了。如果一家公司有一个开源赞助预算，那么像he这样的软件包几乎没有机会与 Vue 竞争这些资金。 Vue 将在 99% 的情况下获胜。当扩展到所有开源项目时，我们最终会得到少数获得大部分资金的大型项目，然后是大量获得很少或没有资金的小型项目。而当大项目依赖小项目时，这是不可持续的。单个损坏的低级依赖项可能会给整个较大的项目及其所有用户带来风险。
这个问题的解决方案真的很简单：开源项目应该资助他们自己的依赖。我什至会说这不仅是解决问题的最佳方案，而且事实上，那些更大、资金充足的项目有责任支持它们的依赖关系。开源的精神是对构建您的软件的那些部分给予认可，并且没有任何理由不能将认可扩展到资金。
JavaScript 生态系统中有几个项目每年收到超过 100,000 美元的捐款，包括：
- 通天塔8 – 303,000 美元
- Webpack 9 – 250,000 美元
- ESLint 10 – 190,000 美元
- Vue 11 – 150,000 美元（加上 GitHub 赞助商上的未知金额）
想象一下，如果这些项目中的每一个都拿出一定比例的赞助来给予他们的依赖。在 10% 的情况下，这意味着超过 80,000 美元最终将落入其他无法吸引资金的项目手中。这笔钱将对较小的项目产生重大影响。
切实可行的赞助承诺
实际的依赖赞助计划是什么样的？当然，不能指望一个项目将大部分资金捐给依赖项，我不建议这样做。相反，维护人员可以采取一些简单的步骤来开始：
- 预算将 10% 的资金捐赠给您的依赖项。最好的计划方法就是从一开始就做好预算。在大多数情况下，10% 的资金不足以影响项目的维护和开发。如果在你的情况下它太多了，那么把它减少到 5%。或 1%。重要的部分是您计划开始每月通过预算来支持您的依赖项。
- 从穷人开始，一路向上。在决定赞助哪些项目时，从资金很少或没有资金的项目开始。您可以使用 BackYourStack 12来识别您的依赖项并确定它们是否具有 Open Collective 帐户。如果他们没有设置接受捐赠的机制，您可以随时在 Open Collective 13上向他们承诺，或者联系并鼓励他们建立捐赠方式。最好从赞助一个项目开始，而不是试图将资金分散到多个项目中。当你筹集到更多的钱时，你总是可以赞助更多的项目。把钱捐给已经比你有更多钱的项目是没有意义的。尽管 ESLint 使用了 Webpack，但 Webpack 的资金比 ESLint 多，所以 ESLint 捐赠给 Webpack 没有任何意义。相反，ESLint 捐赠给 lint-staged 等依赖项，这些依赖项的资金要少得多。
- 奖励优秀。除了财务需求之外，您可能还需要添加其他标准来显示项目的维护情况。它有适当的开源许可证吗？它有行为准则吗？除了支持它们之外，您还可以使用捐赠来帮助提升您的依赖关系。
通过这种方式，任何规模的项目都可以为其依赖项的福祉做出贡献。然后，赞助从最大、资金最充足的项目一直沿着依赖树向下流向零依赖包。即使您的项目每个月只收到 100 美元，您仍然可以对另一个没有收到任何资金的项目产生影响。
号召性用语：尽自己的一份力量
如果你是一个资金充足的开源项目的维护者，现在是时候站出来了。很长一段时间以来，我们一直坐下来接受赞助供我们自己使用，即使我们所依赖的项目一直在努力寻找资金。我们有权力和责任为所有开源项目的维护者改善状况。 ESLint 14和 Astro 15已经建立了捐赠给依赖项的计划。你可以和他们一起传播财富。
如果您维护一个需要资金的较小的开源项目，请确定是否有任何资金充足的项目直接依赖于您的项目并联系维护者。随时请求他们的财务支持并参考此博客文章。确保您已设置 GitHub Sponsors 16帐户和 Open Collective 17帐户，以便轻松接受捐赠。不要害怕接近这些人并寻求他们的帮助。他们长期从你的工作中受益，所以你不求回报；你要求赔偿你已经提供的价值。
如果您正在赞助一个开源项目，请询问他们的依赖支持计划是什么样的。发起人在向项目施加压力以适当分配其资金方面处于独特的地位。对于 ESLint 项目，我们从赞助商那里听说我们之所以被选中而不是其他项目，部分原因是我们支持我们的依赖项。与任何市场一样，有钱的人对市场的运行方式有着巨大的影响。
我们都需要尽自己的一份力量，以确保我们正在朝着一个开源生态系统迈进，在这个生态系统中，最有价值的项目不会因资金问题而苦苦挣扎。让我们尽可能开放下游的资金转移。
结论
“我们需要根据我们使用的东西而不是我们看到的东西来资助项目。” – Ben Nickolls，开源集体执行董事
如果我们继续以同样的方式做事，开源将无法生存。依靠每月 5 到 10 美元的个人捐款对于大多数项目来说远远不够生存。唯一的解决方案是企业融资。虽然更多的公司愿意为开源捐款，但他们愿意捐赠的项目数量很少，而且通常仅限于为他们提供最直接价值的项目。那些有幸拥有知名度和思想份额以吸引资金的项目对其依赖负有责任，以确保整个生态系统的生存。如果我们最终能够让公司向少数开源项目捐款，而这些项目反过来又向其他人捐款，我们将帮助将资金分散到整个生态系统，真正创造一条可持续发展的道路。
感谢Fred Schott和Ben Nickolls审阅了这篇文章的早期草稿。
参考
原文： https://humanwhocodes.com/blog/2022/06/sponsoring-dependencies-open-source-sustainability/