Skip to main content

From Committer to PPMC: A New Beginning at Apache Fesod (Incubating)

Hello everyone! I am deeply honored to share that I have officially been invited to become a PPMC member of Apache Fesod (Incubating).

From starting out as an everyday user of Fesod, to contributing bug fixes and documentation as a Committer, and now stepping into the role of a PPMC member, this progression is not only an acknowledgment from the community, but also signifies a major shift in my focus. I'd like to take this opportunity to reflect on my practical experiences and takeaways during this transition from Committer to PPMC.

From Writing Code to Fostering the Community​

When I first became a Committer, my primary focus was on "what I could build for the project": how many issues I resolved and how many core PRs I submitted. However, as my involvement deepened, I came to realize that keeping an open-source project vibrant and healthy requires far more than just code output. Consequently, I began shifting more of my attention to what happens beyond the codebase:

  • Code Reviews: Instead of just writing code myself, I spent significantly more time reviewing PRs from other contributors. This involved not only verifying logic correctness and test coverage, but also ensuring that newly introduced changes align with the long-term architecture of the project.
  • Issue Triage and Task Breakdown: For bug reports and feature requests raised by users, I helped reproduce issues, label priorities, and break down complex problems.
  • Guidance and Support: Assisting users in GitHub Discussions and Issues with troubleshooting complex Excel parsing and exporting issues, and offering patient, actionable feedback during reviews to help new contributors get their PRs across the finish line.

Key Takeaways​

Throughout this journey, I gained a much more practical understanding of how an Apache project actually operates:

  1. Reviewing code often takes more energy than writing it.

    When writing code, you are only accountable to your own thought process. But reviewing someone else's work requires stepping into their shoes, spotting potential pitfalls, and being mindful of how you communicate to avoid unnecessary misunderstandings and friction. Providing constructive feedback and helping guide a PR to merge is often far more challenging than implementing it yourself.

  2. Rules are not constraints, but the bedrock of long-term sustainability.

    At first, asynchronous communication on mailing lists (The Apache Way), coding guidelines, and compliance workflows can feel cumbersome. But as the project grows and attracts contributors from diverse backgrounds, these rigorous standards are precisely what ensure stability and supply chain security.

  3. Community vitality relies on positive feedback loops.

    Open source is never a solo effort. If a contributor submits a PR and hears nothing for an extended period, their enthusiasm quickly fades. A crucial responsibility of a PPMC member is to minimize the feedback cycle between the community and external contributors, ensuring that everyone who opens a PR or reports a bug feels heard and valued.

Acknowledgments​

A heartfelt thank you to @delei and @psxjoy for their mentorship, and to every member of the Apache Fesod (Incubating) community. Thank you for your thorough reviews, patient guidance on every PR, and the trust you've placed in me.

We often assume that open source is distant and inaccessible, but in reality, it begins with an error you encounter in daily development, a snippet of logic you'd like to optimize, or a piece of documentation that could be clearer.

Taking that first step isn't as daunting as it seems. Whether it's submitting a reproducible test case, fixing a typo, or taking the initiative to open your first PR—every step counts toward becoming a contributor.