开源社区是时候面对现实了

作者：Paul Dix / 公司, 开发者
2018 年 8 月 22 日

像许多开源开发者一样，我一直在饶有兴趣地阅读有关 Redis Common Clause Licensing 的评论 (HN 讨论串)。要点是，RedisLabs 开发的某些 Redis 企业模块将根据 Apache 2.0 + Common Clause 许可证（基本上是新的许可证）获得许可，这将禁止托管和云提供商以及其他直接从中获利的软件制造商免费使用它们。Redis 将继续主要在 RedisLabs 的赞助下，根据自由的 BSD-3-Clause 许可证进行开发。最初似乎有一些关于 Redis 本身正在被重新许可的困惑，Salvatore (antirez) 一直在 试图 澄清。

尽管存在这种困惑，但我认为社区的愤怒并非主要由此驱动。RedisLabs 的帖子并没有含糊其辞地说明 Redis 本身的许可。我认为即使澄清了这一点，社区的大部分愤怒仍将持续存在。我认为大多数真正阅读 RedisLabs 帖子的人都明白发生了什么。他们只是没有对自己诚实地说明开发和推动开源软件成功的现实。简而言之，这需要持续的投资，而且必须以某种方式补贴。

去年我谈到了 基于开源软件构建业务的困难，以及开源软件始终通过人们的空闲时间或其他成功的业务来补贴的事实。由于云提供商持续进军整个基础设施软件市场，在开源基础设施领域建立业务变得更加困难。这正是推动 RedisLabs 做出此许可决定的原因。他们的举动对于业务以及更重要的开源 Redis 项目的长期发展都是有意义的。为什么我说这对 Redis 的长期发展有意义？因为长期发展意味着持续投资，而资金和时间必须来自某个地方。让我们快速回顾一下补贴开源项目的不同方式。

开发人员的空闲时间通常是它的起点。这意味着个人在晚上和周末编写代码和文档。这通常是在全职软件开发工作之外进行的，而全职软件开发工作最终支付了他们的账单。这种模式不可扩展，我认为即使在库的小规模上也不是一个有效的选择。如果您有一个任何复杂程度的库，都需要持续的努力来修复错误并使其发展。否则，您最终会将其锁定并密封为“完成”。如果您有一个更大的项目，那么由空闲时间贡献驱动的现实甚至更糟。

更成功的方法是让开源成为其他一些成功业务的副产品。Facebook 和 Google 产生了大量的开源项目，这些项目主要由成功的广告业务补贴。但是，这些项目经常有隐藏的动机。例如，Google 对 Kubernetes 进行了大量投资，但这也有利于他们的经济利益。它使云平台软件商品化，这为他们进入目前由 AWS 统治的市场提供了完美的楔入点。了解驱动您喜爱的开源项目的组织的动机非常重要，因为如果财务现实发生变化，他们对该项目的支持可能会枯竭。而一个没有任何支持的开源项目注定会在一段时间后消亡。

然后我们有开放核心。一家公司生成一个开源项目（核心），然后在该项目内部或周围创建专有软件，他们将其作为服务进行许可或提供。这显然是 RedisLabs 正在追求的模式。这也是我们在 InfluxData 采用的模式，以及许多其他开源公司采用的模式。从闭源软件获得的收入推动了开源方面的持续改进。

最后，我们有咨询和支持，我认为这是一个死胡同。它当然在个人开发者的小规模上有效，但在试图建立公司时就会崩溃。大多数时候，您最好选择一些其他成功的开源项目，并围绕该项目建立咨询实践。然后，您的开发人员可以向客户收取工时费，而不是编写代码，而这些代码不会为他们的雇主带来任何经济活动。

Envoy 的创建者 Matt Klein 在 Twitter 上争论基金会方法。基本上，将开源置于基金会的管理之下，并由该基金会的拨款资助开发。但是，我认为这不可扩展，并且存在确定补贴来源的相同问题。看看 CNCF 的付费会员或 CloudNativeCon（由 CNCF 运营）的赞助商。他们当然从所有这些中带来了资金，但这要么是由初创公司试图围绕 CNCF 项目建立业务的风险投资推动的，要么是由大型成功公司试图雇用开发人员或追求他们自己围绕这些项目的经济利益推动的。此外，这假设了所讨论项目的某种规模，这通常需要多年的投资才能达到。

我不想过多地批评 Matt，因为我是他的作品和他本人的忠实粉丝。但是，如果 Lyft（他目前在 Envoy 上的所有工作的赞助商）的意外之财枯竭了会怎样？他将不得不寻找新的赞助商，他几乎肯定会找到，但这也很棘手，因为他必须确保他们的动机与他自己对 Envoy 项目的动机一致（就我所见，这些动机在 OSS 社区中是纯粹和值得称赞的）。Envoy 将继续依靠成功的技术公司提供的慷慨支持而生存和消亡，这些公司通过全职开发人员的工资来赞助其开发。

这让我想到关于开源软件的另一个不言而喻的真相，即“拥有”一个项目的组织通常是雇用最多开发人员来为此项目做出贡献的组织。RedHat 知道这一点，这就是为什么他们经常收购流行的 OSS 项目。风险投资家也知道这一点，这就是为什么他们进行淘金热式的土地掠夺，以资助或让他们的投资组合公司收购任何热门新开源项目的主要贡献者。

开放核心是开发开源软件的一种相当诚实的方式。只要您清楚地说明什么是开放的，什么是封闭的。在 InfluxDB 中，我们的分界线是，任何与高可用性或横向扩展集群相关的内容都作为闭源商业产品保留，而单服务器领域中的任何内容都是开源的（但我们最近一直在将一些网络代码移至我们的开源中，我稍后会谈到这一点）。

指责 RedisLabs 做了诱饵和转换是完全不公平的。多年来，他们一直在资助开源 Redis 开发，这项工作现在和将来都将根据自由的 BSD 许可证进行。这不像他们欺骗了一群人使用 Redis，然后抽走了他们的地毯。我确信超过 99.99% 的 Redis 用户完全不受此影响。对于其他人来说，已经存在的代码并非不可用。据我所知，他们不能追溯应用许可证。因此，我们实际上只讨论对特定模块（而非 Redis 核心）的未来开发。

Redis 是一款出色的软件。我在多个工作中都使用过它，我曾在 会议上就此发表演讲，并且我向人们推荐过它。此公告不会改变这一点。它唯一的作用是向我表明，RedisLabs 积极主动地确保公司的长期发展，并随之确保 Redis 本身的发展。只要 RedisLabs 存在并且盈利，他们就能够补贴和赞助开源 Redis 开发。不喜欢他们的方向？您可以 fork，甚至可以使用您进行该操作时的任何当前版本进行 fork。在您开始惊慌失措之前，让纯开源 BSD 许可的 Redis 的持续开发来告知您的观点，而不是一堆危言耸听的言论。

在软件开发中，我们认识到软件中的大多数事情都与权衡有关。开发分布式系统？必须选择 AP 或 CP，并决定哪个权衡适合您。尝试发布版本？必须选择真正重要的功能或更重要的时间表，更多权衡。我认为开源许可和开源资助模式也是如此。

在开源许可中，权衡是关于人们可以使用您的软件做什么。如果您选择像 MIT 或 Apache2 这样的许可证，您必须准备好让任何人拿走您的软件并随心所欲地使用它，包括从其衍生作品中赚取比您更多的钱。但是，更容易建立更大的社区并让更多人做出贡献，因为他们可以随心所欲地使用它。如果您关心确保任何获取您的代码的人都将其贡献回社区，您可以选择 GPL2 或 AGPL。那里的权衡是，您限制了可能希望使用您的代码构建业务的开发人员的商业选择。

这些许可和权衡通常会融入资助模式。开源必须以某种方式资助。我不认为这有一个万能的或银弹。开放核心、大型企业副产品、基金会和双重许可都导致了资助开发的模式。

InfluxData 在开源软件时会考虑这些权衡。例如，我们已选择根据非常宽松的 MIT 许可证许可 Flux，我们的新语言。Flux 还具有通过网络查询开源 InfluxDB 服务器的代码，这超出了我们通常划分开源与闭源的范围。但是，我们的目标是尽可能广泛地采用和贡献它，这意味着我们希望开发人员将其用于有趣的项目、商业项目、建立公司以及介于两者之间的一切。这意味着我们已为其他人从 Flux 的存在中获利做好准备。

我通过一系列里程碑来衡量我们让 Flux 进入世界的成功。首先是让 InfluxDB 用户使用该语言。其次是让 Flux 的用户在 InfluxDB 本身之外的上下文中使用。第三是如果我们看到其他开源项目采用 Flux 作为一种语言。最后是如果我们看到公司（和竞争对手）采用 Flux 作为一种语言并从中获得收入。我们为所有这些做好了准备，因为这就是我们正在开发的这个开源产品的成功之处。但是，这并不妨碍我们继续在商业版本的 InfluxDB 中开发闭源软件，我们从中获得收入以补贴这种开源开发。

最终，我认为开源社区需要深吸一口气，思考开源软件开发的现实。这项工作不是免费的，它需要人们的时间、精力和热情。最后一点是我个人感同身受的，因为我理解多年的持续努力可能会带来多大的负担。这些东西不是免费的，如果像 RedisLabs 这样的公司碰巧将 Redis 的一部分商业化，同时仍然为免费提供的许可 BSD Redis 贡献大量内容，那么他们应该受到赞扬，而不是受到攻击。