如何从零开始成为 Apache 软件基金会的 Committer
最近收到了 Apache OzHera(Incubating)社区的邀请邮件，正式成为了这个项目的 Committer。
从年初的什么都不知道，到如今活跃在各个开源项目里的“老兵”，用现在比较流行的话来说，拿到了 Apache Committer 的资格，就相当于开源上了岸，进入了新的阶段。
下面就分享一下我的个人开源经历，希望对想要参与开源或者已经在其中的同事有所帮助。
初探开源社区
2024年2月，我负责的一个项目上线后，客户反馈数据导出速度太慢，希望能尽快优化。同事建议我试试阿里巴巴的开源项目 EasyExcel 来替代 POI。照着网上示例一番捣鼓后，项目的数据导出效率果真大幅跃升，效果立竿见影。最终项目交付顺利，也得到了客户的肯定。
可我心里却总像揣着个疙瘩：底层都是使用poi，但是速度竟能相差十几倍。这里面的原理究竟为何？自己竟全然不知，仅做了个依葫芦画瓢的 “搬运工”，这让骨子里不服输的我深感不甘。
从那时起，我利用周末和休息时间钻研 EasyExcel 源码，也学习了 Excel 的一些规范和原理。随着项目研究的深入，我留意到 GitHub 上 项目的 issue 区里，诸多使用者提出形形色色的问题，其中不少是我在自学中遇到并解决过的。起初，我只是默默比对、暗自思索，确认自己的理解无误后，才敲下解决方法，试着为他人答疑解惑。
事实上，每次回复都像是一场知识的 “反刍”，在梳理思路、组织语言的过程中，那些原本稍显生硬的知识点愈发融会贯通。掌握的知识愈发扎实，修复 BUG 和优化代码的底气也越来越足，我开始提交各种 PR，慢慢成为了社区中的常见开发人员之一 。随着在项目中的贡献越来越多，我也在6月正式受邀成为 EasyExcel 的外部协作者。
参与 Apache 项目
Apache OzHera
2024年，我的年度技术目标之一是实现业务项目的监控和排查。为此，我调研了多个相关开源库，例如 SkyWalking、HeartzBeat 等。经过一番比较，我发现 Apache Ozhera 最符合我的需求。而巧合的是，Ozhera 当时刚刚开源，正处于需要社区贡献的阶段，于是我决定加入，双方一拍即合。
因为项目刚起步，所以前期最重要的反而不是功能开发。而是整体迁移至 Apache 的组织下。平时接触的Kafka、Dubbo 等项目，看上去更新版本很快。但是真正参与到 Apache 项目中来，发现自己还是想得太简单了。
首先是版权商标问题。 Apache 要求所有的必要文件都要添加版权声明，同时也要符合 Apache 的相关规范。这意味着要将最基础的类路径，全部转换到 org.apache 的路径下。
这个过程从第一个 PR 到社区提名我大概经历了半年的时间。
越大型、严谨的项目在处理这些 PR 时就是缓慢的，所以如果你真的想深度参与某个项目时就一定要有充分的耐心。
首先坚持下去，收获自然就来了。
Apache Seata
今年十月份的时候我在朋友圈还看到另外一个项目：Apache Seata
因为当时我也在做一些数据库的分布式事务的研究，正好这个项目的文档比较友好，于是我就跟着文档走了一遍。
发现功能很强也很全，当时也是刚加入 Apache 的孵化器，所以还是有许多可以完善的地方。
我就开始以单测作为切入点尝试贡献源码，社区的响应速度也非常快。
之后逐渐将我在其他社区学到一些经验也复制到seata中，慢慢的贡献的代码越多，对 seata 也就更加熟悉了。
成为 Committer的好处
Github Copilot
第一个好处是可以免费使用 GitHub Copilot。需要说明的是，这并非 Apache Committer 专属的权益，只要你是某个开源项目的活跃贡献者，就可以尝试申请免费使用（不过申请通过的标准目前并不明确）。然而，如果你已经成为了 Apache 项目的 Committer，那么申请通过基本上是板上钉钉的事。
JetBrains
Apache 邮箱
提到邮箱，就不得不提到 Apache 会为每个 Committer 提供一个专属的邮箱。虽然市面上有各种免费的邮箱注册服务，但当你使用 Apache 提供的邮箱与他人沟通时，往往会给人一种更为专业、可信赖的印象。大多数人可能并不会直接说出来，但在潜意识中，看到一个 Apache 邮箱，往往会对你的技术能力和背景有更高的评价。
虽然这并不是硬性实力的体现，但它确实能够在一些需要展示自我或建立信任的场合，让沟通变得更加顺畅。
项目的写入权限
还有一个好处就是，成为 Committer 后，你将获得项目的写权限。对于参与开源项目的开发者来说，这个权限是至关重要的。很多时候，当你提交一个 PR 后，可能会遇到审核进展缓慢，甚至长时间得不到回应和合并。那时你只能等待，或者反复催促，确实让人非常不爽。
然而，一旦你拥有了写权限，在 PR 获得他人批准（Approve）后，只要风险可控，你就可以自己合并，不必再依赖 Maintainer 来处理。这大大提高了工作效率，减少了等待时间，使得项目的开发进程更加流畅。
同时，由于在社区中的活跃度和参与度得到提升，你的 PR 会更容易受到重视，并且你可以更积极地推进某些功能的开发。这不仅对于你的个人成长和贡献感是一个很大的动力，对于依赖该开源项目的公司和团队来说，这也是一个重要的优势。能够及时合并关键的修复或功能，极大地提高了开发的响应速度和项目的健康度。对于需要快速迭代的企业，尤其是依赖某个开源项目作为基础设施的公司，能从中受益良多。
Apache 成员组成
相信看到这里，应该会有不少人对成为 Apache Committer 产生兴趣，也对究竟需要达到什么样的标准才能成为 Committer 感到好奇。
以下是 Apache 官方提供的贡献阶梯，希望能帮助大家更清楚地了解这一过程。
整个路径其实是比较清晰的，但从 PMC 开始到后面的董事，难度可以说是指数级增加。目前在国内，当选 Apache 基金会董事的人屈指可数，由此可见其中的挑战。
至于成为 Committer 的要求，有些社区会有比较明确的标准，比如提交了多少个高质量的 PR、参与了多少次 Code Review、推动了多少个 Issue 的解决等等。但这些标准并不是一成不变的。不同的社区对于活跃贡献者的评估可能略有差异，有些更看重技术贡献，有些则更注重社区建设的参与。
核心的一点是 “持续活跃”。只要你在社区中保持持续的贡献，无论是修复 Bug、完善文档、参与讨论，还是推动项目的进展，当你的名字和头像变得熟悉后，自然会有相关的 PMC 成员提名你成为 Committer。
总结
参与开源的这一年，最初是出于纯粹的兴趣驱动。这种兴趣源于解决技术问题的满足感。然而，兴趣虽是动力，但要在繁忙的工作与生活中挤出时间参与开源，却并非易事。
在这一年中，我大部分参与开源的时间，都来自于休息和周末。利用零散的时间处理 Issues 或者修复 Bug是常事。而一些复杂的功能开发，往往需要投入更多的精力。有时候，为了解决一个疑难问题，甚至会在晚上通宵复现、排查、修复，直到把问题彻底解决才去休息（印象最深刻的一次，是周五晚上下班到家，就开始处理issue，一直到周六上午11点才全部解决完，上床睡觉）。
很多时候，开源的确是“为爱发电”，没有任何报酬，甚至一些项目因为各种原因，可能会走向停止维护的结局——比如 EasyExcel 的经历便是一个例子(现在迁移到了FastExcel）。随着时间推移，合并的 PR 可能不像最初那样带来强烈的成就感，但每一次的贡献依然是对自己努力的回报。
目前来看，我只是刚刚迈进开源世界的大门，半只脚站稳，另一只脚仍在探索。至于更高的层级，比如 Apache PMC、管理人员，甚至董事，那些位置对我来说还十分遥远。如果有一天，我真的有幸走到那一步，再和大家分享这一路的风景和感悟。
特别说明
此文章的整体架构，来源于crossoverjie的博客。crossoverjie 是一名技术强、爱分享的技术专家。欢迎大家关注他。
参考链接：