April 3, 2019 at 09:00How to become a committer and do you really need it
Hello! My name is Dmitry Pavlov, I work at GridGain , and I am also a committer and member of PMC at Apache Ignite and contributor to Apache Training. Recently, I made a report on the work of the committer at the meeting of Sberbank on open source. With the development of the opensource community, many began to raise questions: 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 about committers, we are immediately presented with omnipotent and all-knowing 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 a flurry of 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 it’s not so simple. Take a look at the committer from the community.
When creating a new opensource product, we always allow users to use and research 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 counterbuffs in the main code base and the project does not develop. Here the same committer is already needed, which has the right to collect user contributions to the project.
To begin with, committing is a plus to the resume, and for beginners in the field of programming it is an even bigger plus, because often when applying for a job they ask for code examples.
The second undoubted advantage of committing is the ability to communicate with top experts and pull some cool ideas from open source into your project. In addition, if you are well aware of a certain open source product, then you can get a company that supports or uses it. There is even an opinion that if you do not participate in open source, then you can’t get into high career positions.
In addition to the benefits in terms of career and employment, committing in itself is nice. The professional community recognizes you, you clearly see the result of your work. Not like in some kind of corporate development, where sometimes you don’t even understand why you are transferring fields to and fro in XML.
In opensource communities, you can meet top experts at the Linus Torvalds level. 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 additional bonuses: Apache committers, for example, get a free IntelliJ Idea Ultimate license (albeit with some limitations).
Everything is simple - you need to commit.
If you think that there are no tasks for you on projects, you are mistaken. Just join the community that interests you and do what it needs to do. The Apache Software Foundation has a separate guide for committer requirements.
The most diverse - from development to writing tests and documentation. Yes, the contribution of testers and documenters in the community is valued along with the contribution of developers. There are non-standard tasks, for example, leading a YouTube channel and telling other users how you use the opensource product. For example, the Apache Software Foundation has a separate page that indicates what help is required.
Not. This is not at all necessary. The committer should not write tons of code. But if you wrote 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 some problem, offer a reasoned solution - this is also a contribution.
It is important to understand that committing is trust. People who decide to make you a committer or not are decided by people like you based on their views on you as a person who benefits the product. Therefore, you, through your actions and actions in the community, need to gain this very trust.
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 do not constantly answer you - well, open source is voluntary.
Do not ask to do something for you or for you. Experienced community members have a flair for such "beggars" and immediately there is an allergy to those who want to shove their work to them.
If you are helped, it’s great, but don’t abuse it. Do not write: “Guys, fix this, otherwise I’m losing the annual prize.” It’s better to ask where you’re going to move on, and tell us what you 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 they will answer you will increase significantly.
Finally readCode of Conduct and learn to ask questions .
Projects often use the RTC scheme, when everyone goes through the review first, and then the changes are merged into the master. With this scheme, absolutely everything goes through a review, even committers. Therefore, you can successfully contribute to the project without being a committer. And in order to make it easier to be selected as a new committer, you can mentor new members, share knowledge, create new materials.
Diversity - in the understanding of the Apache Software Foundation, is, among other things, the affiliation of participants in an open source project with several companies. If everyone is affiliated with only one organization, then with the loss of its interest in the project, all participants are famously running away from there. Diversity provides long-term, project stability, versatile experience and a wide range of participants' opinions.
In open source projects, there are two types of people: those who work in an organization that contribute to this product, and those who work here for love, that is, volunteers. Which of them is more productive? As a rule, participants who support the product from the organization-contributor. They simply have more time and there is a clear motivation to get to the truth, they are focused on the task and closer to the user.
Those who do this “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 it is precisely such participants that 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 for a company that is officially engaged in this opensource project, and does something extra 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 saw the main business project four days a week, and the rest of the time they do open source.
Committing is a good and useful topic, but you should not strive to become a committer. This role can be obtained not for the code, and it does not prove your knowledge. Only expertise is important, that is, the knowledge and experience that you will gain by studying the project, delving into it and helping others solve problems.
All newcomers to the open source community have a flurry of 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 it’s not so simple. Take a look at the committer from the community.
Who is a committer and why is it needed?
When creating a new opensource product, we always allow users to use and research 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 counterbuffs in the main code base and the project does not develop. Here the same committer is already needed, which has the right to collect user contributions to the project.
Why become a committer?
To begin with, committing is a plus to the resume, and for beginners in the field of programming it is an even bigger plus, because often when applying for a job they ask for code examples.
The second undoubted advantage of committing is the ability to communicate with top experts and pull some cool ideas from open source into your project. In addition, if you are well aware of a certain open source product, then you can get a company that supports or uses it. There is even an opinion that if you do not participate in open source, then you can’t get into high career positions.
In addition to the benefits in terms of career and employment, committing in itself is nice. The professional community recognizes you, you clearly see the result of your work. Not like in some kind of corporate development, where sometimes you don’t even understand why you are transferring fields to and fro in XML.
In opensource communities, you can meet top experts at the Linus Torvalds level. 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 additional bonuses: Apache committers, for example, get a free IntelliJ Idea Ultimate license (albeit with some limitations).
What to do to become a committer?
Everything is simple - you need to commit.
If you think that there are no tasks for you on projects, you are mistaken. Just join the community that interests you and do what it needs to do. The Apache Software Foundation has a separate guide for committer requirements.
What tasks will you have to solve?
The most diverse - from development to writing tests and documentation. Yes, the contribution of testers and documenters in the community is valued along with the contribution of developers. There are non-standard tasks, for example, leading a YouTube channel and telling other users how you use the opensource product. For example, the Apache Software Foundation has a separate page that indicates what help is required.
Do I need to write a big feature to become a committer?
Not. This is not at all necessary. The committer should not write tons of code. But if you wrote 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 some problem, offer a reasoned solution - this is also a contribution.
It is important to understand that committing is trust. People who decide to make you a committer or not are decided by people like you based on their views on you as a person who benefits the product. Therefore, you, through your actions and actions in the community, need to gain 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 do not constantly answer you - well, open source is voluntary.
Do not ask to do something for you or for you. Experienced community members have a flair for such "beggars" and immediately there is an allergy to those who want to shove their work to them.
If you are helped, it’s great, but don’t abuse it. Do not write: “Guys, fix this, otherwise I’m losing the annual prize.” It’s better to ask where you’re going to move on, and tell us what you 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 they will answer you will increase significantly.
Finally readCode of Conduct and learn to ask questions .
How to contribute if you are not a committer?
Projects often use the RTC scheme, when everyone goes through the review first, and then the changes are merged into the master. With this scheme, absolutely everything goes through a review, even committers. Therefore, you can successfully contribute to the project without being a committer. And in order to make it easier to be selected as a new committer, you can mentor new members, share knowledge, create new materials.
Diversity - benefit or harm?
Diversity - in the understanding of the Apache Software Foundation, is, among other things, the affiliation of participants in an open source project with several companies. If everyone is affiliated with only one organization, then with the loss of its interest in the project, all participants are famously running away from there. Diversity provides long-term, project stability, versatile experience and a wide range of participants' opinions.
For love or for convenience?
In open source projects, there are two types of people: those who work in an organization that contribute to this product, and those who work here for love, that is, volunteers. Which of them is more productive? As a rule, participants who support the product from the organization-contributor. They simply have more time and there is a clear motivation to get to the truth, they are focused on the task and closer to the user.
Those who do this “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 it is precisely such participants that 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 for a company that is officially engaged in this opensource project, and does something extra 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 saw the main business project four days a week, and the rest of the time they do open source.
The committer - to be or not to be?
Committing is a good and useful topic, but you should not strive to become a committer. This role can be obtained not for the code, and it does not prove your knowledge. Only expertise is important, that is, the knowledge and experience that you will gain by studying the project, delving into it and helping others solve problems.