开源经验：社区是如何管理 HBase 项目的？

【编者按】《开源启示录》是InfoQ 推出的重点专栏，旨在通过新闻、文章、访谈、用户调查、迷你书等形式，报道国内外知名的开源软件以及开源的发展状态，并分析目前开源的现状，总结国内外企业以及个人在开源方面的成功经验以及失败教训。如果您对开源感兴趣，请关注《开源启示录》，也可以加入我们的QQ 群（群号：319967710）参与讨论。

3 月 10 日，豌豆荚的张铎成为中国第 5 位 HBase Committer。现在越来越多的公司和开发者都开始关注开源，开源正在经历前所未有的繁荣时期，但这只是开始。从整体比例来看，国内参与开源项目的人并不多，很多人都不知道如何参与开源项目。在这个背景下，InfoQ 采访了张铎，希望能深入挖掘 HBase 项目组织架构、运营、流程等方面的细节。

受访嘉宾

张铎，豌豆荚基础技术负责人，目前主要关注存储相关的技术。2010 年研究生毕业，来豌豆荚之前一直在网易有道工作，从事的也是基础技术相关的工作。2014 年底带领团队开发了名为 Codis 的分布式存储解决方案，并于 2014 年 11 月 7 在 GitHub 上开源。

第一次提交代码

作为一个历史悠久的开源项目，HBase 非常复杂，据统计，HBase 差不多有 34 万行代码，主要使用 Java 语言编写，部分模块可能会使用 C 语言。我在 2008 年底的时候就开始接触 HBase，但是提交第一个 Patch 是在去年的 9 月份，当时在工作过程中发现，HBase 有时候会丢失数据，确认自己的代码没问题后，我开始怀疑是 HBase 的 bug，定位问题后就立即对该问题进行了修复。而小米的冯宏华已经是 HBase 的 Committer，也正好是我的学长，在冯的鼓励下，我把自己发现的问题提交给了官方。

提交后不到 10 分钟的时间，就有一位 Committer 联系我让改代码的说明格式（有些地方不符合规范），简单修改后，这位 committer 立即 @了负责这块代码的其他 Committer。整个提交过程非常快，HBase 方的反馈也很好，和我之前想的根本不一样。

如果要总结下第一次贡献代码的经验，我觉得应该胆子大点，不要害怕。不要怀疑自己的能力，发现问题就提交。不要担心自己的英文不好，只要发现问题就往上提，这对自己的成长也有好处。很多国外的程序员写的代码很烂，但是他们却敢于提交。而提交后又有很多牛人来帮你修改，这相当于免费请大牛当私人教练。

如何成为 HBase 的 Committer？

并不是第一次提交代码后就能成为 Committer，只要提交过代码的都是 Contributor 的角色。Contributor 要成为 Committer，需要持续不断的贡献代码，并且开发过新的 feature（猜测）。当代码贡献到一定程度时，项目管理者会主动与你沟通是否愿意成为 Committer，并不需要自己申请。

成为 Committer 之前，我一共提交过 30 次左右的代码，从官方的邀请信中可以看到，PMC（项目管理者）比较看重我为 HBase 1.1 提交的几个大的 feature，以及对 HBase 整个项目的单元测试流程的改进贡献。

目前 HBase 共有 41 个 Committer，但真正活跃的不到一半，目前也没有相应的退出机制。Committer 之间主要是通过邮件沟通，没有固定的在线沟通时间。

代码提交后的流程

Contributor 不能直接 push 代码到仓库，他的代码需要经过 Committer 审核。如果是一个简单的改动，那一个 Committer 就可以直接做主。如果是一个比较大的改动，那就需要多个 Committer 一起讨论才能决定。如果是可能影响兼容性的改动，那需要与该版本的负责人讨论后才能确定。

HBase 的代码并没有使用 GitHub 进行管理， GitHub 上的代码只是一个镜像。Apache 基金会中一些比较老的项目使用的都是官方自建的 Git 仓库，缺陷管理工具用的是 JIRA，提交代码后，JIRA 中相关 issue 的状态会变为 Patch Available。同时，项目机器人会定时扫描是否有 Patch Available 状态的 issue，如果有，它会下载相应的附件，并通过脚本检查格式是否正确、单元测试能否通过，并把结果发回到 JIRA。当 Patch 要合并到某个版本之前，该版本的负责人会重点进行测试，包括功能和性能上的。

HBase 的项目架构

HBase 的项目直接负责人称为 VP，VP 全职负责这个项目。VP 下面是几个 PMC，每个版本的 release manager 一般是某个 PMC。PMC 下面就是 Committer 了。一般情况下，一个 Committer 会对 HBase 的固定负责某个版本的某几个块功能模块特别熟悉，所以当 Contributor 提交代码时，项目组是有审核该代码的第一负责人。HBase 项目组会优先让对该模块比较熟悉的 Committer 来审核，这个 Committer 的意见也是最重要的。

HBase 主要的代码贡献者都是 Cloudera 和 Hortonworks 的员工，他们都是全职负责 HBase，甚至 HBase 中写文档的人都是 Cloudera 的员工。Cloudera 和 Hortonworks 都是基于 HBase 的商业公司，他们同时维护开源的 HBase，但同时也都有自己的商业版本。

社区分歧

每个开源项目都会遇到技术方案分歧的情况，同样 HBase 也有。HBase 在这方面并没有好的解决方案，每次讨论这样的问题时都会分为两派，大家都在说自己的解决方案以及优势，但是永远也没有结论。目前也没有相关的投票机制，比如谁的得票多就听谁的，因为投票很容易导致产生更大的分歧。

其它开源项目也没有好的解决方案。如果社区比较融合，大家都抱着解决问题的心态来看待这样的分歧，那还好办。但如果大家都比较偏执，一派人坚持要这样做，另外一派人坚持要那样做，那这样下去稍有不慎社区就可能分裂，这已经有先例了。再或者就像 HBase 一样先挂起这问题，但也不是长久之计。其实分歧问题和社区文化直接挂钩。

开源谈

如果只靠个人无私奉献，开源项目很难发展起来，更不用说建立生态圈。如同公司一样，开源社区需要有人来推动、管理和运营，开源不仅仅是代码本身。比如前面提到的开源文化，这完全是需要有人来引导的。

豌豆荚一直比较崇尚互联网「开放」「平等」的价值观，也很支持重视开源技术。公司决策层领导层也非常重视员工在技术方面的长期积累，所以也允许我有一些比较自由的时间来研究 HBase，做一些贡献，也不要求这个研究马上得在多少天内就贡献多少代码或者做出多少新 feature。我觉得豌豆荚对于基础技术的长期积累还是很看重的，而且很有耐心。纵观一些好的公司，一定会多给员工一些属于自己的时间探索新的东西。如果每天都很忙，不停的在加班，那什么时候去进步了？员工的成长甚至跟不上公司的成长，长期来看反而会拖累公司。