该文章内容发布已经超过一年，请注意检查文章中内容是否过时。
我是一个有Dubbo情节的程序员。
Dubbo以不同方式，陪伴了我时间不长的整个代码生涯。不久前，通过社区投票，我被选举为Committer。当时我在朋友圈发了一句话，也是贯穿我从开始使用Dubbo、研究Dubbo、贡献Dubbo到最后成为Committer的全过程，一直为我提供内心无与伦比愉悦的源泉：成长这种事，能看见脚印特别幸福。
今天来个回忆杀，把我和Dubbo的那些事拿出来说说。
我知道Dubbo，是在我大三翘课出去实习的时候，那个时候是无知的，我眼里最牛的人就是能熟练使用各种配置，精通SSH框架的人。就是在那种情况下，我外出实习，遇到了一群影响我至今的人。当时也是机缘巧合，我们进行了两个非常小的模块的服务化改造。那时的团队除了我们老大，全是一群新兵蛋子，老大指哪我们打哪。老大说，就用Dubbo吧，从那时候开始，我才知道，哦！原来还有一种东西叫做RPC，还有个阿里巴巴的RPC框架叫Dubbo。
苦于当时非常有限的水平和高强度的工作，我和Dubbo的缘分也就停留在一面之缘的程度——要说认识谈不上，说不认识也牵强。
我在二维火任职的一年算是我Dubbo生涯里承上启下的一年。二维火当时自己维护了一个Dubbo的分支，有一群对Dubbo非常了解的人。那时候，工作结束搞Dubbo，周六加班研究Dubbo。看源码，看不懂就debug一下，debug也不明白就问，问人，问google，里外折腾了个遍。
后来毕业加入网易云音乐。大概是今年五月份的时候，我发现了一个Dubbo的小bug，并且给Dubbo提交了pull request。在第一次被merge之后，非常受鼓舞，这才有了后续的故事。后来，回看这第一次提交，真的算是我和Dubbo的一个拐点，拐弯之后，我才逐渐走上一条成为Committer的路。
可能很多人看到这里要望而却步了，这也是做开源给很多人留下的固有的印象——是不是没发现BUG就不能提交pull request，不能做贡献？其实完全不是的，这里给大家敲黑板划重点：其实很多贡献者的第一次贡献，贡献的并非代码，而是文档修改或者单元测试。相比于BUG或者新的Feature，单测和文档上的修复门槛就比较低了。
我自己的方法论就是：先尝试增加单元测试，写单测的时候顺手debug+看代码。或者多看文档，了解框架的同时，发现错别字、语意不明或者文档上的链接干脆点不开的情况，直接提交PR到对应的仓库。
万事开头难。第一次被merge代码，你就可以成为一个Contributor了。Contributor很多，但是Committer很少，下面继续说怎么从一个Contributor成长为独当一面的Committer。
做开源和写代码一样，都不是一朝一夕的事情，而是量变促成质变的过程。这是一个没捷径可走的过程，欲带皇冠必承其重。身后的Dubbo功底自不必多说，这个部分主要是想跟大家说一下除了钻研和热爱之外，其他需要注意的地方。
首先是多提交高质量PR。任何一个PR都会被review，代码中的问题，思路上的偏差，都会被指正。提交PR是一个反复琢磨的过程。PR的质量不能简单的归结于新增了多少行代码，高质量的PR一定是经过缜密思考的，为什么删除代码，新增的代码有什么意义，修改之后有什么效果等等。希望大家更加重视质量而非数量，眼光放长远，相信你的收获一定会非常大！
第二个就是，我们需要培养一种思维方式——Apache Way。一句话概括就是社区重于代码。Apache是一个注重社区的的开源组织，其行为方式相比于目前我们的开发方式，还是有所不同，这里我举一个Apache Way的例子，用以说明传统方式相较于Apache Way的区别在哪里，这里假设我想为Dubbo开发一个功能A。
Old Way：
可以看到，我们整个过程中，真正与社区交互的只有最后一步。
Apache Way：
可以看到，Apache Way就是在整个开发过程中，不断地与社区交互，最大发挥社区的功能，汲取众人之力，这才是所谓社区以及所谓开源的含义。
Dubbo目前还在孵化阶段，整个Dubbo社区还不完善，我们也在跟着Dubbo一起成长，我们非常希望更多的Dubbo爱好者深度参与到Dubbo中，为你的代码生涯树一个里程碑。
相信过程，收获结果；天道酬勤，功不唐捐！