为什么写这篇文章
过去2、3年无意间看到过几篇关于成为committer的文章，有的找不到了，还能找到的我放在了文章末尾(在此表示感谢)，这些文章对于我了解社区、订立成为committer的目标以及最终实现，有很大的帮助，因此我也打算写点东西，希望能够薪火相传，给其他人以鼓励；
hbase社区概况
contributor目前是300个左右，committer是90个左右，一年前的这个时候要更少一些，当时我和团队的小伙伴都很是意外，比我们预期的数字少了好几倍，原因是hbase很早就是知名项目了，在国内有很广泛的应用，难以相信就是这么点人在开发维护，而且里面有很多人实际上早就不活跃了；
comitter数量按时区来看的话，其它：印度(+5)：中国(+8)：美国(-8)大概是1：1：2：4，与各国的软件实力基本一致，从中多少也印证了欧洲的IT产业相对于其经济政治地位来说，是有一些低迷的；
大概过程
2019年2月份提交了第一个patch，和大多数committer一样，是从对文档的修改开始，虽然改动比较简单，但是意义不小，它一定程度上消除了我对开源社区贡献的神秘感，从此有一个issue的编号与自己的id关联在了一起；
2019年8月份提交了一个较大的patch，总共200多行，是根据线上实际碰到的问题，对bucketcache进行的优化，历时一个多月，提交了优化前后的性能测试和分析文档，以及实际生产环境中的运行度量数据，这个issue最后的成功合入，极大的增强了信心，自此便坚信成为committer只是时间问题；
随着对hbase的功能特性和原理源码越来越熟悉，发现问题的频率和解决问题的效率都有了不小的提高，2020年3月到9月这半年密集提交了大量patch，也顺利在9月中旬收到社区邀请成为committer；
参与社区的好处
深入掌握技术组件
这些年随着大数据技术生态蓬勃发展，很多公司的架构图都越来越像蜘蛛网，这其中，有一些是因为要应对各种各样的业务场景，不得已而为之，也有一些实际上只是对技术组件本身还不够熟悉，不能充分发挥其作用，碰到新问题就倾向于引入新技术，但技术栈越是复杂，维护成本就越高，就越是没有时间精力去深入，从而陷入恶性循环；
我所在的团队自去年起就有了这方面的一些反思，平常在使用的技术组件众多，列出来会有挺长一排，但多数都不够深入，一旦出问题往往不能够快速定位和解决，有不少时候就只好祭出重启、重导数据甚至重新安装等这些终极手段，相信不少团队也跟我们差不多；
因此，精简技术栈并各自选择方向进行深入研究成为团队共识，也正是在这个大背景下，个人才有机会能够专注于hbase这项技术；
得到的好处很明显，一方面对hbase的持续优化大幅度降低了tp999的延迟，原本服务层和hbase之间有一层redis用来加速，目前已经简化掉，另一方面碰到问题可以追根溯源，上文提到的bucketcache的那个问题，会造成regionserver每次老年代gc时出现长停顿，如果熟悉源码或社区，就可以通过自行修改或者引入社区补丁来进行修复，而前段时间有一位找我咨询问题的同学所在的公司，便疑似因为这个问题，而使用了jdk13，尝试用新的zgc来避免停顿，非稳定的特性加上非广泛使用的版本，很可能又会带来新的问题；
提高规范性
社区对代码的质量要求很高，除了基本的命名、格式这些之外，一个很重要的特点就是必须要有单元测试，这个根据情况，有时是新增用例，有时是修改现有用例，hbase的代码量据说有80多万行，个人目测单元测试代码跟主目录代码至少有1比1，这些测试用例很大程度上保证了一个复杂的分布式系统能够持续进行迭代升级，另外，如果patch涉及到性能影响，还需要有充分的性能测试结果；
对于单元测试，我在这么多年的工作过程中，越来越能感受到它的重要性，一方面便于迭代之后进行回归测试，另一方面也便于团队其它人员通过了解测试点并调试来理解模块核心逻辑，但就我了解，大部分团队并没有写单元测试用例的习惯，很多人也因此根本不知道如何去写，而通过参与社区可以对这方面有很大提升，无论是技能还是认知；
还有就是代码review，在社区里面，即使是committer，也不能直接commit，必须至少获得另外一个committer的赞同，并且没人反对，review的过程是异步的，虽然显得节奏有点慢，但是可以确保reviewer能够充分的理解patch的内容，这一点至关重要，有不少团队做review是定好时间找会议室一起看代码，这种方式的问题是每个人的工作进度不同，难以保证都能够在会议前充分阅读过别人的代码，临时去看的话其实很难提出有价值的问题，这种情况次数多了，大家就会认为投入这个时间的意义不大，因此放弃review这个过程；
代码review这里稍微发散一下，个人觉得里面的核心问题有2个，1是动力问题，与coding相比，review经常不被当做一个有价值的工作任务，因此缺少动力，2是方式问题，上述提到过，需要异步进行，团队工作跟系统运行一样，异步带来高效；
据说有一些大厂已经在推行类似社区的开发模式，控制commit的权限，来提高代码质量和相关过程的规范性，这无疑是很有意义的尝试；
丰富相关技术的使用经验
开源项目的复杂度往往高于公司里的各种系统，其参与者也大多经验丰富，因此对于一些常用的工具，比如git、maven、jenkins等这些，即使你平时也有在用，但也一定会从中学到不少新的东西，而这些东西对于内部应用系统的开发也带来帮助；
成就感
借助于开源项目，自己写出的代码能够运行在成千上万的设备上，还是很有成就感的；
如何成为committer
首先是源码的学习，我的方法主要是画图和写文章，过去一年多，在processon上面画了至少几十张图，包含类图、流程图、序列图等，整理的文章也有十多篇，另外就是订阅邮件列表，阅读邮件以及里面涉及到的issue，逐步试着去看懂里面谈论的内容；
然后是勇敢尝试，从文档或注释开始尝试提交issue，第一步非常重要；
最后就是坚持，需要记住一点，社区贡献是只会加分不会减分的一个过程，只要能够持续，到达目标是迟早的事情；
- 一程序员在阿里HBase团队的所感所悟(http://www.woshipm.com/it/38942.html)
- 成为HBase Committer后(https://zhuanlan.zhihu.com/p/24001780)
- 如何从小白成长为 Apache Committer(https://ververica.cn/developers/how-to-be-committer/)
- 开源项目没有那么遥远(http://servicecomb.apache.org/cn/docs/opensource-project-is-not-so-far-away/)
