Every time I post a new project proposal, I receive a handful of emails from people in the community asking to be added to the committer list on the proposal. But it doesn’t work that way: it’s really not up to me.
For new projects, we have to cheat a little. A new project can designate a handful of individuals as the initial project committers. In general, it’s difficult to establish merit for initial project committers, so we put faith in the designated leaders of that project proposal to make their selection of initial committers carefully. The advice that I tend to give is that project proposals should only list initial committers that are familiar with the initial code base and are known to the leadership. We expect that initial committers will need help with the Eclipse Development Process, which is one of the main reasons why new projects are required to attract the attention of a pair of mentors from the Architecture Council.
But once a project is up and running, adding new committers is a little more involved. To become a committer on an established project, one needs to demonstrate merit. A developer must demonstrate that they understand the code base, and the development process. Further, they have to show some understanding that participation in an open source project is more than just software development: community development is an equal responsibility of all open source developers.
Transparency and openness are two important elements of community development. Developers who are new to open source have to get used to having their conversations in public forums. Mailing lists, forums, and Bugzilla are preferred mechanisms at Eclipse, but there are also IRC channels, Twitter, blogging, podcasts, webinars, and more. Being transparent can be exhausting. But being transparent is how a project develops a community; it’s how they attract people to participate in the project.
Transparency is about inviting participation, openness is about accepting it. It’s all fine and good to be open and tell people about all the great things that are happening in your project, but it’s equally important that a project accepts input from the community. Successful projects accept input and adapt to it. Successful projects understand that accepting contributions is their life’s blood.
By being open to the ideas of others, and accepting their patches, features, and other contributions, a project grows in diversity and relevance. This is where new committers come from. Developers who provide quality contributions to a project may be invited to join that project as a committer. The quality and quantity metrics vary from project-to-project, but the spirit is the same: contribution demonstrates merit, and merit is what one needs to become a committer.
Since one of the main responsibilities of a committer is to work with contributors and their contributions; it only makes sense that the first step in earning that responsibility is to experience it from the other side.
