---
author: Peter Pang
date: '2026-02-06'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=ImxpVGVM9n0
speaker: Peter Pang
tags:
  - open-source-governance
  - community-contribution
  - software-licensing
  - developer-career
  - strategic-open-source
title: Redis与Valkey分家内幕、开源权斗及新人入门指南
summary: 本期《原桌会》专访中国开源界T0级大佬朱彬彬，深入探讨了Redis从开源转闭源，以及Valkey项目迅速成立的幕后故事。朱彬彬揭示了Redis公司决策的法律与治理原因，并分析了Valkey在Linux基金会下快速发展的因素。对话还触及了云厂商在开源项目中的竞争策略、中国企业在国际开源社区的参与现状，以及个人开发者如何系统性地参与开源项目、积累经验的实用建议，强调了开源的战略意义和深度学习的重要性。
insight: ''
draft: true
series: ''
category: software-development
area: tech-engineering
project: []
people: []
companies_orgs:
  - Redis公司
  - Linux基金会
  - 腾讯云
  - AWS
  - Google
  - Oracle
  - 华为
  - 阿里巴巴
  - Microsoft
  - Apache基金会
products_models:
  - Redis
  - Valkey
  - Node.js
  - io.js
  - MongoDB
  - MySQL
  - Nginx
  - Kafka
media_books: []
status: evergreen
---
### 节目开场与嘉宾介绍

**主持人**: 欢迎收看我的新系列节目《原桌会》。在这个系列里，我会动用自己小小的人脉，邀请一些业界大佬来聊一些大家会感兴趣的技术话题。而第一期的嘉宾，就是中国开源界的T0级大佬：**朱彬彬**。彬彬现就职于**腾讯云**，他是前**Redis**成员，**Valkey**的创始成员和现任核心。在本期节目里，我们会聊到**Redis**和**Valkey**的分家内幕、国际级开源项目的日常八卦、中国人和中国企业在开源领域的现状，当然还有彬彬是怎么样一步步成为开源大佬的经验分享。这里他给了很多很实用的建议，如果你对参与开源项目感兴趣，那就请务必认真听了。那么事不宜迟，我们现在开始。

### Redis闭源决策内幕

**主持人**: **Redis**从开源改成闭源这件事情，你们是完全不知情吗？都是**Redis公司**自作主张做的决定吗？

**朱彬彬**: 对，这个事确实是**Redis公司**直接做的决定。他们当时做决策的时候，只是邮件通知一下**core team**的成员，他就是for your information那种感觉，他只是周知一下你。对其他人都是比较突如其来的，说实话，就这么感觉。

**主持人**: 那我就很好奇了，理论上当时的**Redis**还是一个开源项目，那他怎么能够在开源的框架下，绕开开源社区，一个公司去做所有的决定呢？

**朱彬彬**: 我觉得这里有两个原因。第一个原因其实就是**Redis公司**它本身拥有**Redis**的商标，还有知识产权、所有权。作者**antirez**应该18年就转让给他们了，所以他们本身在法律上，他们完全能做这个事。因为**Redis**本身也是**BSD3**这种协议，加上他们有这个权利，其实很容易去修改这么一件事。第二点，当时的**Redis**的社区治理，就5个**core team**成员，有3个是**Redis公司**的，这其实占了绝大多数票。另外的话他们其实也没有进行过社区投票之类的，因为当时其实**Redis公司**他们刚换CEO，应该是换了个新的CEO，新的CEO进来一年，然后就操刀把这个协议给改掉，就类似这样子。

### Valkey项目迅速成立

**主持人**: 那么来到**Valkey**这边，3月20号**Redis**改成闭源，3月28号**Valkey**项目就成立了，而且还是在**Linux基金会**下面成立，这个速度有点太快了吧？

**朱彬彬**: 确实比较快，说实话。我觉得快其实有两个原因。第一个原因就是原本那批人，其实在**Redis**社区都比较熟了，包括我跟**Madelyn**还有其他的一些成员都比较熟。第二点也就是**Madelyn**她本身从事这方面的开源工作，她也弄得比较久了。她在**Redis core team**也干过4年，她在open source领域也有很些人脉之类的，所以她跟那些**Linux foundation**和**Apache foundation**这些都会有一些相关的朋友。我看当时协议刚改的时候，她应该是最生气的那一个人。因为我们有个通信工具叫**slack**，**slack**上她当时的名字后面都搞了一个小火花那种爆炸emoji表情在上面，表示她的愤怒这种感觉。确实这个东西在当时确实挺快的，这也超出我预期，我想过确实会弄一个新的，但是我没想到它那么快就能进到**Linux foundation**里。

### 大厂对Valkey的背书与站队

**主持人**: **Valkey**项目不只是成立得快，它这个大厂的背书也背得特别快。在一开始，国外国内的大厂就基本上都已经站队了，这个决策是怎么做出来的？

**朱彬彬**: 反正当时第一个官宣的时候，我们可能当时还没站好队，因为当时我们内部团队也在思考，因为这个东西毕竟是个商业化产品，在云上也会去卖云服务，所以这件事情也不一定说会很快地去判断出来到底要怎么走。所以在中间过程中，**Madelyn**她一直有在问我们，就问**腾讯云**到底要怎么去做，或者问我之类的。但后面就是一周之后，我们团队确定好之后，确实要走**Valkey**之后，我们就已经站队到**Valkey**了，包括后面像**core team**的席位，就第一批的**core team**席位其实都在那个时候定下来了。

**主持人**: 那个时候是选择了两头下注吗？

**朱彬彬**: 当时做好决定就走**Valkey**了，那几天做好决策之后。

**主持人**: 这么坚决啊？我还以为肯定会两头下注呢，因为你们是一个新的项目，而你的对手是一个世界上最主流的KVS。

**朱彬彬**: 一个就许可证的原因，许可证的原因就注定了我们如果说不去谈合作之类的话，其实我们是没办法继续做**Redis**的托管服务。第二点呢，因为当时和其他厂商的朋友大家都比较熟，我们其实私下也一直在讨论这个事。所以对于这么一个社区，因为原本的开发团队基本都在，大家很多都是有云厂商的背景，那云厂商背后的话，大家团队的力量也是很大的，就不会比**Redis**差，就有这么个感觉。

**主持人**: 那我就搞不懂了，**Redis公司**都没考虑过这种后果吗？你们这些人又不是独立开发者，每个人都是有大厂背景的，这个是**Google**的，这个是**AWS**的，这个是**Oracle**的，这个是**华为**的，这个是**阿里**的，你是**腾讯云**的。他怎么会觉得说我要把这个东西改成闭源，我要把这些云服务商都踢掉，但是这些云服务商的员工还会继续为我免费地做这个开源的开发，他是在想什么？

**朱彬彬**: 也不是，我觉得是他们预料到了这种情况一定会发生，他们也做好了这种情况一定会发生的准备。所以他们在当时，你说他们不在意社区，事后表现来说，他们也是在意社区的，但是最终决策做出来还是有这么个影响。

### Redis创始人回归与重新开源的考量

**主持人**: 那这之后还有一个节点，就是24年的年底，**Redis**的创始人**Salvatore (antirez)** 回到了**Redis公司**，等于说是重新出山了，然后他们很快就把license重新改回来了开源。那这之后他有找你们说请你们回归之类的吗？

**朱彬彬**: 实际上应该是没有的。我记得有一次互动，他就是过来**Valkey**这边，因为**Valkey**源代码里面不是很多源代码的那些商标归属权是属于**Salvatore**的嘛。他当时就说让我们把**Valkey**里面这些就是IP相关东西都转到**Redis**那边去，就改成**Redis Lab**或者**Redis公司**。他其实只做了这个，你要说他有过来找我们去说讨论这个东西，其实没有。

**主持人**: 那没感觉出来他们对开源社区有多重视啊。

**朱彬彬**: 我觉得体现出来的话，可能是后面他们又重新open source了吧。就说如果他们觉得社区确实是不重要的，或者干嘛的话，他们可能也不会说再把license改回来，或者说去继续维护open source这个项目。但他确实是没有再找你们请你们回归。

**主持人**: 确实没有。

**朱彬彬**: 因为后面我觉得也已经过了挺久了，就有句话是什么，what is done is done的那种感觉。

**主持人**: 那现在的**Redis**应该也重新组建那个开源的核心团队吧，你有跟他们接触过吗？

**朱彬彬**: 有有，你说开发团队这边，我觉得两边开发团队都很友好的，因为大家之前相互工作一段时间。目前**Redis**的**core team**其实是一批新的人，都是他们（**Redis公司**）内部的一些员工。

**主持人**: 啊？全部都是**Redis公司**的人吗？就没有外部人士了吗？那他重新开源不是开了个寂寞？

**朱彬彬**: **Redis**它虽然重新开源了，但是它之前做的一些事情，比如说第一，废弃了之前社区治理的一个模式，现在整个**core team**其实都是**Redis**的人。第二他们还有**CLA (Contributor License Agreement)**。**CLA**是一个你提交代码的时候会签的一个条款，然后那个条款上面会说你提交的所有commit都是归属于**Redis公司**的，类似这样子的。

**主持人**: 诶？那他都已经重新开源了，为什么还有这么一个条款在这里？

**朱彬彬**: 比如说他之后想重新闭源，他可以直接去闭源掉，不需要去跟你这种原作者去讨论或者干嘛之类的，他可以直接去做，有一个合法的一个正当理由。

**主持人**: 这个**CLA**是什么时候出现的？

**朱朱彬彬**: **Redis**在闭源之后应该就有了，我记得他们当时就直接搞了**CLA**这东西了。然后现在重新开源了，这个**CLA**也没有取消。

**主持人**: 那我感觉他这个就是一个纯粹的PR行为了，这个开源。

**朱彬彬**: 是的。其实他们也没有做任何的保证来向大家承诺说以后不会出现，就不会再出现这种情况。因为**CLA**这个东西决定了，即使它现在是开源的，它将来也是完全可以根据**CLA**的条款把它重新闭源回去的。

### 开源项目分裂与合并的可能性

**主持人**: 其实之前也存在过不少这种开源项目，因为控制的公司跟社区有一个矛盾，所以导致分裂的情况。我觉得最经典的就是14年**Node.js**的分裂，而且他们的状况跟**Redis**还真的有点像的。因为都是这个创始人加入了一个公司，然后把IP什么的都卖给了这个公司，自己就退休了。而这个公司就是因为自己的业务需求和社区的路线不一样，这个开源社区就会分裂出来。所以当时他们分裂出来是**io.js**，只不过这个分裂就持续了半年而已，他们最后还是合并了。所以回到你们，你们觉得你们跟**Redis**还有合并的可能性吗？

**朱彬彬**: 我觉得如果说两边有意向的话，确实是可以谈的。但是我觉得对**Redis公司**来说，我之前跟**Madelyn**也聊过这件事，我们在讨论就什么情况发生的话，我们有可能会愿意合并回去。就比如说**Redis**他们那边也愿意回把社区合并的话，那还是和之前面谈到的信任问题有关，你没办法判断**Redis**之后会不会去修改这个东西（许可）。所以最主要的话，如果说真的想要合并的话，我们就一定是需要**Redis**这个项目首先第一点肯定要改回去**BSD3**这种协议。第二点的话，就可能说需要去把它这个商标转移到一个比较中立的基金会，就比如说**Linux基金会**或者**Apache基金会**。那还需要去移掉他们那些**CLA**的一些限制。最后的可能还需要他们去承诺他们的决策权不能说占绝大多数，就类似需要有做这么一些事。但我觉得这些事，就**Redis公司**他肯定是不会去愿意去做的。

**朱彬彬**: 你要说一个决策做得对还不对，要看双方的背景。那对于**Redis公司**来说，他们可能因为商业化的一些压力，产品的一些策略调整，他们可能确实需要做这种事。他看到了**MongoDB**有一些成功的案例，因为**Mongo**也改过许可证，他们改了之后他们股价之类的有很大的一些提升。然后可能觉得站在**Redis**的角度，他们是想看到类似这些事情的发生。

**主持人**: 诶？但是据我了解，**Mongo**他们基本上都是内部开发了吧，没有怎么外部的参与。

**朱彬彬**: **Mongo**和**Redis**确实不一样。他们会吸纳少部分的外部贡献者的一些patch，但是只是少部分。所以**Mongo**对他们来说，其实没有什么参考价值。

**主持人**: 感觉这个企业的领导层不是很聪明。

**朱彬彬**: 我觉得就从一个市场的角度来说，你现在制造了一个竞争者跟你分蛋糕的，对你来说就是一个不好的结果了。除非说大家可以一起把这个KVS这个市场做到翻倍，那我们KVS市场本来就只有这么大，那你为什么要制造一个竞争对手？我们看很多其他的行业，就是最后只剩下两三家的时候，只要政府没有反垄断，大家的想法都是合并，因为你这样子的话可以统一市场，就不会说两边竞争，竞争就会消耗，消耗就会有受伤，对吧。

**主持人**: 那我先确认一下，合并的话是不存在什么技术路线的问题，是吧？

**朱彬彬**: 我觉得不存在。虽然现在两边产品分叉出来有点多，因为过了确实也差不多两年。技术角度上，其实你要合并也是可以合并的，技术上是没有难度的。我觉得难度的还是策略，还有商业这些，对方的态度这个问题。

**主持人**: 那假如我来牵头，把**Salvatore**和**Madelyn**拉到一起坐下来谈，你觉得能谈得成功吗？

**朱彬彬**: 我觉得如果确实两边都有意愿去谈，其实也是可以的。但还是最主要决策权，我觉得还是在**Redis**那边。

**主持人**: 好吧，那这个问题就留给**Redis**他们了。

### Valkey时代云厂商的竞争策略

**主持人**: 那聊完八卦，我们来聊一聊技术吧。有一点我是挺好奇的，就是像**Valkey**这种纯粹的开源系统，那些云服务商他们要怎样去竞争呢？就是纯粹比谁的价格更低吗？

**朱彬彬**: 我觉得最主要就在市场上，如果想竞争的话，最主要还是你本身这个产品上面的工艺，就功能差异化。就比如说怎么理解呢，因为像目前的话，我们在**Valkey**的架构上，我们前面挂了一个**proxy**，挂了个代理。像社区版它本身没有代理这个东西，那我们挂了代理之后能做很多原本在内核做不了的事情，有这种差异化的存在。

**主持人**: 是不是可以说明一个问题，就是其实大家都藏着，就都没有把自己最好的东西拿出来放到**Valkey**这个开源项目里面去？

**朱彬彬**: 我觉得初期可能会藏一点，但是长远的角度来看是往外面open的。因为你看到**Valkey**最近的一些大的功能，其实都是各个厂商内部已经跑了很久的一些功能，就贡献出去。因为像现在**proxy**之前也有别的一些**core team**成员，他们是想推的，想推自己的**proxy**到社区，就说有在讨论说社区是不是需要一个**Valkey proxy**类似的组件。那遇到的阻力都会比较大，因为每个厂都有自己的**proxy**，其实很难去把自己的**proxy**往外去推。最主要的东西就是把自己的东西变成一个标准，但是你自己的东西变成标准的东西，它需要达成很多共识，每个人的想法是非常不一样的。怎么去描述这件事呢？我觉得其实也不太好说，说实话。

**主持人**: 那我来帮你总结吧，实际上就是大家都想让自己的标准成为最终的标准，但是没有人肯让步，那就干脆就不要标准了，是这样吧？

**朱彬彬**: 是的。

**主持人**: 说到功能这点，我在去年发布的这个**Valkey 9.0**上面看到一个很有意思的，就是**hash field expiration**这个功能，是两年前**Redis**发布过的功能。那这些**Redis**发的功能，我们有哪些要拿过来复刻一遍，这种决策是怎么样去决定的呢？

**朱彬彬**: 这个需求其实在以前**Redis**内部就有了，就比如说在内部，在**Redis**社区就有了。

**主持人**: 对，我就特别想要这个功能，要不然你整个hash就是一坨东西，就很难用。

**朱彬彬**: 对，所以当时在**Redis**社区内部有很多用户都希望有这么个功能。所以在后面就分叉出来之后，**Redis**做的第一个大功能应该就是这一个，我记得**7.4版本**就把这个加进去了。他们想把这功能作为类似分叉之后的第一个大功能，类似这么个东西。

**主持人**: 他们怎么一分叉就开始发这种大家期待已久的功能啊？这什么意思啊？

**朱彬彬**: 可能还是想搞差异化之类的东西吧，确实也挺那个的。他们之前都是一直有在压一些功能，一直没往里面做，但是分叉之后又在往里面做。所以这确实也挺那个的，就是恶心人。

**主持人**: 好吧，我来帮你描述了。那么这个东西你们当初决定要复刻过来的话，是可以直接把代码复制过来吗？还是因为已经分叉了，所以不兼容了，要重新写？然后你们写的话，你们需要考虑到跟他们那边的兼容吗？

**朱彬彬**: 就会考虑**API**层面的兼容，比如说命令，那些命令的名字啊，参数这个东西，会考虑做**API**上的兼容。因为**API**上的兼容能利好那些从**Redis**迁移过来的人，或者比如说客户端。但这只是**API**上的兼容，你说代码上的话，确实是不兼容的。因为分叉确实比较多，代码上包括像**AWS**他们的人，他们的法务同学之类的，跟他们很明确地说，就让他们不要去看**Redis**代码，就有这么个限制。所以他们不会去看**Redis**的实现，只会去看他们（**Redis**）的文档，去看他们这个**API**是怎么设计的，在**API**的层面上去做兼容。

**主持人**: 那这种算不算是看图写作文呢？就是我们知道它有这个新功能，它这个**API**长这个样子，然后我们就按照这个去把它实现出来。

**朱彬彬**: 这个东西本身我们也是想做的，包括之前分叉出来之后，在**8.0**没有做，是因为**8.0**的时候人力之类的东西都在别的地方，确实可能需要点时间，所以最终到**9.0**才出来。其实发了就好，总比像**Redis**那样故意压着这个功能不发好得多了。当然我们现在在**Valkey**不会说特意地去阻塞某些人去做一些功能，因为现在跟之前的**Redis**可能不太一样，现在整个**Valkey**还是相对来说会比较open的。我会去认真评估你这个东西是不是对大家好，就对社区好，更多会站在社区这么一个角度。

**主持人**: 这里感觉是有点矛盾了吧，因为前面不是说了那个**proxy**的事情吗？你像**proxy**这种好东西，最后也是没通过。

**朱彬彬**: 之前**proxy**的讨论的话，我记得应该是**华为云**的同学想去加，但是最终没做成，还是因为大家都不太想做，讨论的人会比较消极。

**主持人**: 所以是核心团队里面有人投了反对票是吧？

**朱彬彬**: 应该是，但具体讨论我忘记了，我没怎么参与，因为当时可能我在忙别的。

**主持人**: 那这样子也没有完全摆脱掉当初**Redis**那种被企业的利益影响到开发路线的这种结果呀。我看现在**Valkey**的这个**技术委员会 (TSC)** 的这种结构，是设计了一个投票要超过2/3才能够做决定这么一个纲领，这就是为了避免**Redis**那种企业影响到决策的这种结果，是吧？

**朱彬彬**: 对的。权限大家尽量地平均，不会出现这种被某一个厂商或者某一个实体去控制绝大多数的决策权。

**主持人**: 那这里就有一个问题了，他不一定需要一个厂商去控制啊，他只要两个他们的利益关系是一致的，他们也可以控制的。你比如说现在**TSC**里面有9个人，**AWS**就已经3个了，虽然说他不能够超过3个，但是只要你有两个公司有3个，那3+3=6，那已经完全控制了吧？这不也是一个存在的风险吗？

**朱彬彬**: 从现实情况出发的话，确实可能存在这个风险。因为最早的话，像那个**TSC member**其实是6个，当时的6个有厂商背景的，也是社区最活跃的一些贡献者组成。我觉得最主要促进（增员）这个事的发生，可能是之前**Google**有个**core team**（成员）他去年年底离职了，他去到了**Oracle**，加入了**甲骨文公司**。他在走之前，他站在他们团队的角度，他还是希望说在社区能留下**GCP**（**谷歌云**）的一个成员，希望说把另外一个**GCP**的成员给加进来。他发起这个话题的时候，像**AWS**也会开始发起，他说如果你们那边要加一个人，那我们这边也要加一个人。所以后面就聊着，大家都觉得大家一致认可，大家都OK。并且我们为了防止像刚刚那种情况再出现，我们有去修改社区治理的模式，我们又再次在（纲领）上面去强调成员或者公司的席位数量不能超过3个，又再次做这种事。但像你刚刚说的，如果两个公司联合起来，或者三个公司联合起来的话，那种情况没办法避免。

### 中国技术人与企业在开源社区的现状

**主持人**: 这里就有一个我特别想讨论的话题，就是我们中国的技术人和中国的企业，好像在整个国际上的社区，开源社区这里面，相对来说这个发言的机会是比较少的。我感觉**Valkey**是不是已经是中国的发言权比较高的一个地方了？

**朱彬彬**: 我不太知道其他项目，但是**Valkey**这边确实也还好。我感觉跟国情也有关，我们国内很多开发者大家虽然说很喜欢开源，但是参与开源的频率啊、质量啊，其实都相对会比较少。因为大家国内的工作、家庭之类的，时间分配会比较忙。

**主持人**: 就是我们参考一下国外的做法，你像**AWS**、**Google**、**Microsoft**他们都会养很多的人专门去做开源。那这里就不存在什么工作和开源的冲突了，因为你的工作就是开源，开源就是你的工作。开源这个东西并不是说我要去做一个完全免费的事情，它是一个长期的铺路的一种行为。那你铺完路了之后，你就可以开始收过路费了，这么一种长期的眼光的事情。我们的企业是不是感觉就是没有形成这么一种眼光？

**朱彬彬**: 这个问题比较难答，说实话。我觉得跟团队的，就是跟你领导，就领导leader之类的，他们喜不喜欢开源，或者说以前有没有搞过开源，或者说对开源的看法，这些都有关。

**主持人**: 因为我想的是，大家都是云服务商，你说云服务这个东西本质上的商业模式都是一致的。那老外都已经给你们跑通这个模式了，那我们为什么不考虑直接抄一下答案呢？

**朱彬彬**: 我不知道别的团队，反正我们团队这方面投入也在慢慢变大。你看包括我工作上，我也会有比较多的时间投入到开源上。有时候在团队内部就工作不是特别忙的时候，我leader还有老板都是鼓励我，去往社区投入一些精力，去做一些事情。当然现在的话，你要说对比**AWS**那种投入的话，确实也还没有那么多，但是有在那个的，有在慢慢加大投入的。

**主持人**: 其实我最近刚遇到一件事情，就非常契合开源的战略意义这么一个话题。最近有一个粉丝在找我帮忙，他是**西安交通大学**的一个教授。他们会用到的一个科研的设备，一个系统，或者说一套标准，这套东西是美国一个大学开发的。这个美国大学做了这套东西之后，它免费给大家用，它不收钱。全世界的学校想要用，申请它就可以拿过去用。这就造成了全世界都在用这套东西，那它就变成了一个全世界公认的标准。我觉得这其实真的就是老美特别擅长做的一件事情，就是他在前期他会不求经济回报，他就会尽量地让更多的人去参与、去使用，对它形成依赖，然后让它形成一个国际标准。那结果呢，在去年年底的时候，所有中国学校的申请都被拒绝了，就是这个美国的大学直接把中国踢出去了，这个授权（范围）他要掐你，就是这么简单的事情了。因为这个东西它不开源，它只是免费地给你用。所以这个粉丝就来找我，希望我带一个团队去开发开源版本的这个系统，去对标对方，或者说兼容它，然后让我们的这个成为一个中国的学校都可以用的一个系统，我们成为一个标准，这样我们就不会被他们那边卡脖子。我觉得这种战略上的意义，就是在如今的这种大环境下，也不是什么空谈了，这是真的会发生的事情。所以从企业的角度来说，就应该去考虑一下这方面的因素，而不是单纯地就想着这个项目它能够赚多少钱，能够产生多少利润，而是一个大的方向。你能够参与的涉及的这种开源东西越多，你在这个市场上的蛋糕越大，你就越可以避免去用别人闭源的东西，要不然哪天他一掐你，你就没了。

**朱彬彬**: 我觉得未来所有的应用软件，要保证长久发展的一个很重要的因素，就是它里面依赖到的一些核心组件必须是开源的，或者说是厂商中立的。这是一个健康的一个发展路线。像你刚刚说的那个学校那个项目，当然它本身因为它是闭源的，所以我觉得大家确实可能也不好去弄那个，或者制定标准，但是它确实是一个经验教训吧。

### 个人参与开源的经验分享

**主持人**: 那我问一个非常私人的问题，你现在开源和不开源的工作的占比分别是多少？

**朱彬彬**: 这跟忙不忙有关，说实话。大概的话，我可能早上来的时候，整个早上的时间可能会放到开源上。因为你也知道，像**GitHub**或者**slack**，我们外国的朋友时差问题，所以很多时候我们这边是晚上，他们那是白天，所以很多时候消息是异步处理的。所以我觉得时间比例的话，每天大概可能可以投入到社区有两三个小时，就不忙的时候可能可以投入到两三个小时。

**主持人**: 那这个就完全取决于你的公司里面的工作内容了咯？我本来以为是什么五五分这种。那如果你这个工作很忙的话，是不是有可能一个月都碰不到**Valkey**的代码？

**朱彬彬**: 因为我们团队人也还比较多，有其他人在帮忙，就分摊压力。所以我这边投到社区的时间，我自己觉得还是比较多的，就不会说出现这种连续一个月都会特别忙。

**主持人**: 那会不会有一个情况是，这个人一直缺席很多重要的场合，我们下次会议就决定把他给踢掉了？

**朱彬彬**: 好像有，我忘记时间是多少了，是半年还是多久。

**主持人**: 那我觉得如果我是**腾讯云**的领导，我至少应该保你这个席位，对吧，保你这个发言权。所以我应该多给你一点时间在这个**Valkey**项目的参与里面才对吧？

**朱彬彬**: 但你社区的话，也不一定说你投入那么多时间到社区就一定在社区有事情做。很多时候你参与社区，很多时候处理别人的消息，包括那些东西，它是不太需要一个很连续长的时间。如果你不是沉浸在编码阶段，或者说在处理问题，它需要你的时间是会比较零散的。

**主持人**: 所以你们是没有一个什么很严谨的**Todo list**在这里等着大家是吧？

**朱彬彬**: 是的。因为大家我觉得大家不像工作，工作会有一些时间限制，deadline之类的。那社区确实大家都知道大家很忙，所以大家处理事情的话都会不着急，就压力不会说很大，大家都是非常open地或者说自由地去做这件事。

### 如何入门开源项目

**主持人**: 那最后我们来聊一聊你的个人故事吧，你第一个参与的开源项目是哪个？

**朱彬彬**: 我以前搞过一些小的，但是不太确定了。因为最开始我是写业务代码的，我是在在线教育的行业，在写一些**Python**相关的业务代码。所以对**Python**相关的话，我以前有提过一点点，但不是很系统。那你要说我系统地参与，那确实第一个就是**Redis**项目。大概是在21年3月份还是4月份开始的吧。我当时开始参与**Redis**，当时也不是说很厉害，因为每个人都会从一个新手慢慢过渡的。所以我也是去看看文档，去修修文档，包括写测试用例，它有这么个慢慢熟悉的过程吧。我应该在21年三四月份开始去给**Redis**提交第一个**PR**，八九月份的时候就慢慢地和**Redis**的一些贡献者、核心贡献者就比较熟悉，再到后面正式地加入**Redis**这么一个开源组织，开始承担更多的工作。

**主持人**: 那你上来就选这么大的一个项目，是什么个契机啊？因为你对KVS很感兴趣？还是说我就是要挑战一个大的东西？

**朱彬彬**: 其实还是从工作出发吧。我当时也做业务开发，我本身用到**Mysql**、**Nginx**、**Kafka**、**Redis**，很多组件都会用到。我觉得说单单会用其实还不够，我觉得我需要找到一个组件能去更加深入地去了解、去学习。那**Redis**可能在主要组件里面，可能是相对比较简单的，或者说对业务来说联系比较紧密的。因为你做业务开发，**Redis**我觉得应该是每个业务开发都会去用到和学习到的一个东西。所以我就从**Redis**开始入手。**Mysql**我当时也有想法去弄的，只是说后面慢慢重心到**Redis**了。

**主持人**: 那你是准备到什么时候才发的第一个**PR**？

**朱彬彬**: 我第一个**PR**我记得应该是个文档型的**PR**，就比如说修一下文档之类的东西。后面我有些**PR**，我初期的**PR**是跟**bugfix**有关的，就修一些小bug。那到中期的话，和其他的贡献者比较熟的时候，那些贡献者会给你分配一些任务。就比如说我当时和**Redis**的一个**core team**成员比较熟，他当时比较忙的时候，他会让我帮忙去看一些测试用例的一些失败的情况。我记得最早看的是一个主从复制相关的一些测试用例。因为**Redis**它本身在分布式架构下，它确实会有一些时序相关的一些**timing issue**之类的，或者说一些**竞争条件 (race condition)**。当时通过测试用例确实学习到了非常多知识，包括修这些测试用例，对**Redis**也会越来越熟悉。

**主持人**: 可以说这是你的策略吗？就是先混个脸熟。

**朱彬彬**: 嘿嘿，你要说策略其实也算吧。这取决于你对那个东西的熟悉程度。那如果说你本身就特别熟悉的话，你确实可以说去直接去从一些功能出发点去切入。

**主持人**: 那你最一开始修那些bug，都是在日常的工作中发现的吗？还是说你是去那些没有人解决的issue列表里面去找来修的？

**朱彬彬**: 工作日常中其实你发现不了bug，因为那种是比较热的路径，都不会有问题的。我发现的，我觉得两部分都有吧，从**issue**（列表）里面去看，包括从源码里面去看，其实都有。你要说我开始做贡献的时候是一开始就来吗，其实也不是。在此之前我已经很多书籍之类的，一些文档，我已经看过了很多，包括用法都有过很多积累了，不是说一上来就看源码之类的。通过这个东西可以触及很多东西，比如说数据结构、网络通信、主从、集群。虽然不是特别大，但是它又挺全的，就很多东西支持你确实能从这里面学习到。

**主持人**: 所以就是深度的价值大于广度，对吧？不需要参与很多个项目，只要你有一个项目你参与到足够深，你对它的理解足够深，你从中获得的知识也是可以应用到很多地方的，是这样理解吧？

**朱彬彬**: 在这里面深度确实是更重要一点，我觉得。因为当你深度够的话，你的广度很容易可以扩展的。

**主持人**: 我有很多很年轻的粉丝，他们有一个共同的问题，就是积累的太少了。所以他们的想法就是说，有没有什么开源项目可以参与一下，就丰富一下自己的简历。你觉得这是一个合理的途径吗？

**朱彬彬**: 我觉得确实是个好的途径，说实话。第一点我觉得你如果想参与开源项目，还是（应该）选开源项目和你的工作是相关的。这方面一方面能反哺你，第二点用它填充这个简历确实也是个好的途径。因为现在对企业的话，现在很多团队都会比较喜欢那种能够去主动参与开源，并且在开源有一些产出的一些同学，都会比较受欢迎。因为你本身参与开源，它需要有一些基础实力，就包括可能说需要你要怎么去和别人去沟通，怎么在开源社区去做一些团队协作。因为现在参与开源，我觉得对很多新手来说，可能提一个东西没人去理你，我觉得这对于新手来说是打击比较大的。但我觉得这东西也不能怪人家那些**maintainer**不关心你，因为很多**maintainer**确实也都比较忙。如果说你的问题，包括你的一些改动是没什么必要的，他们真的是不太会想去花时间去投入在这里。我觉得有个很重要的基础，你们不要尝试地去修复一些没有问题的代码，或者说不要尝试去优化一些没有问题的代码。很多新手会有这种感觉，就看着你这个代码就说不应该这样写啊，这个for循环应该怎么写会更好啊，他会有自己这种想法，所以他就会去写。那我觉得初期我们可以避免类似这种想法，因为对于**maintainer**它确实是一个负担。首先还是得看你这个**PR**有没有价值，那如果有价值的前提下，你可能写的一些不太好的代码，其实也没什么问题的。因为像一些**maintainer**他意识到你这个**PR**是有价值的，是可以合进去的，他会开始去指导你去写代码。

**主持人**: 所以这也算是一个策略吗？就是找到一个有价值的问题，就算你不知道怎么解决它，你能够找到这个问题，把它发出去，大佬也会过来指导你，手把手教你去怎么解决这个问题。

**朱彬彬**: 对对。我觉得第一点的话，你要想办法把对方的兴趣给吸引起来，我觉得这确实是会比较重要，说实话。很多**maintainer**本身做开源的话，都是会乐于助人，也不说乐于助人吧，大家都会比较友好的，相对来说。我不知道我的路径能不能复制，但是它确实可能是一个经验。首先我觉得最好先是一个使用者。很多人初期或者前期，他可能确实找不到发力点，我觉得这很正常。我觉得还是积累的问题吧。我觉得开源跟工作可以相辅相成地去做。当然你如果能和工作结合肯定最好，因为很多人一开始（直接）看源码，其实是没办法做贡献的。这东西确实是很残酷的一个东西，你确实需要对这个本身有一个熟悉度之后，你才能好好去参与。

### 阅读书籍、文档和代码的建议

**主持人**: 那么刚才提到的书本、文档和代码这三者的阅读顺序，你有什么建议？

**朱彬彬**: 我会建议先看书。当然现在书籍有个问题就它可能会比较老，有些东西会比较老。但我觉得老的东西其实也没什么问题，也可以先看。反正我觉得第一点还是先看书。第二点其实就是看文档。文档其实很枯燥。这个文档跟源码这部分我觉得可以结合起来的。因为你可以通过文档去了解到这个东西的概念之后，你可以去参照着源码去看它这个概念到底怎么实现的。我觉得这个顺序还是很重要的。

**主持人**: 就是我之前有一个有点标题党的视频，就叫做《不要读代码》《读代码没有意义》。但我并不是说代码一点意义都没有，只是很多人他会误以为你要了解一个东西，了解一个项目，你上来第一件事你就应该读代码。所以就很多粉丝就会找我，问我要推荐一些**Github**项目给他们，他们想要去读一下里面的代码。但是如果你连宏观的概念都没有，我很难理解你打开哪个文件你都不知道，对吧。

**朱彬彬**: 这方面我比较同意原子能老师。很多人一来就扎根代码确实不太好，因为很多东西确实看不懂。包括现在如果说我想去学习另外一个组件，你让我直接打开它的源码，我其实也无从下手。因为你不知道入口函数，很多东西你其实不知道，你确实没办法做。书籍的话，我觉得像我刚刚说的，我觉得最好的东西还是你如果工作中能用到的，那肯定是最好的一点。你尝试先学习怎么把这个东西给用好，或者说把它的应用场景全部给掌握。当然如果说你确实没使用场景的话，我觉得也可以尝试去自己创造一些使用场景。对这方面比较成熟之后，你可以尝试去看一些原理相关的书。比如说你看**Redis**，或者说你本身对算法、数据结构比较感兴趣，你可能说我会想知道**Redis**里面它这个字典呐，这种哈希表，这种有序集合，它怎么实现的。因为你原本已经对这些命令很熟悉了，你会发现它是通过什么样的形式实现这些命令，并且实现得非常高效，并且省性能，就是内存也省。我觉得很多人比较消极，或者说被打击的，都是一开始扎进去之后，发现进去之后啥都不懂，啥都看不出来，就说算了，我不适合看，我看不下去。哈哈。还是先找到一个点，这个你感兴趣的点。我不会说一定在最上层把所有东西都搞得大而懂之后再去。

**主持人**: 那你现在已经把**Redis**所有代码都看完了吗？

**朱彬彬**: 我只有**Module**相关的，还有那个流（stream），还有**Lua**相关，只有这几个地方的没有全部看完。但我能说其他所有东西我都看完了。第一步入手的话，我应该是从数据结构入手的。会开始从字符串慢慢地到跳表，到有序集合、字典，会慢慢开始看。在这个过程中，你会发现这些数据结构的实现，首先第一点，就跟你以前从算法书里面看到一些东西就具象化了。以前从一些书籍上确实学到这个数据结构很好，它大概怎么样实现的，但是你以前没有写过类似的代码，或者说没有看过完整的实现。那现在突然就看到一个完整的实现，你说哦，原来以前教科书上说的那些数据结构，它确实是可以用代码写出来的，会有一个比较好的一个正反馈。数据结构看完之后，下一步我看的是命令。举个例子，像那个有序集合（sorted set），那**zset**的话，它其实在**Redis**里面，它底层用到两个数据结构，一个是跳表，一个是哈希表。它又想要快，又想要有范围查询，结合两个数据结构确实能做成这个事。你从这个命令开始慢慢着手的话，又可以慢慢去把整个链路串起来了。确实时间周期可能需要拉得比较长，说实话。因为当时搞**Redis**我也经历过一段时间，不知道我要去看哪方面的内容，或者说不知道怎么去深入。反正就慢慢地一点点去看吧，慢慢扩大这个圆圈，这个范围，类似这样子。

**主持人**: 所以就是不能急是吧？就不能够想着一天吃成一个胖子。

**朱彬彬**: 当然可能有些特别聪明的人可能确实有方法吧。那种天才就不需要咨询我们的意见了。

**主持人**: 好了，以上就是第一期《原桌会》的全部内容，感谢大家观看。第二期的嘉宾现在还没有定，有一个候选是**JetBrains**的老总，不过对方的时间有点难安排，所以不一定能成功。如果你有特别想要我去采访的，或者是一个好的建议，可以在评论区里面留言，给我一点灵感，谢谢。那我们下一期《原桌会》再见，拜拜。