在过去的几年里，不断有人提出向开源维护人员提供资助的建议。

总体而言，人们提出这项建议有一些很明显的动机：提高开源生态系统的安全性和可靠性，认为这可以解决维护人员不堪重负的问题，最终还会解决开源领域的“搭便车”问题。

在此，我想通过本文逐个探讨一下这些问题，看看提供资助是否真的能解决这些问题。

搭便车问题

简单来说，搭便车问题指的是：有些公司不劳而获，免费使用开源软件，并将其作为利润的基础，却不思回报，赚取不义之财。

事实上，这个问题自古就有，比如“老板”压榨“工人”，没有支付足够的报酬（或压根不给报酬）；再比如贪婪的人类毫无节制地掠夺地球上免费且很有限的自然资源。开源软件特别容易受到这个问题的影响，因为开源的就是免费的，而大多数人都不会花钱购买“免费”的产品。

此外，这个问题的部分原因来自于开源的基本理念。虽然开源的基本理念是自由，而不是免费，但是人们很容易混淆二者（英文单词“free”既有“自由”的意思，也有“免费”的意思）。事实上，从经济学的角度来看，开源对软件行业产生的最大影响恰恰是它的免费。

开源是市场价值的破坏者

很多人认为，开源是市场价值的“破坏者”，但是人们往往不理解，这种破坏性的很大一部分是价值毁灭。我们举个例子：一个古老的开源系统 Linux。

作为一款操作系统（与 GNU 或其他用户空间软件结合使用），Linux 早期与专有的 Unix 展开了斗争。然而，与免费软件竞争利润是不可能的，最终导致该领域的产品一个接一个退出市场或专注于其他产品，如今除了历史遗留下来的产品以及一些小众产品之外，已经没有专有 Unix 提供商了——本质上，操作系统市场中包含的价值已被摧毁了。

曾经苹果创建并拥有利润丰厚的智能手机市场，开拓了 80% 的市场份额，然而谷歌凭借 Android 成功地进入该领域，并扰乱了该市场，基于开源的免费操作系统成功吸引了大量的手机制造商，他们渴望比苹果更便宜的平台。虽然手机市场的价值并没有完全被摧毁，但也大大贬值（智能手机从高利润业务变成了中低利润业务）。

所有这些价值破坏都是通过开源的免费效应实现的，创新者不必承担从零开发一切的全额经济成本，他们只需采用免费开源的代码，然后在此基础之上进行修改。微软以及一些公司声称开源是知识产权的“癌症”，也正是这个原因。

然而，这种观点也是思想僵化和错误导致的，虽然开源破坏了现有市场的价值，但其为新兴市场提供了更丰富的多样性和独一无二的机遇。从经济学的角度来看，价值破坏的主要利益在于降低了门槛，为市场创造更多新机遇，并呈现多样化的竞争（或将垄断市场转变为竞争市场）。

嫉妒并不能解决问题

读完上述内容，你可能会发现，所谓的“搭便车”问题只是开源免费本质的自然结果，就像免费的啤酒一样（有人用你免费提供的东西创造了一个市场，正是因为他们没有为此付出代价），这根本不是一个需要解决的问题，我们应该坦然接受，并加以利用（如果你足够聪明的话）。当然，并非我们所有人都具备商业头脑来利用这样的市场机遇，但即便你做不到，也没必要嫉妒那些“搭便车”的人。

最重要的是，通过某种机制为维护人员提供资助也无法解决这个所谓的“搭便车”问题，因为滥用开源而不思回报的公司并没有实质性的动力。

维护人员不堪重负

近年来，开源社区维护人员不堪重负已成为热门话题，网上涌现了许多博客文章和支持小组。根据我的观察，你是哪种类型的维护者似乎很重要。如果只是业余爱好项目，在时间允许的情况下维护某个开源项目，那么也不至于不堪重负。但如果你是一名全职维护者，那么很有可能被压垮。

我属于前者，所以对于后者只能通过观察，并没有实际的经历。但在我看来，如果交付预期超出你的能力，任何工作（不仅仅是开源维护者）都会压垮你，不断积压的工作和口头抱怨会导致你倍感沮丧。

当有人不堪重负时，常见的解决办法是减轻负担或提供帮助，但我发现全职开源维护人员非常不愿意放弃项目（大概是因为每个项目都是他们核心价值的一部分），所以提供一些帮助、减轻他们的负担是唯一可行的干预措施。

说到这里，虽然有时候最初的本意可能是提供帮助，但我们往往会面临不恰当的需求，从而导致负担又加重：

• 开发者提出问题：“我们人手不足，项目已经落后于计划六周了。”
• 管理者暗自分析：“我不能加人，也改变不了交付日期，只能无视。”
• 开发者得到的结果：“他希望我们汇报每天的进度，直到状况有所改善。”

令我震惊的是，一些备受推崇的开源系统，比如 GitHub，也有一些类似的反面案例，比如鼓励维护人员通过 Star 数展示代码库的价值，统计每日的 PR 以及问题数量，展示每一位访问者，以及去年你为每个项目做出的贡献。

说回重点，我认为提高收入并不能减轻维护人员的负担。虽然金钱能给维护人员带来短暂的幸福感，但日渐积累的工作量很快就会淹没这种幸福感。

如果维护人员已经尽了最大努力，那么给他们更多的钱也不能让他们承担起更多重任。而对于像我这样的业余爱好者，我已经将所有业余时间都投入到我的维护项目中了，即使你给我的报酬超过我的工作收入，我也无法再投入更多时间了。

安全性与可靠性

每个人都希望维护人员提供安全可靠的代码，并在一定的 SLA（服务水平协议）内处理错误报告。但很显然，开源维护人员一般都会尽可能提供安全可靠的代码，但他们不会考虑 SLA 之类的要求，因为没有这个必要（许可中也提到了“无法保证……”），所以付钱给他们也无法提高代码的安全性和可靠性；如果他们已投入所有时间，那么就更无法保证及时响应错误报告了。

那么，如何才能提高开源代码的安全性和可靠性呢？维护人员真正能做的是让保持代码处于最新版本。如果向一个项目提出建议，告诉他们为了安全性，应该将数万行 C 语言代码用 Rust 重写一遍，这不仅是无礼的要求，而且毫无意义。

保证软件安全性与可靠性的关键方法之一是，运行检查程序并进行广泛的单元测试和集成测试。这样做的好处在于，这项工作可以单独进行，不必影响主要的维护工作，当然前提是有人分类并修复发现的问题。

修复是这项工作的关键，如果只是简单地将问题汇报给已然不堪重负的维护人员只能让情况更加糟糕，还会导致越来越多无法解决的问题。因此，如果你正在考虑提供检查程序或测试的资源，请同时考虑如何解决发现的问题，不要加重维护人员的负担。

围绕安全性与可靠性的商业模式

检查并测试代码有一个历史悠久的商业模式，即让发布者来承担这些工作。一些优秀的发布者会向上游发送补丁，他们的商业模式是出售软件（或者提供支持）。但是，这种方式也存在一定的问题，主要是其经济模型上的问题。

首先，你希望得到支持的产品必须是通过某个发行版提供的，这意味着该产品必须有足够多的用户，能够支撑起一个发行版。其次，你最终需要按照实例支付使用成本，也就是发行版中包含的一切的平均成本。其中最大的问题在于每个实例的成本，特别是当你需要超大规模应用的情况下。也难怪有人呼吁将按实例付费改成按项目付费。

如前所述，维护人员需要的是更多的帮助，而不是金钱。一个良好的帮助方式是添加测试和检查（包括修复错误和向上游发送补丁）服务。这必然需要与维护人员联络（并且可能涉及酬金），但我们的目标是辅助维护人员，并避免维护人员被沉重的负担压垮。

专业维护人员

上述大部分内容都假设维护人员已将所有时间都投入到了项目中。如果维护人员只是利用业余时间做开源项目，或者他们是公司员工，部分收入来自于开源项目，部分来自其他收入，那么就向他们支付全额工资，让他们成为全职维护者（这样的话他们就不得不离开当前的工作了），让他们把花在“其他事情”上的时间转移到开源项目上，这看似是一个很好的解决方案。

然而，我们不能忽视从公司员工转变为独立的合同工所带来的各种成本（如医疗保健、税务申报、会计等），这会占用维护人员大量的时间。此外，从兼职转为全职更有可能会进一步加重维护人员的负担，特别是他们需要花费更多时间来管理开源项目，以及咨询业务等相关问题。

总结

通过上述探讨，我们可以得出一个很明显的结果：为维护人员提供更多资金支持并不能达到预期的效果。当然，这只不过是通过最终结果来看待问题。我们不能忽略的一点是，为维护人员提供更多资金肯定会增加维护人员的收入，并让维护开源项目成为他们的谋生手段。

以前，开源维护人员获取收入的唯一方式是积攒好口碑（某个公司付钱让你为他们提供维护服务，或者维护人员展现某个公司所需的技术力），但是如今维护人员多了一个选择，即成为专业的开源维护人员。因此，鼓励大家为开源维护人员提供金钱支持，这可以吸引更多人进入开源生态系统。

总的来说，我认为，为维护人员提供更多资金支持是一件好事，但这应该成为帮助开源贡献者获取报酬的开端，而不是最终方案。