成为 Apache Committer 只是我投身开源社区建设的开始
本文已由 Apache EventMesh 公众号转载、ALC Shenzhen 转发。
新晋 Apache Committer
感谢 Apache EventMesh PMC 邀请我成为 Apache EventMesh Committer。Apache 软件基金会建立于 1999 年，25 年来在全球范围内共计推选了 9199 名 Committer。很荣幸能成为全球第 9200 名 Apache Committer，如愿拥有了属于自己的 Apache 邮箱。
Apache 开源社区的魅力
契机
动笔写下这个章节的第一个字时，是我在 GitHub 上泡了一整天之后。Good First Issues 和 What are we doing now 这两个重要的 List 已经近半年没有人维护了，我根据自己还只是 Contributor 时整理的笔记，将零散的代码改进点创建为新的 good first issue，供想要参与开源的新人练手。
令我意外的是，就在我建了两个低难度的 issue 之后，十分钟不到就已经双双有人认领。有新面孔来做 good first issue 的时候仿佛已经过去很久了。Good First Issue List 中的任务大多都早已有人认领，但提交的 PR 在被 Review 之后就杳无音信，又或是没有提交过 PR。
原来关注着社区的人并没有减少，只是留给他们的契机变少了。回想到我自己，谁都需要这样的一个契机。
能力越大 责任越大
配置好 Committer 权限的第一天，我就在邮件列表里创建了 50 条回复。我跟进了几乎所有长时间没有进展的 PR 和 issue，在具有 Committer 权限后的半个月里，邮件列表中发送了超过 200 封邮件。
成为 Committer 之后，我更加确信：在开源社区，Committer 身份的意义就是 “能力越大、责任越大”。我可以不用麻烦别人过来关闭一个过时的 issue 或是打上一个 help wanted Label，而是可以出于个人的主张自行维护；我的 Approve 不再是灰色的 “意见”，而是绿色的 “肯定”。推选为 Committer 是社区对你的一种认可，这意味着你可以独当一面，而不用事事询问 PMC。
我意识到我是突然这么活跃的。大家在开源社区里能投入的时间都是有限的，没有人能够长此以往地全身心地为社区 Review 每一个贡献。但开源社区就是这样运作的 —— 没有谁需要牺牲什么来去达成什么，也没有谁无可替代地具有这个 PR 绝对的话语权。
我看到了，我有话要说，所以我 Review。这是最自在的 Reviewer 动机。
这群人
GitHub 的 Issue 和 Pull Request 很强大，但它只是提供了一个问题追踪的平台而已。若是想要细数一个开源社区的里程碑，像是亲历者一样历历走来，这时你就记得邮件列表的好了。
相比于一天动辄十几封邮件的 dev 和 issues 列表，users 邮件列表要来得清净的多。这是 EventMesh 最早从项目进入孵化器之初就开始活动的邮件列表，用于发布项目的里程碑、解答用户的疑问，也是能够看到如今在工作和开源两端忙碌着的明哥和陈老板在两年前是怎样的一个青涩模样的地方。
PMC Chair 陈广胜发起了一个针对 EventMesh Logo 的讨论，初始成员们在下面有序地发表着自己的意见，邮件的附件中还带着他们中意的 Logo 截图，而项目的孵化器导师 Justin 则在下面有点气又很礼貌地提醒不要跨越多个邮件列表发表回复。
看到这里，我回想起来，在我和 Justin 合影前介绍自己时，我说，我是来自 EventMesh 社区的贡献者。他说，“哦！我知道这个项目。”
那时的我没有多想，但现在的我突然意识到，Justin 的眼神里有一份肯定，就像是把孵化毕业的项目当作了自己的孩子一样。EventMesh 历时两年多的孵化，23 年 2 月毕业成为 TLP 顶级项目，几个月后就能有社区培养的贡献者与孵化器导师线下见面，在 Justin 指导的项目中应该也是少有的吧。
这篇讨论令我有些忍俊不禁，如果这群人这样的讨论发生在现在，我想我得在会上笑出声来。
这就是开源社区的魅力之一。相比于 “开放源代码” 这字面意义上的含义，有着一起玩开源的这群人才更难能可贵。发现并培养喜欢开源的成员，也正是 PMC Member 和 Committer 们的职责。
Committer ≠ Reviewer
不得不感慨的是，新兴的 EventMesh 社区中被提名为 Committer 后持续活跃超过半年的 Reviewer，与 ASF 中的热门项目（例如 Kafka）相比，还是有些少。从项目进入孵化器开始，每隔几个月都能在邮件列表中见到新 Committer 公告，都是我在几年前的 issue 里见到过很多次的身影。他们曾经做出了很多贡献，如今却完全见不到他们来提 issue、Review PR 了。
23 年 8 月到 10 月的这段时间，我有实习，还要进行秋招，但我在开源社区依然稳定地每周提交 1~3 个 PR，同时 Review 其他人的 PR。在我心中，开源的优先级更高，因为我知道，这是更快提升个人技术实力的方法。也正是因为我在开源社区的积累，帮助我拿到了大厂的 ssp offer。
但在接下来的一个月里，我忙于选 offer，花时间调研业务的前景，暂时停下了开源的脚步，因为选择往往比努力更重要。此时一些能够决定我的命运的事情的优先级被置于开源之上，那么对于其他人而言，也一定时常有令其不得不放下开源的事情。毕竟，玩开源只是一个非常有意思、也很有意义的兴趣。
无论如何，他们都是 Apache 的荣誉 Committer，毕竟每个人都有自己的事情。同时满足 “不受雇于项目的母公司”、“出于个人兴趣参与开源”、“能花时间 Review PR”、“能参与项目发展的讨论” 这些条件的 Committer 还是少数，而这些 Committer 才是很多社区最为刚需的成员。
学生如何通过开源之夏成为 Apache Committer
开源的初心是很纯粹的，Apache Software Foundation 的存在只是为了在法律意义上保护项目和开发者们。
开源之夏只是你接触开源的众多理由中的其中之一，它是比较适合在校生参与开源活动的一个起点。
有很多同学问过我开源或是开源之夏的窍门，希望这个章节能对你有所帮助。
抓住开源之夏这个契机
你可以带着功利心去接触开源，但这并不妨碍你从中获得乐趣。为了简历好看方便校招也好，单纯参加比赛顺便领个奖金也罢；想要从同龄人中脱颖而出，又或是不满于工作中所写的冗长的业务代码 —— 与其漫无目的地半途而废，不如怀揣着一份荣誉或愿望。真正参与到社区中后，你会自然而然地把 Committer 和 Apache 邮箱当作一种能力的象征和自己的里程碑。
相比于走上开源之路却没能坚持下去，更多的人缺少的是一个契机。开源之夏就是很好的一个契机，谷歌、中科院、CCF 和一些大厂都有在办。一个课题、一位导师、一位学生，资源分配合理，哪怕导师在工作上再忙，也能分出精力去指导学生。只要学生愿意虚心请教，就不太容易出现闷声撞墙的情况。导师也希望你能够顺利完成课题，因为这不仅关乎着社区的声誉，导师也想要对你申请课题时的认真态度作出回应。
Apache 的开源社区欢迎新面孔。相比于与其他候选人比较而踯躅，不如多花一些时间参与到社区的交流过程中。做一两个 good first issue 或者参加双周例会都是很好的起点。就算没能中选，在自己的代码被 Review 的过程中也能稳步地提升自己的编码实力。
专注于开源，而不是开源之夏这个活动
课题没有中选，不代表你的开源之夏结束了。能拿出来作为一个课题的特性只占社区想做的特性中的一小部分，通常还是比较简单的那一批。参与开源没有门槛，无论课题的申请截止与否，也无论学生是否是课题的候选人，只要你阅读过贡献指南，按照格式提交 PR，说明自己修改的内容和目的，社区都会同样重视。你甚至可以与中选者合作，毕竟有的课题是需要持续迭代下去的，需要周边生态的配合。如果有人，不是为了比赛，依然能出于兴趣去做这件事，我觉得会更受人关注。
因为开源之夏，你已经认识到了去做开源的这件事情。如果你不是那种需要 deadline 推着走的 type 的话，按照你的节奏去加入社区就可以了。大多数参加开源之夏或者 XX 比赛的同学都只是将课题视为一个任务，没有持续地做下去。事实证明能不能获得 Committer 提名也与比赛有没有获奖根本没有关系。贡献的多少是由社区的大家看在眼里的，只要你能在一个社区有持续性地贡献，都能被认可，并成为相应模块的专家。
不要只是抱着 “学习” 的心态参与开源社区。一个 Apache 项目是你不可能在短时间内看完并理解的，你也不需要 “学完” 它才能上手。经验是在实际优化代码、阅读 git commit 对应的 PR 的过程中才能积累的，没有机会会乖乖等到你准备好了再让你抓住。哔哩哔哩上通常会有项目的 Meetup，可以让你很快理解重点。
纪念
写下此文，更多的是为了自勉。疲惫了也好，稍作休息也罢，读一读过去的自己，以此明志，总能重拾热情。感谢在我朝着目标努力的路上注视着我的各位。
