从开源小白到 Apache Member , 阿里工程师的成长笔记

阿里妹导读: 2019 年 5 月 4 日, Apache 基金会官方 Blog 中宣布全球新增 40 位 Apache Member, 阿里巴巴技术专家望陶成为其中之一. 全球共有 771 位 ASF Member, 中国仅 13 位. 他从一个 0 基础的开源小白, 一路走来, 感触颇深. 今天, 望陶把这段经历分享出来, 让更多的人能够看到, 其实参与开源并没有那么难, 只要持续的付出, 总会有所收获.

阿里巴巴编程之夏火热报名中, 点击文末 "阅读原文", 参与开源共建!

初次参与开源

2014 年我加入阿里巴巴中间件团队, 开始接手阿里巴巴集团应用容器的维护工作. 当时集团的应用容器绝大部分都是基于 JBoss, 老旧且无人维护, 另外有一小部分跑在 Jetty 和 Tomcat 之上, 当时中间件团队维护了 Tomcat 的一个私有分支, 最大的目标就是要统一所有集团的应用容器为 Tomcat . 而在那之前我从未接触过 Tomcat 的开发和运维, 对我来说挑战还是很大的. 然而更大的挑战来自于当时带领中间件的大老板, 大老板提出了一个在当时的我看来几乎无法实现的目标 -- 成为 Apache Tomcat 的 committer.

要知道, 作为 Apache 的核心项目之一, Tomcat 自 1999 年发布第一版以来, 一直是开源届和 Apache 基金会明星项目, 至今仍然在应用容器领域市场占有率保持第一, 历经 20 年发展依旧热度不减. Tomcat 历经这么多年的发展, 却从未出现过一个中国人的 committer. 而我们小团队只有 4 个人, 根本没有任何搞开源的经验, 完全不知道从何做起. 老板向我们交代这个任务, 问我们谁愿意挑战一下的时候, 我也没有多想, 就承担了下来. 就这样, 我开始了 Apache 开源之旅.

说实话, 一开始其实自己并没有太多的思路, 于是开始反复浏览 Tomcat 官网, 希望能够查询到一些有用的信息. 所有的 Apache 项目几乎都会有新用户指南, 一般会介绍如何参与到此开源项目当中, Tomcat 也不例外. 很快我从修复 bug 开始, 第一个 patch 是修复一个 websocket 测试用例失败的问题, 修复该问题涉及到了对代码的一些重构.

还记得当时提交之前我非常谨慎, 和老板一起反复讨论了很多次, 终于形成了一个比较满意的方案. 提交给 Tomcat 社区之后, 很快社区便有了响应, 并合并了我提交的补丁. 第一次提交便获得了认可, 心里很开心, 紧张的情绪也缓解了. 看到 Tomcat 的 release note 里面出现了自己的名字, 真的非常开心.

Apache Roadshow China

2015 年 10 月, 我有幸在北京参加了 Apache Roadshow China, 算是第一次和 Apache 基金会有了亲密接触. 在大会上亲眼目睹了时任 Apache 基金会主席 Brett Porter,Apache 基金会副总裁 Niclas Hedhman 等大佬们的演讲, 以及在 Panel Disussion 里面, 几位大佬和几位来自中国的 Apache 成员的一起探讨社区领导的开发流程等.

当时觉得自己离他们似乎非常遥远. 2015 年的时候, 国内参与开源 Apache 社区的几乎全是在外企工作的华人. 而如今来看, 国内公司参与开源的程度已经显著地提升. 这次参与中国路演, 有幸和 Niclas heldman 做了一些交流, 我问了他一个问题: 我正在参与 Tomcat 社区, 如何才能成为 committer? 他给了我一些至今对我影响依然非常深远的建议: 参与社区讨论, 从简单的新手任务入手修复 bug, 以及参与 release vote. 而这么多年过去了, 这些建议依旧适用.

Tomcat committer

尝到了贡献的甜头后, 后面团队的目标也有所调整, 内部版本的 Tomcat 和开源版本的结构, 保持完全一致: 一方面使得合并开源 Apache Tomcat 变得非常容易; 另一方面, 内部做的增强也更加方便合并到社区. 后续向社区的贡献主要来源于三个方面:

第一个方面是阿里内使用 Tomcat 在大规模, 高并发场景下遇到的问题修复. 比较典型的是当时无线网关应用采用的是 Tomcat NIO+Async Servlet 的架构. 作为一个入口应用, 曾经因为 Tomcat 在高并发下的异常出现过一个比较大的故障, 后来排查这个问题花了非常多的精力, 最终彻底修复了这个问题. 详细的排查过程记录在《逆流而上 - 阿里巴巴技术成长之路》一书的《山洪暴发, 高流量触发 Tomcat bug 引起集群崩溃》文章中. 修复方案也一起提交给了 Tomcat 社区, 虽然改动量不大, 但其中凝聚了团队相当多的心血.

第二个方面是 Tomcat 大面积在阿里铺开的, 遇到的问题修复, 比如发现了一些不符合 servlet 规范的行为等, 包括双十一应对的时候所做的一些优化, 并行类加载等等.

第三个方面是主动参与开源社区, 针对一些一直存在的问题的修复. 经过一年多的持续投入贡献, 2016 年 8 月 23 日, 在一个平常的工作日的上午, 我打开邮箱, 看到一封来自 Tomcat 社区核心开发, Java EE 规范专家组成员, 时任 Apache 基金会董事会成员 Mark Thomas 的来信, 邀请我成为 Tomcat committer. 打开邮件那一刻感觉自己的心都在颤抖, 激动之情有点不能自已. 当时的确出乎自己意料, 没有想到梦想的那一天真的会到来.

Tomcat PMC Member

成为 committer 之后, 有了代码的直接提交权限, 其实意味着更大的责任. 那一年 Tomcat 已经成为了阿里内部应用容器的标准, 集群的规模在国内外也是领先的. 而我也并没有停止社区的参与, 直到 2017 年, ApacheCon 北美大会即将在 5 月美国迈阿密召开, 收到 Call for participation 邮件的时候, 我突然萌生了一个想法, 为什么不把阿里巴巴在大规模高并发下遇到的挑战在 ApacheCon 大会上分享呢? 每年的 ApacheCon 基本都会为 Tomcat 开设专场, TomcatCon. 之前从来没有在国外大会上分享的经验, 也不知道能否被大会接受, 我怀着忐忑的心情提交了提案, 也没有抱太大的信心. 直到那年 3 月, 我收到一封邮件, 通知我的提案被 ApacheCon 大会接受了, 那种被认可的感觉真的很棒.

在 5 月份的大会上, 我有幸见到了经常在社区里面交流却素未见面的一群开发者, 比如来自英国的 Mark Thomas, 来自美国的 Christopher Schultz, 来自法国的 Jean-Frederic Clere 等等, 他们都是 Tomcat 社区的顶尖专家, 有的甚至 10 余年来一直参与在 Tomcat 社区. 和之前邮件讨论起问题来非常的直率, 甚至是严厉的印象不同, 他们都非常的亲切, 演讲当天也在场下默默地支持我, 演讲很成功, 让世界看到了一个中国公司在 Tomcat 社区所作出的贡献努力, 我觉得挺骄傲的. 演讲第二天的晚宴上, 气氛很轻松, 台上正在进行着闪电演讲, Mark 拿着啤酒走过来和我说, 邀请我成为了 Tomcat PMC member. 天啊, 我完全没有想到能够和面前这群大神们站在同样的位置上, 很开心地接受了.

结缘 Dubbo

2017 年, 阿里正好开始重启了 Dubbo 开源的维护工作, 而团队正好承担了这一重要使命. 当时 Dubbo 在之前的一段时间里面停止了维护, 社区的很多用户只能选择 fork 分支自己维护. 重启维护之后, 需要思考的问题是, 社区会不会有类似的担心. 为了打消这个顾虑, 团队决定把 Dubbo 捐献给 Apache 基金会, 希望能够通过 "社区大于代码","公开透明","共识决策" 等 Apache 之道, 打消顾虑. 已经有过几年 Apache 社区参与经验的我, 自然地承担起帮助 Dubbo 进入 Apache 基金会孵化的工作, 从联系导师到修改提案, 终于 Dubbo 通过了 Apache 孵化器社区投票, 正式加入 Apache 孵化器进行孵化. 那天是 2017 年的大年三十, 我坐在家里的电脑前, 发送出正式投票结果邮件的那一刻, 我在想这注定是个值得铭记的日子.

在 Apache 孵化器中孵化, 就像一个浪子在江湖上横冲直撞了很多年后, 突然静下心来开始求学, 自然要循序很多规则, 也会有很多的文化和意识心态上的冲突. 我开始思考如何能够帮助 Dubbo 更好地践行 Apache 之道, 这里面有很多东西需要做. Dubbo 和其他项目不同的一点是, Dubbo 在加入 Apache 之前已经是一个巨无霸级别的项目了, 上万的 star, 庞大的社区, 国内大规模被采用, 社区一天的活动量所发送的邮件就会让导师觉得无所适从, 简直没有办法看了. 如何能让这个巨无霸按照 Apache 之道发展, 成为了一个很大的挑战.

有一个很鲜活的例子, 当时社区在讨论到底应该在邮件列表上还是在 GitHub issue 上讨论问题. 而 Dubbo 的用户早已经习惯了在 GitHub issue 上讨论, 但是导师之一的 Mark 却指出, 邮件列表仍然是这个星球上最为普适的通讯工具. 当我们习惯了中国近几年互联网迅猛发展带来的红利的时候, 却忘记了这世界上还有一些国家, 在某些环境下上网的网速可能只有几十 k/s, 甚至只能拨号上网. 如果在 GitHub 上讨论, 那对于这些环境下想参与社区的人就是灾难性的. 或许我们可以放弃那部分用户, 但这并不是 Apache 的价值观. 类似的例子还有很多, 我有点遗憾没有及时把他们都记录下来. 我会尝试在另外一篇文章中分享.

来源: https://yq.aliyun.com/articles/704943