参与开源，从给RocketMQ提ISSUE开始

往事

2020年9月份的一天，当时人在郑州的一个公寓的出租屋里。

因为晚上约了北京某知名的互联网公司（公司可能不够大，但很多人都听过）的远程面试，所以尽管我当时的工作是997，那天晚上我还是早早就下班回到公寓准备面试。

在面试的过程中，面试官提了一个问题：以往的工作经历中，遇到的一个比较难忘的问题。大概是这个意思，因为原话，我也记不太清了。

在我之前的经历，我也遇到过一些奇奇怪怪，或者比较棘手的问题。当时思考了一下，就说了一个关于zk的，但是在我以前工作经历中，不算太复杂且容易描述清楚的问题。

我说的问题是：我在开发分布式配置中心的时候，zk的节点在并发写的情况下，因为网络延迟而导致监听丢失的问题。

我给他简单说了下问题现象以及原因，包括zk关于监听器部分的源码实现（频繁操作zookeeper节点，客户端收不到监听通知）。

然后面试官问我，你有没有在zk的github上，提这个问题的ISSUE。

issue,对于当时的我，其实是相当陌生的一个名词。在那以前，我在github上其实并不活跃，更多的时候，可能是需要下载某个开源工具。尽管当时的我，在自己的仓库里也提交过一些乱七八糟的项目。

当时，我也未曾给某个开源项目提过issue，对issue的概念还是比较陌生的。

面试官问我为什么不提交issue怎么怎么的。原话我也记不太清了，但是我也感觉了一丝味道出来，大概他也觉得我太水了吧。

我当时在想，大概在github上提issue都是一些比较高阶的玩法，是那些资深的程序员做的吧。

那场面试也以此结束，不出意外的挂了。

给RocketMQ提ISSUE

在10月份的时候，辞职来到了北京。

迫于生活的压力和第一次来到北京的迷茫，下火车之后拖着行礼只面试了一家公司便匆匆入了职。

入职后的工作内容算是从零开始基于RocketMQ搭建一个消息平台吧。

在以前的工作内容中也有基于RocketMQ研发、演进一个消息平台的经历。这份工作相对之前的工作内容反而还算简单，毕竟这次的工作内容不涉及太多的研发工作。

我做了相关的功能测试，不同维度和数项broker参数调整后的性能测试以及监控告警平台的搭建。在这期间包括之后一段时间的使用过程中，也陆续发现了一些bug或不满足自己场景的特性需求。

大概如下：

其实都不算是太大的问题。

我现在已经记的不是特别清楚我第一次提交issue的时候，是个什么样的心情了 。大概是有一些紧张、激动吧。我花了点时间，很认真的写下了问题的原因，但是却又担心社区不给我反馈。

我最初没有提交过代码的时候，也在想，我这样也算是给开源做贡献了吧；但是又会想我又没提交代码，应该也不算是贡献吧。

给RocketMQ提pr

在提交某个issue后，有相关人员回复了我，其中有句话，大概意思是“是否可以提交一个pr”。

我当时很认真的在网上查了下pr的意思。

“你是否可以提交一个pr”，其实这句话，对我影响真的是很大的。这让我觉得是在鼓励我，尝试去提交一些代码参与一个开源项目，对于一个我这样的小白来说，这给我了一丝勇气，去参与别人的项目的勇气。

我在网上查了一下提交一个pr的流程。然后很认真的在自己的仓库里拉出来一个分支开始进行开发，并提交相关代码。

提交之后的心情大概是很紧张的，怕因为写的不好，被直接拒绝。

结果是，我提交的pr并没有处理。嗯，社区的处理速度好像一直都很慢。尽管当时每天都期望收到回复邮件，想知道是否有写的不好的地方需要调整，或者被拒绝，或者被接受。不过很久之后也没收到，又忙于其它工作，慢慢就忘了这些事。

虽然，第一次提交之后，尽管没有结果，依然让我熟悉了这个流程，后续还是尝试提交了一些pr，大部分没被接受，只有两个后续被接受了。

其实之前我一直以为都没被接受，是一年后用rocketmq最新代码做测试的时候，看到了自己写的那一点，才知道还是有被接受的，虽然可能只是一点不太重要的代码。

参与贡献ShenYu

ShenYu是一款网关，官网地址：High-performance, multi-protocol, extensible, responsive API Gateway | Apache ShenYu (Incubating)

在2021年的3月份左右，需要在公司内部落地一款网关，经过选型后，我们选择了这款，当时它还叫做Soul（记录一下落地网关soul(shenyu)过程中的一些实践）。

因为之前RocketMQ的经历，对于提交一个pr，我已经算是轻车熟路了。所以当我在使用过程发现了一个问题的时候，便提交了pr进行修复。

作者快速的反馈让我真的是非常惊喜。因为此前的经历，我以为开源项目的处理速度可能都是很慢，但是当我提交的代码被快速合并之后，这次的事情再一次给了我很大的鼓励。后续便又参与了不少贡献。

尝试开源自己的项目

在2021年夏初的时候，我花了一两周的时间，提供了一套解决方案并进行相关开发：RocketMQ主机磁盘空间有限，无限期延长消息存储的一种解决方案，类似于mysql备份binlog重新解析，我是备份rocketmq的commitlog到其它地方重新构建索引。

因为最初开发的时候，我也不太确定自己这个方案的可行性，所以开发过程中的验证代码，我都暂存到了自己的私有仓库。最后确认可行之后，我还是把这部分的验证梳理了一下（不是完整的解决方案代码，但已经基本够用），并正式的进行开源，可能很少人会遇到类似场景，所以没什么人关注。

结果最后这个解决方案，公司也并没有真的采用并用在线上。再加上我之前或者后来的一些经历，我大概明白，除非逼不得已的这些情况（对SkyWalking进行改造的相关实践记录），领导可能也不太想用我写的东西。

在2021年9月份，我需要对新搭建的kafka集群做一些测试，当时繁琐于手工命令操作，希望找一个类似于rocketmq-console的开源平台，结果找了一圈，没找到。

当时领导手里搭建了一套滴滴开源的GitHub - didi/LogiKM: 一站式Apache Kafka集群指标监控与运维管控平台 ，我想用它创建一个topic，结果给我的账号是一个开发者权限，无法创建topic。

这个事情让我很是无奈，刚好我在学习scala准备阅读一下kafka的源码，便也想用scala写点东西练练手。于是趁此机会我便打算写一个类似rocketmq-console风格的kafka管理平台给自己用。

没事的时候，或者晚上、周末的时候我便写点代码，也花了几个月陆续把自己使用的功能都给开发完了。

这个项目我刚开始写了一点基本功能的时候，便进行了开源，因为我觉得只是自己一个人用，还不如给别人也带来一些帮助，所以设计的尽量易用一点：GitHub - xxd763795151/kafka-console-ui: 一款快捷易用的轻量级kafka可视化管理平台，目前也收获了几十颗星星。

开源收获

大概是带来了更多自信了吧，毕竟说起来也算是参与过apache顶级开源项目的人，哈哈。

以前一直觉得自己的水平不咋的，现在也是。不过开源参与的多了，便没以前那么不自信了。

前几个月，在一个群里，看到有朋友说，如果给某个开源项目贡献过代码，fork这个项目到自己的仓库，会显示星星数。

看了下果然是，这可真真是个意外之喜，于是赶紧把自己的github主页整理了一下。

这样子我的主页便好看了许多，以后也敢在自己的简历上写上自己的github地址了，如果面试官打开看的话，也不是那么荒芜，大概也会给面试加分的吧。 

然后，也可以给自己加一个title了，比如：xxx contributor，前后也贡献给这几个开源项目数千行代码，完成了几个功能模块，也不全算是蹭开源项目了。