Hi! I’m Dmitriy Pavlov and I work at GridGain. I’m also an Apache® Ignite™ committer, a member of the Apache Ignite PMC (Project Management Committee -- and a committer and member of the PPMC at Apache Training (incubating). PPMC stands for “Podling Project Management Committee.”
Recently, I delivered a talk about promoting Ignite as a committer. An Ignite “committer” is a designation signifying that an individual has made a sufficient contribution to the Ignite project.
As the open-source community evolves, there is increasing interest in the process of becoming a committer. Some of the questions I’ve seen:
“Which tasks should one take on to achieve this title?”
“How many lines of code should one write before they can become a committer?”
Trying to imagine a committer, those from the outside perhaps see an all-mighty and all-knowing crowned person holding a volume of «Clean Code» instead of a scepter. But is that really true? In this post I’ll try to address the most important questions about committers. If you’re considering going for this goal, I hope this helps.
All newbies in the open-source community may sometimes think that they’ll never be able to become committers. Many treat this role as a prestigious one, granted only for special feats, and after having written a ton of code. But not all things are so simple. Let’s examine, therefore, how the community treats a committer.
Who is a typical committer and where does his or her strength lie?
When creating an open-source product, we always let the users explore it in action -- as well as allow them modify it and distribute modified copies. But when such modified copies are replicated in an unsupervised manner, we don’t get contributions into the main codebase and the project stalls. It’s here where we need exactly such a person – the committer – someone who is authorized to merge user contributions into the project.
Why should you become a committer?
First of all, committer activity is a jewel in your CV -- and even a greater plus for junior programmers, because at interviews you are often asked to show code samples.
The second pure advantage of being a committer is an opportunity to connect with top professionals and also pull some cool ideas from open source into your own project. Besides, if you know an open source project well, a company supporting or using it will be happy to hire you. There are some people who will tell you that great positions are unreachable without first committing in open source.
Committer activity not only gives you career and employment perks. The professional community acknowledges you and your work, and you clearly see the results of your work in action.
How different is that from some enterprise project -- where you have no idea why you are must continually keep shuffling various XML fields?
In open source communities, you may contact top specialists such as Linus Torvalds. But, if you aren’t one of them, certainly don’t be afraid to join -- the community has various tasks for different folks.
There are some bonus goodies, too! For example, Apache committers get an IntelliJ Idea Ultimate license for free (albeit with some limitations).
How do you become a committer?
You should commit – it’s just that simple.
If you think there are no tasks for you on some project, you are wrong. Just join the community you are interested in and start working on its tasks. The Apache Software Foundation has a dedicated guide with requirements for committers.
What are the tasks we are going to solve?
A whole zoo of them… development, writing tests and documentation. Yeah, the contributions of QA engineers and technical writers in the community are valued no less than the developers’ contributions. There are also special tasks – for example, to lead a YouTube-channel aimed at developers about how you are using your open source product. In the Apache Software Foundation this dedicated page details what contributions of this kind are needed.
Do I need to deliver a big feature to become a committer?
No. It is absolutely not required. A committer isn’t obliged to write tons of code. But if you have developed a big feature, the project management committee could take a much bigger interest in you. Contributions to the project are not only about features, programming and testing. If you email of some problem and propose a sound solution for it, that’s considered a “commit,” too.
It’s important to understand that committer activity builds upon trust. People like you decide whether you can become a committer, based on their judgments of how useful you could be for the entire product. So, it’s up to you to obtain such trust with your work and deeds.
How to behave?
Be constructive, friendly, polite and patient. Bear in mind that in open source everyone is a volunteer and no one owes anything to others. If you get no feedback – wait and repeat your question in 3-4 days. If you never get an answer – well, open source is a voluntary endeavor, after all.
Don’t ask to do anything for yourself or selfish reaons. Seasoned community members sense such «tricksters» and quickly ignore those who want to shift their own work onto others.
If you get help – great! But don’t overuse it. You’d better never write «Guys, fix this please, I am struggling for an annual bonus!» Instead ask something like how you could progress on what you’ve already discovered about this or that bug. If you promise to update the wiki, based on the solution, the odds to get feedback become much higher.
Finally, read Code of Conduct and learn how to ask questions the smart way.
How to commit, if you aren’t a committer?
Many projects employ an RTC workflow, where all commits are reviewed before all the changes are merged into the master branch. Such a pattern assumes that everyone is passing a review, even the committers. So, one can successfully contribute to the project without being a committer. To have a better chance of getting elected as a new committer, you could first become a tutor for newbies, share knowledge and compose new content.
Diversity — a benefit or a harm?
Diversity, as treated in the Apache Software Foundation, means the affiliation of project members to several companies. If everyone is affiliated to the same organization, the whole team quickly leaves the project as soon as the company abandons the project. Diversity ensures the project’s longevity, robustness, versatile experience and a wide range of opinions among members.
Geek or gold digger?
Two kinds of folks contribute to open source projects: 1) employees of a company that contributes to this product, or 2) geeks (volunteers).
Which is more productive? As a rule, the first ones. They just have more time and are more motivated to dig out the truth. They are committed to the task and are closer to the user.
Geeks are also motivated -- but differently. They crave to flesh out the project, to make our world better. Exactly such members are more dedicated in the long run, because the ones who joined the community voluntarily rarely leaves it without serious consideration.
It is possible to combine these two ways of contributing to balance productivity and stability? There are two possible ways. First: the committer works at the company that regularly maintains this open source project -- and such a member makes an additional commitments to the project (just for kicks). For example, he or she can teach newcomers. Second: it may be a company that passed an open-source transformation. The staff may work on the main commercial project four days a week, and the rest of the time is devoted to the open source part.
Committer — to be or not to be?
Committer activity is a good and useful endeavor, but one shouldn’t strive to become a committer per se. This status can be granted not only for code and it doesn’t justify your proficiency. The key is the expertise (i.e. knowledge and experience) you gain when researching the project, tweaking it and helping the others to solve their problems.