Gravitino Committer 成长之路(1)


成长道路

贡献时间轴

从 2024 年 12 月 6 日合并了在 Apache Gravitino 项目的第一个 PR,到 2025 年 7 月 3 日正式成为 Committer,一共经历了 7 个月, 209 天。在这段时间里,我共提交了 127 个 PR,合并了其中的 124 个,累计增删代码超过 5 万行,主要贡献于 Gravitino 核心框架及其附属的 MCP 项目。

我想通过几期博客,分享一下,我作为一个用户,是如何在开源项目中,从“贡献者”一步步赢得社区 PMC 的信任,最终成为 Apache Committer;以及,开源又如何在这个过程中,为个人和企业带来实质性价值。

我的博客将会分为两期

  • 第一期主要介绍"为什么参与开源"以及 “ASF 社区生态”
  • 第二期主要介绍"成为 Committer 的关键路径"以及"我的收获"

为什么参与开源

企业视角

从企业视角来看这个问题,参与社区开发有如下几个好处:

  • 提升技术影响力:将改进贡献开源可降低维护成本、提升影响力,让企业从适配者转变为生态共建者;
  • 了解行业需求:开源社区连接真实需求与技术趋势,助力企业洞察痛点、优化产品设计与研发决策;
  • 开源是最实战的培训平台:开源提供真实项目环境,助力企业低成本培养具备规范意识与实战经验的高质量工程人才。

首先,大多数组织和个人参与开源的初衷,往往是出于实际需求:他们希望改进正在使用的开源项目,使其更加稳定、易用、契合自身场景;或者干脆将内部自研的工具开源,构建自己的“轮子”。虽然这些功能可以选择内部使用、不对外共享,但将其贡献回社区才是真正实现长期价值最大化的方式。一方面,这有助于提升整体项目的质量与活跃度;另一方面,若不将代码上游合并,未来项目升级时可能因版本不兼容而导致功能失效,反而增加维护成本。更重要的是,积极参与开源贡献还能显著提升公司的技术影响力,让企业在项目的发展方向、版本规划、功能设计等方面拥有更多话语权,真正从“使用者”转变为“参与者”与“推动者”。其次,开源社区本身就是技术需求的“集散地”。通过与上下游用户、开发者互动,公司能更早接触到用户的真实的痛点与趋势,从而反哺内部产品设计与研发决策。最后,开源代码的审查严格,有助于提升员工的技术功底,变相节省了企业的培训成本。

个人视角

从开发者个人来看,参与开源贡献有如下几个好处:

  • 学习到系统的工程能力:开源锻炼工程能力与架构思维,提升规范意识与全局视野;
  • 提升表达和协作能力:开源是跨地域协作中的沟通语言,提升技术表达力与接受多元反馈的能力;
  • 提升内在成就感:开源带来被看见的成就感,激发内驱力,增强责任感与持续贡献的动力。

参与开源,有助于开发者系统性地掌握软件工程能力。开源项目更加注重架构设计的合理性、代码的可维护性,以及系统在长期演进中的可持续性。通过实践,开发者能够逐步理解架构背后的权衡逻辑,学会如何划分模块边界、如何实现 SOLID 的设计。与此同时,开源提供了完整的工程流程体验,从代码提交、自动化测试、CI 校验,到文档同步、版本发布,每一个环节都高度标准化。这不仅显著提升了开发者的编码能力和技术广度,也帮助开发者熟悉 GitHub Flow、Issue/PR 驱动协作模式,以及主流社区所推崇的开发规范与工具链,为其打下了坚实的工程基础。

此外,开源不仅仅是代码的集合,更是一种协作的语言。在与社区的互动中,开发者不仅要完成代码实现,还常常需要参与到设计讨论、文档编写等工作中。这就要求他能够清晰地表达自己的意图、设计思路以及问题的定位过程。开源也是一种高频率、去中心化的协作方式。开发者需要习惯与陌生人协同开发,接受代码被审查、被质疑,甚至听到“这个设计不合理”的反馈。在不断的沟通与磨合中,开源会帮助开发者逐渐学会倾听与尊重,理解不同文化背景、技术视角下的表达。

最后,参与开源可以带来持续的成就感与责任感。当开发者自己的代码被社区合并、功能出现在 release note 中,可以清晰地感受到自己的工作被真正使用和认可,这提升了开发者内在的成就感,同时也可以给他们带来好心情。

开源社区

ASF 社区

Apache Software Foundation(ASF) 成立于 1999 年,是一个非营利组织,旨在为开源软件项目提供法律、基础设施和治理支持。是目前最大的软件基金会,ASF 的开源软件在世界各地被广泛使用,ASF 目前管理者超过 8,400 名 Committer 以及 320 个活跃的项目。ASF 的一个重要的理念是“社区优于代码”,即一个强大的社区总能修复代码中的问题,而一个不健康的社区则很难以可持续的方式维护代码。

社区结构

对于开源项目而言,抽象来看,社区一般有两种重要角色,

  • 用户(使用该项目的人)
  • 贡献者(对项目有贡献的人)。

这样一个社区模型,是一个分层模型。在普通用户中会有一些人将项目在生产中使用,这样的用户就是产品用户(Production User);有些用户在使用过程中会遇到 Bug 或者发掘可以提升的点,并以 Issue 的形式暴露出来,这部分用户称之为 Issue-raised User,通常这类用户从 Production User 中产生。如果用户可以动手解决问题,并将 Bug Fix 和 improvement 提交到社区,这样的用户就是代码贡献者(Code Contributor)。如果一个贡献者提交了很多的代码,并且为项目做出了重大贡献,那么这样的贡献者称之为核心贡献者(Committer/Maintainer)。

通常来说一个健康的社区都是由这样的层次构建而来,并且每一层都有一定的比例,且在不停地由上而下的转换。开源中提到的社区实际上指的是由用户和代码贡献者共同构建的生态。

代码贡献者也具有层级结构,一般情况下可以将其分为如下几个层级:

  1. Contributors
  2. Committer
  3. PMC

就责任而言,Contributors 主要负责具体的代码实现;Committer 更注重代码设计与评审,具体来说包括:

  1. 代码与设计评审
  2. 分支管理
  3. 合并与回滚补丁
  4. 协助 PMC 发布版本

相比而言,PMC 主要负责项目的决策、发展方向以及社区的生态建设,具体来说包括:

  1. 提名并选举新的 PMC 成员和 Committer
  2. 决定路线图与版本发布
  3. 负责商标、知识产权管理
  4. 审查项目进度并提供反馈

如何参与社区工作

参与社区工作的步骤可以抽象成

贡献流程

  1. 找到解决的 Issue;
  2. 创建开发分支
  3. 完成代码开发和测试;
  4. 提交合并 PR;
  5. 邀请 maintainer Code Review;
  6. 修改/合并/拒绝

这里需要注意的是部分项目直接使用 github 的 issue 进行问题追踪;有些项目则使用 jira 作问题追踪。

如果模块 Maintainer 认为这个 PR 存在较大问题,他可以直接 close 对应的 PR 和 Issue。

未完待续…


文章作者: pancx
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 pancx !
评论
  目录