跟许多开源开发者一样,我也一直在围观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
译者:弯月,责编:郭芮