参与开源项目很难吗?
hello大家好，我是小楼。
流量真是个让人捉摸不透的东西，有时候写了一篇自己感觉牛的不行的文章，结果阅读数据惨淡，有时候觉数据可能没那么好的文章，实际数据却出乎意料。
之前的文章《惨，给Go提的代码被批麻了》就是这样，我以为就一般吧吧，没想到却“火了”。
这篇文章截止目前，发表的20天时间里，在掘金阅读量突破1w，知乎阅读量突破1.8w，头条阅读量破1.7w，微信公众号的阅读加上被转载的阅读也有1w，就连公司内网的阅读都有3k。
可以说这个数据是我从写公众号以来最好的了，但我并不觉得它是我写得最好的文章，所以就很迷。
好了，以上只是写技术文过程中的一点点惊喜，这样的惊喜是我继续写好文章的最大动力，所以动动你们的小手，点赞+在看+转发安排起来。
今天我就顺着这篇文章来聊聊大家可能都比较感兴趣的话题，开源。本文会结合自己的一些看法，从参与开源项目的收益和如何参与开源项目两个方面展开。
参与开源项目的好处
首先要明确，为什么要参与开源项目？总得对我有点好处吧。每个人可能追求不一样，所以我这里就列举一下我知道的好处，看看有没有戳中你的点。
- 小礼品
这点可能是被很多人忽略的点，因为太小了，但确实也算得上一个好处。如果你掌握了一些技巧，每年从开源社区拿点小（薅）礼（羊）物（毛）是很easy的。尤其是国内的社区，T恤、杯子、背包等等是很容易拿到的。
比如这两年Nacos、Dubbo社区送我的一些杯具：
据我观察，阿里的开源项目只要每年都去提一个PR，很大概率会送你礼物，不管这个PR是大是小，可以大到贡献一点源码，也可以小到format一下代码、修改文档中的一些错误、增加一个单元测试等等，所以是不是学到了薅羊毛的技巧？
- 朋友圈素材
这点只是满足一下虚荣心，其实并没有什么卵用，但还是提一嘴，比如下面这些素材，是发朋友圈装x的利器：
- 装饰简历
如果你有参与开源项目的经历，写到简历上一般是个加分项，说一般情况是因为我在面试的时候遇到过候选人在简历上这样写：
参与贡献过上万star的项目。（后面还贴上了项目地址）
一看这句描述就有猫腻，为啥强调上万star却不说出项目名称？于是我打开后面的github地址发现，原来这个上万star的项目是个聚合在线学习资料的项目。
不能说参与这样的项目不好，只是简历上这句话让我感觉在打擦边球，所以不但没有加分，反而减分了。
一般来说对项目有过贡献，无论大小，都可以称之为Contributor，贡献达到一定程度则称为Committer，达到多少贡献才能称为Committer一般每个社区都有自己的衡量标准，比如Nacos社区有明确的规定：
翻译下就是：至少有8个PR，团队协作能力，理解项目的代码风格，能写出优秀的代码。当然也有很多社区没有明文规定，总之就是贡献越多越有可能成为Committer。
所以在简历中如果你是某个项目的Committer就很厉害了，一词胜千言。退一步就算不是Committer，如果你有一些比较重要或者核心的代码提交，也可以写上，附上具体的issue。如果只是代码的format、增加一些单元测试，我建议简历上就不要提了。
- 能力提升
通常开源项目的代码、设计、规范都是比较优秀的，和优秀的人一起共事能成长更快。
一般我们在参与开源项目时，都是使用英文来交流，所以对你的英文书写能力是个提升。
其次代码规范、测试能力、考虑事情的全面性都将得到锻炼。
以我个人的感受来说，虽然嘴上说写代码要规范，但在公司写代码的时候，有时候就不太注意，都是以快速完成任务为目标，但开源项目不一样，你写的每一行代码都要被众多的大佬一行一行地review，只要有一点点不满意都会要求你修改。
测试也是如此，你写的每一行代码都将被代码测试，单元测试、集成测试。开源项目更相信用代码测试，所以这也锻炼了你写测试和写代码的能力，写出代码不难，写出容易测试的代码还是比较困难的。
- 提升影响力
这是更高层级的追求，当你想在技术上走的远的时候，需要一些业界影响力，这时，参与开源是个不错的选择，能结识更多的圈内牛人，也让大家能认识你，你的圈子、人脉就会扩张。
提升影响力有什么作用呢？最直接的是，让别人知道你的存在，下一次机会来临时，说不定你会被看中或者推荐。
当然我离这个层次还很远，只是说一点自己的理解。
如何参与开源项目
- 参与开源的方式
上文其实也提到了，参与开源项目不一定是直接的贡献源码，也可以是对文档的编写或修正、写一些单元测试或者测试用例、也可以写一些开源项目相关的文章。
比如我在去年写《Dubbo为什么要用Go重写？》这篇文章时，就顺手把Dubbo-go项目的README改了
还有比如在写《使用dubbo-go搭建dubbo接口测试平台》这篇文章时，把这篇文章投稿给了Dubbo-go官方网站，也被收录进去
这些都算是对开源的一种贡献。当然如果你有代码的直接贡献是最好的，这也是获得技术成长最快的方式。
- 从哪里开始
如果我们平时工作中用到什么开源项目，没事的时候可以把源码下载下来翻一番，可以按照文档跑起来，打上断点看看是否跟自己想的一样，这时我们便有了一些基础，可以去github上的issue找找，一般的项目会把issue分类，可以从标了good first issue或者bug标签的issue看起，看看有没有自己能解决的，再结合代码，一步一步调试。
这种方式目的性比较强，我就是冲着提交代码去的，而且比较有时间去研究，目前我还没用过这种方式，我更多的是下面提到的这种方式。
另外一种是如果我在使用开源项目的过程中发现了一个bug，或者一个可以优化的点，可以去github上提个issue先讨论讨论，如果社区的人也认可你的观点，可以把你的修复或者修复作为一个PR提交上去。
这个方式我在Dubbo/Sentinel/Nacos/Skywalking/Go中都是这么干的，都是平时遇到的一些问题，反哺到社区。
发现问题往往比解决问题更困难，开源项目也是如此。
等等，在你想提交代码前，我建议你好好看看开源项目的规范，一般位于项目的README或者官网中，他对issue有什么要求，对代码有什么要求，对commit message等等都有什么样的要求，如果不按照这些规范来提交，可能你的下场会和我一样，一个字「惨」。
- 提交代码流程
这一步网上资料比较多，我这里只说个大概的流程，具体到每一步我相信你能在网上找到更详细的教程：
- 提issue讨论（不是必须，有些项目可以直接提代码）
- fork代码仓库
- 在fork的代码仓库拉一个分支，并把代码提交到这个分支上
- 签署Contributor License Agreement（简称CLA）
- 在这个仓库上向原仓库发起一个PR
- 等待代码Review反馈，并按照反馈修改
- Merge进代码仓库，贡献完成
最后说一句
万事开头难，往往第一个PR是最难提交的，如果尝试着提交了，我相信你会打开新世界的大门。
对了，虽然我参与到开源项目的经验不够多，但可以给你一点参考，有正例也有反例
- https://github.com/golang/go/pull/50023
- https://github.com/dubbogo/dubbogo.github.io/pull/7
- https://github.com/apache/dubbo/pull/8066
- https://github.com/apache/dubbo/pull/7929
- https://github.com/alibaba/nacos/pull/2403
- https://github.com/alibaba/Sentinel/pull/1045
- https://github.com/alibaba/Sentinel/pull/104
- https://github.com/apache/skywalking/pull/2930
- https://github.com/apache/skywalking/pull/2874
好了，今天的分享到此为止，如果文章中写的有不清楚的地方，也欢迎加我微信MrRoshi私聊，我们下期再见！