Hello! My name is Dmitry Pavlov, and I work at , and I am also a committer and member of the PMC at Apache Ignite and a contributor at Apache Training. Recently, I gave a talk about the role of a committer at a meetup organized by Sberbank focused on open source. As the open source community evolves, many are increasingly asking: how does one become a committer, what tasks should be taken on, and how many lines of code need to be written to achieve this role? When we think of committers, we often envision all-powerful, omniscient individuals wearing crowns and holding a copy of 'Clean Code' instead of a scepter. Is that the case? In this post, I will attempt to answer all the important questions about committers so that you can understand whether this role is truly for you.
Newcomers in the open source community often wonder if they will ever become committers. After all, for many, this is a prestigious role that can only be attained through special achievements and by writing a ton of code. But things are not so simple. Let's look at committers from the community's perspective.
Who is a committer and why is he needed?
When creating a new open-source product, we always allow users to use and explore it, as well as to modify and distribute modified copies. However, when uncontrolled distribution of software copies with modifications occurs, we do not receive contributions back into the main codebase and the project does not evolve. This is where the committer becomes essential, as they have the right to collect user contributions to the project.
Why become a committer?
First of all, being a committer is a plus for your resume, and for newcomers in programming, it is even more beneficial, as frequently, job applications require code samples.
The second undeniable advantage of being a committer is the opportunity to communicate with top specialists and bring exciting ideas from open source into your project. Moreover, if you are well-versed in a certain open-source product, you may secure a position at a company that supports or utilizes it. There is even a belief that if you do not participate in open source, you will not reach high career positions.
In addition to the career and employment perks, contributing is rewarding in itself. You get recognized by the professional community, and you can clearly see the results of your work. It's not like in some corporate development projects where you sometimes don't even understand why you're shifting fields in XML back and forth.
In open-source communities, you can meet top specialists like Linus Torvalds. But if you're not at that level, don't think there's nothing for you to doāthere are tasks of various levels.
There are also additional bonuses: Apache committers, for example, receive a free license for IntelliJ Idea Ultimate (albeit with some limitations).
What should you do to become a committer?
It's simpleāyou need to commit.
If you think there are no tasks for you on the projects, you're mistaken. Just join the community you're interested in and do what is necessary for it. The Apache Software Foundation has a separate with the requirements for committers.
What tasks will you need to solve?
A wide varietyāfrom development to writing tests and documentation. Yes, the contributions of testers and documenters are valued equally with those of developers. There can be unconventional tasksāfor example, manage a YouTube channel and tell other users how you use an open-source product. For instance, the Apache Software Foundation has a dedicated , listing what help is needed. Ā
Do you have to write a large feature to become a committer?
No. It's not necessary at all. A committer doesn't have to write tons of code. But if you've written a significant feature, it will be easier for the project management committee to evaluate you. Contributing to the community is not just about features, programming, and testing. If you write a letter and describe an issue, proposing a reasoned solutionāthatās also a contribution.
It's important to understand that commitment is about trust. Whether to make you a committer is decided by people just like you based on their perceptions of you as someone who adds value to the product. Therefore, you need to earn that trust through your actions and behavior in the community.
How should you behave?
Be constructive, positive, polite, and patient. Remember that in open source, everyone is a volunteer, and no one owes anyone anything. If you donāt get a response, wait and remind them about your question in 3-4 days. If you keep getting no replies, well, open source is voluntary work.
Donāt ask someone to do something for you or on your behalf. Experienced community members can sense such "requesters" and often develop an aversion to those who want to offload their work onto others.
If someone helps you, thatās great, but donāt take advantage of them. Itās not appropriate to say, "Guys, fix this or Iāll lose my annual bonus." Instead, ask where to go from here and share what youāve already discovered about the bug. If you promise to update the wiki once the issue is resolved, the chances of getting a response will increase significantly.
Finally, read and learn .
How to contribute if you are not a committer?
In projects, the RTC scheme is often used, where everyone goes through a review before changes are merged into the master. With this scheme, absolutely everyone is reviewed, even committers. Thus, it is possible to contribute successfully to a project without being a committer. To be more easily selected as a new committer, you can mentor new members, share knowledge, and create new materials.
Is diversity beneficial or harmful?
Diversity, in the understanding of the Apache Software Foundation, includes the affiliation of participants in an open-source project with multiple companies. If everyone is affiliated with only one organization, once that organization's interest in the project wanes, all participants will quickly leave. Diversity ensures the longevity and stability of the project, diverse experiences, and a broad range of opinions among participants.
For love or for calculation?
In open-source projects, there are two types of people: those who work in an organization contributing to the product, and those who are here out of love, meaning volunteers. Who is more productive? Generally, participants who support the product from the side of the contributing organization are more productive. They simply have more time and a clear motivation to dig into the truth; they are focused on the task and closer to the user.
Those who do this 'out of love' are also motivated, but differently ā they are eager to explore the project and make the world a better place. It is precisely these participants who are more stable and focused on the long term, because those who join the community of their own accord are unlikely to leave it overnight.
How to find a balance between productivity and stability? There are two options. The first option is when a participant works at a company officially involved in the open source project and does additional work out of personal interest ā for example, mentoring newcomers. The second option is a company that has undergone an open source transformation. For example, when employees spend four days a week focusing on the core business project and the rest of the time on open source.
To be a committer or not to be?
Commits are a good and beneficial topic, but one shouldn't strive solely to become a committer. This role can be obtained without writing code, and it does not prove your knowledge. What matters is the expertise, meaning the knowledge and experience you gain by studying the project, digging into it, and helping others solve problems.
Source: habr.com
