At the Apache Software Foundation, there are two levels of recognizing participants in a project – Committers, and PMC members. The PMC nominates and elects new Committers and PMC members.

But what do Committers do?

The name itself is a bit of a misnomer, because it comes from a specific technical detail from the past. That is, an individual can be given commit rights, which means that they could commit code to the SVN repository (or CVS before that).

But there’s two problems with this name, and this definition.

The most obvious one is that, today, in the age of Git (and really even before then) nobody commits their own code. Rather, they review and commit someone else’s code.

Granted this varies greatly from project to project, as well as from one patch to another. For example, I routinely commit my own changes to documentation or website content, But for code changes, most projects mandate (note, this is a *social* mandate, not a technical one) that a patch (pull request) receive some kind of review from other contributors, who will then agree on an action.

The second problem with the name and the definition is, in my opinion, the more damaging one, although it may be less obvious to casual participants. And that’s that it implicitly values *code* above all other contributions, and, as a result, makes it hard, or in some cases impossible, for non-code contributors to gain the respect and recognition that they have earned. It’s already hard enough for them to earn that respect, because these so-called “non-technical” skills are harder to measure, and are already undervalued by the people who think (wrongly) that writing code is the only important part of a software project.

I cannot tell you how many times I have been told, by PMC members of a given project, that they cannot nominate someone as committer who has written docs, who has produced events, who has donated legal talent, or various other non-code contributions, because that would open up the risk that they would then start modifying the code in the Git repository, and this would result in bugs and data loss and who knows what all disaster.

This is such nonsense. And the people giving these reasons owe it to themselves, and to their project, to actually think honestly about why they are gatekeepking project leadership from people making important non-code contributions.

But not only is it an invalid reason, it’s actively damaging to the project, for a number of reasons.

1. Projects that refuse to respect non-code contributors are making themselves more susceptible to corporate control. This is because when the project won’t respect these contributions, companies have to step up to provide those services – marketing, events, legal work, design – and this gives them outsided control of the messaging of the project, which, in turn, makes it clear that they are, in reality, the power behind the project.
2. If you don’t recognize and respect non-code contributors, they eventually feel that disrespect, and go away. This means that the coders, who are good at code but bad at other things, have to do those tasks anyway. This results in the tasks being done poorly, and stealing time from what they’re good at. Everybody loses.
3. Software that is designed, implemented, and tested by engineers is never as good as software that has non-expert users as part of this planning process. I could, surely, elaborate, but I think you all know what I’m talking about.

And yet, I still have this argument with software projects, all the time. And they still make the same excuses. Makes me tired.

Then there are the projects that try take this issue seriously, but want to create a separate tier of membership for those non-code contributors. They believe that this is a way to give the recognition and respect that is earned, without … y’know … actually giving these people any *real* power in the project. This is, quite literally, creating second-class citizenship, and, in most cases, robs these people of the opportunity to advance to the next level of project management.

Short of renaming “committer” to something else (or maybe that’s an option too?), to convey what it actually means today, what can we to do to persuade projects to actually respect, and reward, non-code contributions?