Hello! My name is Dmitry Pavlov, I work in , and I am a PMC committer and contributor to Apache Ignite and a contributor to Apache Training. Recently, I gave a presentation on the work of the committer at the Sberbank meetup on open source. With the development of the open source community, many more and more questions began to arise: how to become a committer, what tasks to take, and how many lines of code you need to write to get this role. When we think of committers, we immediately imagine omnipotent and omniscient people with a crown on their heads and a volume of Clean Code instead of a scepter. Is it so? In my post, I will try to answer all the important questions about committers so that you can understand if you really need it.
All newcomers to the open source community have thoughts that they will never become committers. Indeed, for many, this is a prestigious role that can only be obtained for special merits by writing a ton of code. But everything is not so simple. Let's take a look at the committer from the community side.
What is a committer and why is it needed?
When creating a new open source product, we always allow users to use and explore it, as well as modify and distribute modified copies. But when there is an uncontrolled distribution of copies of the software with the changes made, then we do not receive contributions to the main codebase and the project does not develop. This is where the very committer is needed, which has the right to collect user contributions to the project.
Why become a committer?
Let's start with the fact that committership is a plus for a resume, and for beginners in the field of programming, an even bigger plus, because code examples are often asked for when applying for a job.
The second undoubted advantage of committering is the ability to communicate with top specialists and pull some cool ideas from open source into your project. In addition, if you know a certain open source product well, you can get a job in a company that supports or uses it. There is even an opinion that if you do not participate in open source, then you will not get into high career positions.
Aside from the career and employment perks, committership is a pleasure in and of itself. You are recognized by the professional community, you clearly see the result of your work. Not like in some corporate development, where sometimes you donβt understand at all why you are shifting fields back and forth in XML.
In open source communities, you can meet top experts like Linus Torvalds. But if you are not like that, you should not think that you have nothing to do there - there are tasks of different levels.
Well, there are also additional bonuses: Apache committers, for example, receive an IntelliJ Idea Ultimate license for free (albeit with some restrictions).
What to do to become a committer?
It's simple - you need to commit.
If you think that there are no tasks for you on projects, you are mistaken. Just join the community you are interested in and do what is necessary for him. The Apache Software Foundation has a separate with requirements for committers.
What tasks will have to be solved?
The most different - from development to writing tests and documentation. Yes, yes, the contribution of testers and documenters in the community is valued on a par with the contribution of developers. There are non-standard tasks - for example, to maintain a YouTube channel and tell other users how you use an open source product. For example, the Apache Software Foundation has a separate , which indicates what kind of assistance is required.
Do I need to write a big feature to become a committer?
No. This is not at all necessary. A committer doesn't have to write tons of code. But if you write a big feature, it will be easier for the project management committee to evaluate you. Contributing to the community is not only about features, programming and testing. If you write a letter and talk about a problem, offer a reasoned solution, this is also a contribution.
It is important to understand that committership is trust. To make you a committer or not is decided by people like you based on their views on you as a person who benefits the product. Therefore, you, by your actions and deeds in the community, need to win this very trust.
How to behave?
Be constructive, positive, polite and patient. Remember that in open source all volunteers and no one owes anything to anyone. They do not answer you - wait and remind about your question in 3-4 days. They constantly do not answer you - well, open source is a voluntary matter.
Do not ask to do something for you or for you. Experienced members of the community have a flair for such "beggars" and immediately become allergic to those who want to push their work to them.
If you get help, that's great, but don't overdo it. You should not write: "Guys, fix this, otherwise I'm losing the annual bonus." It is better to ask where you should go next, and tell us what you have already dug up on this bug. And if you promise to update the wiki based on the results of solving the problem, then the likelihood that you will be answered will increase significantly.
Finally, read and learn .
How to contribute if you are not a committer?
Projects often use the RTC scheme, when first everyone goes through a review, and then the changes are merged into the master. With this scheme, absolutely everyone is reviewed, even committers. Therefore, you can successfully contribute to the project without being a committer. And in order to be more easily selected for new committers, you can mentor new members, share knowledge, and create new materials.
Diversity - benefit or harm?
Diversity - in the understanding of the Apache Software Foundation, this is, among other things, the affiliation of open source project participants by several companies. If everyone is affiliated with only one organization, then with the loss of its interest in the project, all participants famously run away from there. Diversity provides long-term, project stability, diverse experience and a wide range of participants' opinions.
For love or for convenience?
There are two types of people in open source projects: those who work in an organization that contributes to this product, and those who work here for love, that is, volunteers. Which one is more productive? As a rule, participants who support the product from the side of the contributor organization. They simply have more time and a clear motivation to get to the bottom of the truth, they are task-focused and closer to the user.
Those who do it βout of loveβ are also motivated, but in a different way - they are eager to study the project, to make the world a better place. And just such participants are more stable and focused on the long term, because those who came to the community on their own initiative are unlikely to leave it one day.
How to find a balance between productivity and stability? There are two options. The first option: when a participant works in a company that officially deals with this open source project, and does something additional in it, out of his own interest - for example, he supports newcomers. The second option is a company that has experienced an open source transformation. For example, when employees work on the main business project four days a week, and the rest of the time they are engaged in open source.
Committer - to be or not to be?
Committing is a good and useful topic, but you should not strive to become a committer specifically. This role can be obtained not for the code, and it does not prove your knowledge. What matters is expertise, that is, the knowledge and experience that you gain by studying the project, delving into it and helping others solve problems.
Source: habr.com