开源社区应该认真对待了

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

像许多开源开发者一样，我一直很关注有关Redis通用条款许可的评论（HN线程）。其大意是，RedisLabs开发的某些企业模块将在Apache 2.0 +通用条款许可下（基本上是一种新的许可）进行授权，这将禁止他们被托管和云服务提供商以及其他直接从他们那里获利的软件开发者免费使用。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（他目前的工作赞助商）的支持干涸了怎么办？（他目前的工作赞助商是Lyft，他在Envoy上的所有工作都是由Lyft赞助的）他将不得不寻找新的赞助商，他几乎肯定能找到，但这也会很棘手，因为他必须确保他们的动机与他对Envoy项目的动机一致（这些动机在我看来在开源社区中是纯洁和值得赞扬的）。Envoy将继续依靠赞助其开发的全职开发者的成功技术公司的慷慨而生存或死亡。

这让我想到了关于开源软件的另一个不言而喻的事实，那就是“拥有”一个项目的组织通常是雇佣了最多为其做出贡献的开发者的组织。RedHat知道这一点，这就是为什么他们经常收购流行的开源项目。风险投资家也知道这一点，这就是为什么他们会像石油淘金一样抢购土地，要么资助，要么让他们的投资组合公司收购任何热门新开源项目的主要贡献者。

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

指控RedisLabs进行了钓鱼式诈骗是完全不公平的。他们已经资助了多年的开源Redis开发，现在和将来都将遵循宽松的BSD许可证。他们并没有像欺骗一大群人使用Redis然后从他们脚下抽走东西一样。我相信99.99%以上的Redis用户完全不受此影响。而对于其他用户，已经存在的代码并非不可用。据我所知，他们不能反溯性地应用许可证。所以我们真正讨论的只是针对特定模块的前向开发（而不是Redis核心）。

Redis 是一款出色的软件。我在多个工作中都使用过它，也曾在会议上做过关于它的演讲，并向他人推荐过它。这份公告并没有改变这一点。它唯一做到的是表明 RedisLabs 在确保公司长期发展以及 Redis 自身方面非常积极。只要 RedisLabs 存在并且盈利，他们就能资助和支持开源 Redis 的开发。不喜欢他们的方向？您可以进行分支操作，甚至可以在您采取行动时使用当时最新的内容。在您开始恐慌之前，让持续在纯开源 BSD 许可的 Redis 上的开发来指导您的观点，而不是一些恐惧的煽动。

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

在开源许可中，权衡的是人们可以如何使用您的软件。如果您选择了像 MIT 或 Apache2 这样的许可，您必须准备任何人都可以使用您的软件，并做他们想做的任何事情，包括从衍生作品中获得比您更多的收益。然而，由于他们可以随意使用它，因此更容易建立一个更大的社区并吸引更多的人参与。如果您关心确保任何从您的代码中获益的人都将其贡献回社区，您可以选择 GPL2 或 AGPL。那里的权衡是您限制了可能希望用您的代码建立企业的开发者的商业选项。

那里的许可和权衡通常会影响资金模式。开源必须以某种方式获得资金。我认为没有一刀切或银弹的解决方案。开源核心、大企业消耗、基金会和双重许可都导致资助开发的各种模式。

当我们开源软件时，InfluxData 会考虑这些权衡。例如，我们选择以非常宽松的 MIT 许可证许可我们的新语言 Flux。Flux 还包含用于通过网络查询开源 InfluxDB 服务器的代码，这超出了我们通常区分开源与封闭的范围。然而，我们的目标是尽可能广泛地采用和贡献，这意味着我们希望开发者将其用于娱乐项目、商业项目、建立公司以及所有介于两者之间的内容。这意味着我们准备让他人从 Flux 的存在中获利。

我用一系列里程碑来衡量将 Flux 带入世界的过程。首先是将语言提供给 InfluxDB 用户。第二是让 Flux 的用户超出 InfluxDB 本身的环境。第三是看到其他开源项目将 Flux 作为语言采用。最后是看到公司（和竞争对手）将 Flux 作为语言采用并从中获利。我们准备应对所有这些，因为这是我们正在努力工作的开源项目取得成功的样子。然而，这并不妨碍我们继续在 InfluxDB 商业版本中开发闭源软件，以从中获得收入来资助这种开源开发。

最终，我认为开源社区需要深呼吸，并思考 OSS 开发的现实。这项工作不是免费的，它消耗人们的时光、精力和热情。最后一点我在个人层面上与之相关，因为我欣赏多年持续努力可能带来的压力。这些事情不是免费的，如果一个像 RedisLabs 这样的公司同时在商业化 Redis 的某些部分的同时，还向免费可用的宽松 BSD 许可的 Redis 贡献了大量，那么他们应该受到赞扬，而不是被攻击。