开源经验：社区是如何管理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。我觉得豌豆荚对于基础技术的长期积累还是很看重的，而且很有耐心。纵观一些好的公司，一定会多给员工一些属于自己的时间探索新的东西。如果每天都很忙，不停的在加班，那什么时候去进步了？员工的成长甚至跟不上公司的成长，长期来看反而会拖累公司。