整理 | 华卫、核子可乐
近日,Redis-rs (适用于 Rust 的 Redis 库)的创建者 Armin Ronacher 在该项目的 Issues 区更新了一条评论,表示 Redis 公司正在要求其将项目转让给他们,而他本人最近没有在该项目作出更多贡献、也并不想因商标侵权的争议卷入法律纠纷,所以向其他的项目维护者们求助相关问题和解决建议。
与此同时,Predis 的维护者 Till Krüss 透露,Redis 公司也向他提出了同样的要求。Predis 是一个适用于 PHP 7.2 及更高版本、灵活且功能齐全的 Redis 客户端。
这些消息传出后,一众开源企业家和维护者们都“警铃大作”。
“看起来 Redis 正试图接管所有 OSS Redis 库。Jedis、Lettuce 和 redis-py 宕机了,他们现在正在威胁 redis-rs。”SvixHQ 的创始人兼 CEO Tom Hacohen 率先表示。
紧接着 Percona 创始人 Peter Zaitsev 发出更深的疑问,“它们接下来是否会进行优化以不再与 Valkey 兼容?”
对此,Clipsource 的首席技术官 Erik Hoffman 评价道,“Redis 现在对所有事情都采取了 Wordpress 的态度。任何东西都不允许以 Redis 命名… 这样摧毁自己的社区是悲剧性的。”
开源 Redis 库面临转让 or 侵权难题
以下为 Redis-rs 项目创建者 Armin Ronacher 发布的完整内容:
据 Ronacher 介绍, Redis 公司给另一位 Redis-rs 的项目控制者 Jan-Erik Rediger (@badboy )和他本人都先后发送了邮件。
这是 Jan-Erik Rediger 最先收到的邮件内容:
这是 Armin Ronacher 收到的邮件内容:
现在,Ronacher 最在意的问题是:有人在将这个 crate 和 Valkey 一起使用吗?将该 crate 转让给 Redis 公司是否存在风险?
项目维护者们的解决思路
Redis-rs 作为 Rust 的高级 Redis 库,通过一个非常灵活的底层应用程序接口,方便地访问所有 Redis 功能。它使用可定制的类型转换特征,因此任何操作都能以用户所期望的类型返回结果,能够带来非常愉快的开发体验。
在 Ronacher 的建议请求发出后,有积极的维护者迅速响应并提出了解决办法。
维护者 Dirkjan Ochtman 表示,“考虑到源代码采用的是三条款 BSD 许可(因此可以很容易地进行分叉),我认为最合理的的做法是由当前的团队以新的名称继续使用当前的 crate,而将旧名称留给 Redis Inc。”
Ronache 也马上回应了这一解决思路:
同时,Ronacher 发问道:“如果 crate 要重命名,新名称是什么?我假设显而易见的是将其重命名为 valkey-rs,我们需要了解一下 Valkey 的人对此有何看法,在这一点上,我们可能会遇到同样的情况。”
对此,Valkey 维护者 Shachar Langbeheim 第一时间出现在评论区,表示“我不确定 Redis 团队是否具备所需的 Rust 能力,也不确定他们是否真的关心 crate 的维护。我见过他们的团队为其他语言的 crate 贡献功能,但从来没有在这里做过。”
换句话说,这些项目进入到 Redis 的“保护伞”后,会发展得更好吗?
另一位 Valkey 维护者 Viktor Söderqvist 则向 Ronacher 发出了邀请:“关于新名称的问题,不妨考虑 valkey-rs 并归入 Valkey 项目官方。请注意,Valkey 同样拥有商标并归 Linux 基金会所有。Valkey 项目由来自 6 家不同企业的 6 名开发人员组成的技术指导委员会管理。我们的核心价值只有一个:坚持开源。”
Redis“保护伞”能使社区受益吗?
大家讨论得不可开交之际,Redis 公司的产品经理 Mirko Ortensi 出来说话了,称“让 Redis 及背后社区共同支持并贡献同一个库这种集中力量办大事的思路才是正确的”,但似乎不仅没有得到开源维护者们的认同和支持,还引来了更多的犀利质疑。
首先 Langbeheim 直言道:“你说你想要一个开放的开发社区,但你也想要控制权。我希望你明白,鉴于 Redis 最近在授权方面的行为,这两个目标被认为是相互排斥的。”
另一位 Valkey 的维护者 Madelyn Olson 表示,“我最初的希望是,我们能够同时支持 valkey 和 redis,让它们能够在一个开放的开发社区中继续发展。各个项目之间仍有很多重叠之处,因此将它们分叉似乎有些浪费。”
Redis-rs 项目贡献者 James Lucas 则称,“ 你认为目前 crate 的维护者无法满足这一要求吗?这个 crate 在很大程度上(如果不是主要)是由整个社区的贡献驱动的。我认为没有任何理由认为核心 redis 团队的贡献会在这方面会得到不同的处理,我们不会响应您团队的请求。”
还有人更为直接地表示:“我不相信这个项目在转入 Redis 旗下后会变得更好。在我看来,你们的团队忽视了许多社区讨论和 go-redis 问题。你们关心的是客户,而不是社区或任何贡献者。你可以给予客户支持,但不能给予社区支持。”
这一说法也得到了其他用户的赞同,认为“将该项目转移到 Redis 旗下不会给社区(甚至也不会给公司)带来好处,而只会解决潜在的商标问题。”
来自 Apache OpenDAL 社区的 PMC 主席、ASF 成员 @Xuanwo 则担心,“如果将这一代码仓库转交至 Redis,我担心 Redis 可能会对其协议或者客户端本体做出重大更改,阻止用户使用此客户端访问其他与 Redis 兼容的服务。”其提出,“不知道能不能给 Redis 协议起一个正式的名称,并围绕它建立起一整个生态系统。比如我们可以称之为 xxx,它将与 xxx 和 xxx 相兼容,允许 Redis 同一切与 Redis 兼容的系统进行通信。”
事实上, 与 Redis 类似的问题也在其他开源项目上出现过,但处理情况却截然不同。
例如, Apache Kafka 项目也不在 Confluent 旗下(当然他们不能这样做,因为商标属于 ASF),但他们的做法是积极参与社区活动,通过在社区中的贡献赢得用户信任。与此同时,他们仍然可以为其客户提供支持,他们拥有“官方 Confluent 支持的客户端”。
Valkey 发展势头强劲
长期以来,Redis 已经成为众多开发人员工作流程中不可或缺的组成部分。其受到欢迎的一大原因在于其出色的灵活性,虽然主要作为缓存方案存在,但开发人员也经常将其用作键值存储、数据库和消息队列。如今的 Redis 经过充分发展,已经能够适应各类细分市场的具体需求。
毫不夸张地说,Redis 可能是技术历史上使用范围最广,至少在开发者群体当中得到评价最高的软件基础设施方案之一。
对于此番事件,不少人都在猜测 Redis 公司的出发点:“他们希望从中得到什么?这岂不是只会给自己的用户带来不便吗?”
而被提及最多的就是针对“Valkey 兼容”的担忧,“我怀疑 Redis 会将各种流行的 Redis 库纳入他们的保护伞下,并使它们与 Valkey 不兼容。这似乎是对 Valkey 的防御性举动。”
今年 3 月,在 Linux 基金会宣布支持 Redis 的“Valkey”开源分叉之时,Redis 公司 CEO Rowan Trollope 就对此嗤之以鼻,称其是云服务商为了避免支付许可费而采取的卑劣手段。Trollope 表示,“各大主流云服务商都从 Redis 开源项目中获得了商业利益,因此在基金会内部发起分叉并不奇怪。”
当时,System Initiative 联合创始人 Adam Jacob 公开评价称,Redis“现在有了一位资金充足的竞争对手”。而 Percona 最近公布的调查结果表明,市场对于 Valkey 表现出了浓厚的兴趣。上个月,谷歌宣布旗下 Memorystore 将支持 Valkey,亚马逊云科技也表示将在 ElastiCache 和 MemoryDB 中支持 Valkey。Aiven 于 6 月发布了 Aiven for Valkey。
从 2024 年 3 月 Valkey 发布至今,谷歌搜索趋势显示,该项目的势头总体上优于其他替代方案。当然,这种短期内的关注激增恐怕不可能长期持续。
维基百科搜索历史数据显示,在过去 90 天内,Valkey 的关注度已经达到 Redis 的约六分之一,表现颇为强劲。通过这些指标,可以看到技术社区对于 Valkey 的关注度和参与度都在强劲增长。
Valkey 也在用实际行动表明,它将继续追求自身独有的技术观点与优先事项,而不仅仅是作为 Redis 的开放及兼容版本。随着在该项目首个 8.0 版本中引入 IO 多线程等功能,Valkey 显然不打算去跟 Redis 的风,而是一套拥有自主路线规划能力的强大解决方案。
未来是无法保证的,但若有足够的资金和资源,开源分叉项目或也能够赢得人心和用例量。
参考链接: