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

跟许多开源开发者一样，我也一直在围观Redis通用条款授权的评论（
https://news.ycombinator.com/item?id=17814386）。其主旨是，由RedisLabs开发的特定企业级模块上的工作成果将采用Apache 2.0和通用条款授权（Common Clause license，简单来说就是个新的授权方式），这种授权方式将禁止主机提供商、云服务提供商以及其他直接从中获益的软件开发商免费使用redis。Redis以后还是主要在RedisLabs的赞助下进行开发，并采用更自由的BSD-3-Clause授权。

最初似乎产生了“Redis要采用新授权”的误解，不过后来Salvatore（antirez）辟谣了。

尽管产生了误会，但我不认为社区的怒火是由此产生的。RedisLabs的文章关于Redis自身的授权说得并不模糊。在我看来，即使Salvatore出面澄清，也无法平息社区怒火。他们没有诚实看待开发开源软件并获得成功的话题。

简单来说，Redis还将继续获得投资支持，而这种支持必然是某种资助。

去年我讨论过依靠开源软件创业的困难（
https://www.influxdata.com/blog/the-open-source-database-business-model-is-under-siege/）。事实上，OSS一直在获得某种资助，要么是人们免费提供的时间，要么是其他成功的企业提供的帮助。在过去几年内开源架构的创业变得越来越难，因为云服务提供商席卷了整个基础架构软件市场。这正是RedisLabs决定改变授权方式的原因。从商业角度来说，他们的决定很正确，而且更重要的是这有益于Redis开源项目的长期生存。为什么说有益于长期生存呢？因为长期生存意味着不间断的投资，而这些投入的钱和时间必须有来源。我们来快速浏览下资助开源项目的几种方式。

最常见的资助方式就是开发者们免费贡献的时间。也就是说，每个人都可以在晚上和周末的时间写代码、写文档。通常，人们只能在工作之外进行这种活动，因为大家需要去做全职的软件开发工作才能养家糊口。这种模式无法扩展，甚至连小型的代码库都无法支持。如果你有一个代码库，不管是复杂还是简单，都需要持续投入精力去修改bug并改进功能。否则就只能封存代码了。靠自由时间来维持的大项目就更糟糕了。

更现实的方式是，让一些成功的企业使用开源代码。Facebook和Google成功的广告业务催生了大量重要的开源项目。但是，这种项目通常都有隐含的动机。例如，Google在Kubernetes上投入了巨大的精力，那是因为这是对他们最有利的做法。这样做能把软件放在云平台中商品化，从而让他们有能力对抗目前市场上占据垄断地位的AWS。了解你喜欢的开源项目背后的组织动机很重要，因为如果公司的经济状况改变，他们就有可能终止对项目的支持。而没有任何资助的OSS项目肯定维系不了太长时间。

正因为如此我们才有了开源核心。一个公司在制作一个开源的项目（核心）后，在该项目的基础上构建私有软件，使用商业授权，或者提供服务。这显然是RedisLabs追求的方式。这也是许多开源软件公司使用的模型。闭源软件可以利用其本身的收益用来推动开源软件的发展。

最后，还有咨询和售后支持，但我认为这是条死路。对于个人开发者的小规模项目也许可行，但想用这种方式创业却行不通。更多情况下，选择其他的成功开源项目进行咨询工作会更现实。如此一来，开发者们就可以按小时向客户收钱，而不用为雇主免费工作。

Envoy的创始人Matt Klein曾在Twitter上讨论过基金会的模式。简单来说就是把开源项目交由基金会负责管理，开发活动由基金会的资金来支撑。但我认为这种方式也无法扩展，也有同样的问题，也就是找不到持续的资金来源。看看CNCF的付费会员，或者由CNCF运营的CloudNativeCon的赞助商吧。当然他们都在为CNCF付钱，但这些钱要么来自那些试图在CNCF项目的基础上创业的公司的风投，要么来自一些希望招募CNCF开发者的大公司，或者是希望围绕CNCF的项目赚钱的大公司。而且，这种方式也需要项目有一定的规模，一般项目需要数年时间的投入才能达到这种规模。

我自己很喜欢Matt的作品，也很喜欢Matt本人，因此并不想挑剔Matt。但如果Lyft（目前他在Envoy项目上的赞助商）停止对他的资助会怎样？他需要找个新的赞助商，毫无疑问他能找到，但难点在于要保证赞助商对待Envoy项目的动机与他个人的动机一致（我感觉他个人的动机就像OSS社区一样纯洁高尚）。也就是说，Envoy的生死依然需要依赖那些成功的科技公司为开发者提供全职的薪水。

这让我想到了另一个关于开源软件的不能说的话题，那就是某个组织“拥有”一个项目，通常等于这个组织雇佣了最多的项目贡献者。RedHat很清楚这一点，所以他们经常收购流行的OSS项目。风投也知道这一点，所以他们或者砸钱圈地，或者收购热门开源项目的主要贡献者。

开源核心实际上是个很靠谱的开源软件开发方式，只要你能明确哪些开源、哪些闭源。在InfluxDB，我们的分水岭就是，任何与高可用性或集群扩展有关的代码都作为闭源商业产品，而任何单服务器的代码都作为开源代码（最近我们也把一些网络代码移动到了开源范围内，我一会儿会讨论）。

指责RedisLabs先吸引用户再换授权是完全不公平的。他们多年来一直在资助开源Redis的开发，这部分工作成果现在是BSD授权，以后依然是BSD授权。他们并没有吸引很多人使用Redis然后再釜底抽薪。我敢肯定，99.99%的Redis用户不会受到任何影响。而对于受到影响的人，他们已有的代码也不太可能无法使用。据我所知，授权没办法应用到过去的软件上。所以，这里的讨论范围实际上只有特定模块的未来发展（并不包括Redis的核心）。

Redis是个非常优秀的软件。我在许多项目中都使用它，也在会议上讨论过它，也会把它推荐给别人。我的行为不会因为这次声明而改变。它给我带来的唯一影响就是，我认识到了RedisLabs很渴望保证公司的长久和Redis项目的长久。你要不喜欢他们的做法，可以自己开个分支自己决定方向。

所以，在惊诧之前，先看看RedisLabs在纯BSD授权的Redis上做出的持续努力，别只会以讹传讹。

在软件开发这一行，大多数软件实际上就是两个字：取舍。想做个分布式系统？要么选AP，要么选CP，鱼和熊掌不可兼得。想做发布？要么发布最关键的功能，要么选择更重要的时间线。我认为，对于开源授权模型和开源资助模型也是同样的取舍二字。

对于开源授权模型来说，取舍就是你要决定人们能拿你的软件做什么。如果选择了MIT或Apache2授权，就得做好心理准备，人们能拿你的软件为所欲为，包括用来赚钱。但是，正是因为人们可以为所欲为，所以建立大型社区并吸引更多人贡献也要容易得多。如果更希望保证任何对代码的贡献能留在社区中，可以选择GPL2或AGPL。其代价就是限制了商业应用。

这里讨论的授权和取舍也适用于资助模型。开源软件必须有资助模式。我不认为有包治百病的灵药。开源核心、大公司的产出、基金会、双授权，都是合理的资助模式。

最后，我认为开源社区需要冷静下来想想OSS开发的实质。

这项工作并不是免费的，它会消耗人们的时间、努力和热情。其中最后一点是我深有体会，因为我知道多年来的持续贡献是多么不容易。这一切都不是免费的，如果像RedisLabs这样的公司在将Redis的某一部分商业化的过程中碰巧为免费的、宽容的BSD授权的Redis做出了贡献，那他们依然应当被肯定，而不应该受到攻击。

原文：
https://www.influxdata.com/blog/its-time-for-the-open-source-community-to-get-real/

作者：Paul Dix

译者：弯月，责编：郭芮