我和 TiDB 的故事 | TiDB 仓库 commit TOP 1，PR 数超过 1000 的阿毛哥

原文来源：https://tidb.net/blog/d78c0d00

大家好，我是毛康力，来自 PinCAP 的研发工程师。我的 github ID 是 tiancaiamao，目前在 TiDB 仓库的 commit 数排名在 top1。在 TiDB 相关的各个项目总计 PR 贡献累计超过 1000 了。

相遇

我在 TiDB 仓库的第一个 pr 应该是 2016 年的 6 月 21 号。 因为工作原因，我在 2016 年 4 月份加入了 PingCAP，先是在 tikv 那边干了一阵子，但是写 Rust 不太习惯，然后就转到 TiDB 这边写 Go 了。对我自己来说，还是 Go 语言写起来比较舒适。再接下来就是持续的给 TiDB 提 PR 了，这一干就是持续好多年。

选择加入 PingCAP

我接触 Go 语言比较早，而早期使用 Go 语言的公司并不算多，PingCAP 是其中之一。然后也有关注到 TiDB 这样的 Go 语言实现的 ” 明星 ” 项目。

一个契机是，早期的活跃的 Go 语言用户同样也不算多，我自己有写博客的习惯，当时主要是一些关于 Go 方面的内容，东旭正好通过博客关注到我，于是就约着聊聊。就这样擦出了火花，于是我就来贵司了。

最初我是在广州的，而 PingCAP 在北京，所以对于换城市会有一定的顾虑。而正好 PingCAP 的文化是支持 remote 的，这点就非常有吸引力了。 站在现在的角度看，虽然作为一个老司机，我已经 remote 好多年了，习以为常。但是当时还是挺震憾的，文化上非常的开放和自由，宽松的工作氛围，追求结果而关注过程。

现在 PingCAP 在全国几个大城市有了 office，海外也加入了不少同事。一个 team 可能遍布在好几个地方，并不能大家都在一个办公室，有事吼一嗓子，或者直接去工位找某某某。其实大家也都习惯了 ” 线上 ” 协作的模式，提 PR，review PR，线上会议等等，这都是跟开源的协作模式很契合的。

像我所在的团队就有分布在国内几个城市，以及在欧洲和北美。导致一个问题是，跨越了多个时区，开会聚集不到所有人。处理方式就是，比如今天由国内跟欧洲开会，明天再国内同步到北美那边。由于分布在不同的城市，一个 team 的同事可能都没线下见过，如果 team building 聚一聚时，会发现大家可能相互 review 过 PR 和线上讨论过问题，但是却又还 ” 不认识 ” 对方，于是我们戏称为 “ 网友见面 ”。

谈一谈 TiDB 贡献者们

TiDB 贡献者们来自各行各业，也都有着不一样的身份，但是他们都有一个共同的身份，就是 TiDB contributor 。

比如说有学生。尤其是有些国内排名靠前的大学，学生都很猛的，还没毕业就早早关注到一些开源项目，并参与贡献一些 PR。像我自己毕业时的那个年代，对于开源项目这些东西都还没有什么概念。现在实在是太 ” 卷 ” 了，没有一些开源项目的贡献，大公司实习之类的经历，可能简历关都过不了。 我时常调侃，还好加入得早，要不然如果是换成他们先进来，再来面试我，我就被他们拍死在沙滩上了。

关于学生这块，我们有时候也组织一些面向高校的活动。比如说 TiDB-challenge-program 的活动，也是会吸引一些高校学生参加。我们会发布一些特定的小项目，我自己作为 mentor 带过一些，感觉真的是很优秀的同学，对比一下由开源这一块吸引到的贡献者，比简历投递过来的质量往往要高不少。 所以这也是招聘的一个很好的来源。早些年，我们会给 TiDB 贡献过代码的外部贡献者发一些小礼物，比如说有送件文化杉啥的。如果发现了穿着我们送的文化衫的 ” 野生 ” 贡献者，要赶紧拉住要简历。因为公司内推是有奖励的，所以这种人被我们称之为 “ 行走的 iPhone”。

扯远了 … 说回 TiDB 贡献者的背景，除了学生，也有来自学术界的。印象很深的一个是 Samuel，是一个国外的大学教授。开发了一个 Squirrel 的测试工具，发了篇论文，里面用到了一些模糊测试的方法，在 TiDB 上面验证过，帮我们挖了不少 bug 出来。再后来，他有个博士生，github ID 是 bajinsheng。在 Samuel 的基础上继续深入，做了个叫 sqlance 的工具，也给我们找了好多 bug。工具太厉害了，效率很高，一个人的战斗力超过一个团队。那阵子他比我们自己的 QA 整个团队加起来找得 bug 都还要多。github issue 里面搜 label:fuzz/sqlancer 可以看到这些记录。贡献不一定是单指代码，像这种帮忙找 bug 发现问题，也是一种形式的贡献。

类似的还有 TAOBench 作者，也是有一篇 paper 的，他们构建一个性能测试的工具，里面的实验验证有用到 TiDB 和其它几款数据库产品的对比。这些研究工作对我们的产品性能提升会有帮助，后来我们内部也把这些成果纳入了我们 benchmark 测试的 workload 里面，日常跑着。 严格来说 TAOBench 作者是来自 facebook 的，应该算是工业界了，但因为论文的关系，我还是归到学术界这边。

至于工业界，来自于这块的贡献就更大了。我们的不少的 committer 都是来自外部公司的。说明一下，给 TiDB 提过 PR 这种我们叫 contributor，当 contributor 持续提一些 PR，对某个模块具备足够的了解之后，我们会提名为 reviewer。足够活跃并且对整个 TiDB 做出了比较大的贡献之后，我们才会提名 committer。 像 SpeedCloud 的李雨来就是为我们贡献了最初版本的 plan cache 的实现，于是成为了 commiter 的。还有晓光老师也是我们的 committer，之前是在知乎。在 PingCAP 内部，其实也是同样的流程，要一步一步提 PR 才从 contributor 到 committer 或者 maintainer，这点对公司员工跟外部贡献者并没有区别。

有很多公司在用 TiDB，会给 TiDB 发现一些 bug，有些是提 issue，有些就直接 PR 甩上来的。尤其是互联网公司，都是很有这种直接 ” 撸起袖子就干 ” 的风格的。于是这些用户也就成了我们的贡献者。

从地域角度来说，贡献者来自全世界的都有，虽然国内的更多一些。记得一个很好玩的事情是，以前有个俄罗斯的小哥，给我们提过 PR。我说过，我们当时都会给贡献者送些小礼物啥的，然后我们同事就联系到人家，说给寄点东西过去。对方持着很怀疑的态度，在担心我们是骗子或者是在套他的个人信息啥的。 最后我们真的把礼物寄到俄罗斯了，小哥表示非常惊奇，也很高兴能收到礼物。虽然不是什么值钱的东西，这算是一种公司文化吧，我们一直是非常重视开发者的。

TiDB 代码贡献之路

我们的开发活动都是在 github 上面，公开透明。整体上看，日常的 workflow 都是围绕着 issue 和 PR 展开的。如果是简单的场景，直接提 PR(pull request) 就行了。PR 一般是需要得到两个 reviewer 以上的角色的 approve 之后，就可以将代码合入到 master 主干分支。

如果是对于复杂一些的场景，比较说开发一个新的 feature，流程上需要有文档，设计和讨论。内容也会以 issue 之类的形式放在 github 上面。比如说参见临时表的开发过程。

我想说的是，这一切都是对外开放的，真正的开源协作的模式。

影响用户的需求

github 上面的 issue 更加面向研发一点。如果是对于普通的用户，可以到 AskTUG 上面提问，这是一个属于用户群组的社区。

我们会收集用户的反馈，需求一般是几类来源，一类是这种社区的呼声比较高的问题。再一类是从企业版客户那边，在使用过程中得到的反馈。还有一些比如某些重要的 PoC，客户看中某一块的能力，我们还没支持。

PM 会整理这些需求，然后按优先级排期，研发这边会不断地改进产品。产品会不停地迭代，每个小版本我们都会有一些 feature 或者改进带出去，小步快跑的模式发布。

隔一定的时间，我们会发一个大版本，大版本往往都是带了比较重大的 feature 或者改动。现在我们会有 LTS(long term support) 的版本，追求稳定可以随 LTS 版本升级，而想快速尝鲜或者是等待某个新 feature 的用户可以用非 LTS 的版本。 这样同时保证了稳定和快速迭代，满足不同场景的用户需求。

收获

我自己算是跟随 TiDB 一起在成长吧。早期的 TiDB 代码规模比较小，团队也没有划分得很细，每个人都会涉及许多个模块，这样基本上可以熟习整体架构和所有的模块。你可以在 parser，事务，分区表，DDL，优化器，执行器等等几乎所有角落看到我的代码提交记录 (哈哈)。 现在的团队划分更细了，专注各自的模块，可能就没有我当时那么好的学习的机会了。

除了涉及到的技术层面，我觉得一个很重要的收获是作为一个工程师的综合能力。这个听起来就比较虚了，只有经历过，才知道怎么样维护这么大一个开源项目。怎么样保证产品质量，并且可控地迭代。如何与他人协作去推进一个事情。 大公司里面可能会有一些测试和 review 的规范化的流程，但是规范程度很难达到这种大型开源项目的标准。通过每一个 PR 提交细节，就可以看到这些工作的严谨。开源的项目可以知道谁，在某一次提交做了什么，被全世界所有的眼睛盯着，所有不规范的行为，都是被钉在耻辱柱上的。

开源文化

我觉得开源一定是要形成一个社区。把代码放出来，然后不管了，那样不叫开源。但有些公司就是喜欢这么玩，内部的产品竞争中败下阵来，于是直接把源代码往 github 一扔，就号称开源了。完全看不到后续 PR 和更新，也没有人在回答问题和解决 issue。

开源的概念火了起来，有些基础软件赛道的创业公司，PE 估值很高。就会有些人跟着蹭一波热度，这都是把开源当噱头，这都是假开源。 更过火的甚至出现了某公司，做活动推广刷星，只要给他们 github 项目仓库点赞就送礼物。这种形式做出来的 star，对产品本身是毫无意义的。当然，如果投资人傻的话，也许给投资人看可以糊弄下: “你看，我们涨星趋势比当初的 TiDB 还要猛”。把开源当 KPI 来做，那肯定是做不成的。

不对的人对开源的文化有不同的理解。比如以 GPL 协议作为切入点来看，这是一个 ” 病毒 ” 传播协议，使用它的代码会被感染，也要求按 GPL 协议开源。但它确实是反技术垄断，打破专利壁垒的有效武器。对比一下，某头号数据库厂商，一个据说律师比程序多的公司，具体做了哪些贡献是推动技术进步，时代发展并且让所有人受益的事呢？源码在手，就意味着自由，而不是封闭，free! free 是自由，而不是免费的意思。也有像 MIT 这类的协议，放弃了对软件的诸多权利，这跟 GPL 不太一样，但在 free 这点上都是共通的。

不同的时期，推动开源运动的主力也在变化。早期更多一些个人英雄主义的开源项目。现在更多的是机构和大公司在主导着开源项目。这里面其实也有些利益的因素，是否拥抱开源，跟公司的认知有很大关联。

如果一个公司觉得，代码是核心资产，开源是劣势，会导致竞争对手抄袭自己的代码，从而后来居上，那么他就应该选择闭源。 如果一个公司觉得，开发者才是核心资产，那他应该打造一个开放的社区，吸引到更多的贡献者，让这个社区变得更活跃，更强大，从而产品也能更完善。因为抄代码是好抄，但是构建一个活跃的社区却是有很高的壁垒的。

当然，也会有一些分裂社区的行为，比如说，如果一个公司觉得既然代码都开放了，那么何不 fork 过来，再自己改一套，然后闭源卖企业版或者啥的。 这么做完全可以，只要没违反相应的开源协议。事情背后的本质，变成了这家公司，对抗整个社区的游戏。如果它的投入够大，它的迭代速度比原始项目更快，产品做得更好，用户就会吸引到它的阵营来。只是这个过程代价很大，需要这家公司的投入，大于整个社区的其它公司和个人贡献者的投入总和。

为了防止分裂，最好的做法就是让社区更活跃，参与者更多，由多家公司来一起推动。使得分裂社区的成本由单个公司无力承担。最后要么选择加入，要么对抗并失败。开源的规则就是这样玩的。有一个典型的例子就是 chromium，软件的复杂性使得没有哪一家公司能 fork 一个出去，然后自己另起炉灶的。一旦形成了事实标准之后，项目牵头的公司成为最大的受益者，属于是阳谋了。再比如 android 的例子，只有构建好生态，才能有无数的贡献者参与进来，写驱动，写 app，写各种东西，然后整体生态越来越强大。

从这个角度，我觉得开源的文化，就是反映人背后的认知。最终符合生产力发展规律的事物，会取得最后的胜利。相比于闭源 / 假开源，一开始就坚定选择开源的人，格局简直是在大气层了。

建议

如果说给最其他打算成为 TiDB 贡献者的人一些建议？硬核的方式，当然是 read the f*cking source code 啦。读代码的过程中，发现有什么问题可以在 github 提出 issue 讨论，或者代码方面有改进的点可以提 PR。读代码适合有一定基础，并且喜欢这种风格的程序员。

更平滑一些的方式，可以先从一些文档开始学习，了解一下系统的整体架构，官网的博客就是一个比较好的学习资源。有大概的熟习之后，可以从一些小的 PR 开始做起，在 TiDB 的 issue 里面搜索带 help wanted 标签的 issue，一般是比较适合于新人上手的。 至于怎么提 PR，在项目的 README 里面有一块 How to contribute。

关键是参与进来，接受反馈并不断学习，相信 TiDB 一定会让贡献者有很好的收获的。