On April 6th, 2020 I was invited to become a committer on the Apache Solr project. My journey to becoming a committer started in earnest 4662 days before that! On July 2nd, 2007, I opened SOLR-284, a ticket for adding content extraction to Solr.
A committer on an open source project under the Apache Foundation umbrella is someone who is trusted to contribute code to the project and to help manage and drive its ongoing development. It’s an honour to have been asked and I was very proud to accept the invitation!
So, you did the math, and you realized that it took me 153 months, or 13 years (rounding up), to become a committer, and you’re wondering “What if I don’t want to wait that long?” So here’s my quick cheat sheet on ways to become a committer on an open source project, illustrated by my own journey:
- Start by learning the culture of the project. How are decisions made? What tools do people use? What do the various acronyms mean? Join the mailing lists and read every commit.
- Start small and work your way in. Some great ways to do this are to:
- Take existing patches and test them. Update them to the latest code base. Document what you’ve learned.
- Take advantage of being new to a project to bring fresh eyes to the documentation. Every time you find yourself scratching your head on how something works, contribute a fix to the docs. It’s a powerful way to immediately contribute. This is the fastest way to get involved and involves the least cognitive load! See SOLR-2232 or this email thread.
- Answer questions on the mailing list! Being able to articulate reasonable responses to questions demonstrates how much you have learned.
- Bug fix, bug fix, bug fix! Pick bugs that have an obvious answer so that the “correct” solution is easy to figure out. If the right approach to solving it is very ambiguous, you probably won’t get much traction. Remember to remind committers to apply your fixes when they have the time! See SOLR-13965 and SOLR-11480 and SOLR-2611 and SOLR-2263.
- Ready to start slinging some code? Don’t go and refactor the core foundations of the project (at least not yet). Instead, be like a pilot fish and latch onto one of the core committers who is being very active in the project:
Embrace their vision, and start picking up tasks related to whatever major chunk of work they are doing. Write some unit tests. See about opportunities for refactoring. Do some manual testing over multiple platforms. Once they see that you’re contributing (and accelerating what they are pushing), then work to get some of your own tickets assigned to you under that vision. I’ve seen this lead directly to committership many times, and if I had followed this route, I might have joined sooner!
Here’s to the next 4662 days of being active in the Apache Solr project!