Conducting Oneself

Right now, there are a lot of hot takes in the Open Source community about codes of conduct (CoCs). Linus Torvalds came forth recently, admitting that he was a jerk, and that his jerkiness has excluded technically talented people from contributing to the Linux kernel. The Linux kernel project adopted a CoC! It’s pretty basic, but not so bad as things go.

Why do open source projects benefit from having a code of conduct? Open source projects are the foundation of the internet. In my opinion, open source projects are the key to creating a better world for us all. The ideals of open source, free software to which we can all contribute and improve, from which we can all draw inspiration and benefit, are worth pursuing. Unfortunately, these ideals do not exist in a vacuum.

Structural and cultural issues exist which provide an uneven playing field. We do not all have the same resources, time, and life experiences. Codes of conduct level the playing field, and give opportunities to more people to contribute to open source projects. When more people contribute more diverse ideas to open source projects, we all benefit.

How do codes of conduct do this? By outlining the professional decorum we expect contributors to our project to follow. These are very basic rules, which to some boil down to “basic human decency.” Still, by stating these expectations explicitly, and providing well-defined consequences for failing to meet these standards, we provide assurances to people in marginalized communities that they can contribute without being subjected to the behaviors we’ve ruled out in our code of conduct.

When people write un-serious codes of conduct, they signal to people that they do not intend to be welcome spaces to ideas outside the unspoken, unwritten norms of the community. That they are not “open” spaces. This is antithetical to the spirit of open source software. SQLite is one example of an organization that has written an un-serious code of conduct. It’s disappointing that an open source project with a reputation for writing quality, well-tested, well-constructed code would decide to exclude people in this manner.

When people write serious codes of conduct that do not address common forms of excluding marginalized communities, they do at least as much damage as having an un-serious code of conduct, by signaling to people within the community who participate in exclusionary behaviors that these behaviors are not going to be sanctioned by the community. The GNU Project is one such example of a project that has written a code of conduct that doesn’t do a good job of addressing the ways in which marginalized communities are excluded. I’ll address its shortcomings below: (my comments are in bold)

The GNU Project encourages contributions from anyone who wishes to advance the development of the GNU system, regardless of gender, race, religion, cultural background, and any other demographic characteristics, as well as personal political views.

“Political views” is very tricky phrasing. Today, some people might consider it a “political view” that another group ought not to exist, or that their existence be predicated on their subjugation. By stating that a project accepts contribution regardless of “personal political views,” the GNU project is signaling that they accept contribution from people whose “political views” preclude the rights of the other categories mentioned.

People are sometimes discouraged from participating in GNU development because of certain patterns of communication that strike them as unfriendly, unwelcoming, rejecting, or harsh. This discouragement particularly affects members of disprivileged demographics, but it is not limited to them. Therefore, we ask all contributors to make a conscious effort, in GNU Project discussions, to communicate in ways that avoid that outcome—to avoid practices that will predictably and unnecessarily risk putting some contributors off.

These guidelines suggest specific ways to accomplish that goal.

Please assume other participants are posting in good faith, even if you disagree with what they say. When people present code or text as their own work, please accept it as their work. Please do not criticize people for wrongs that you only speculate they may have done; stick to what they actually say and actually do.

Please think about how to treat other participants with respect, especially when you disagree with them. For instance, call them by the names they use, and honor their preferences about their gender identity.

The word “preferences” is problematic here. People do not have gender identity “preferences”. They have gender identities. Including the word “preferences” signals an implicit devaluing of “preferences” that fall outside the norms of the GNU Project.

Please do not take a harsh tone towards other participants, and especially don’t make personal attacks against them. Go out of your way to show that you are criticizing a statement, not a person.

Please recognize that criticism of your statements is not a personal attack on you. If you feel that someone has attacked you, or offended your personal dignity, please don’t “hit back” with another personal attack. That tends to start a vicious circle of escalating verbal aggression. A private response, politely stating your feelings as feelings, and asking for peace, may calm things down. Write it, set it aside for hours or a day, revise it to remove the anger, and only then send it.

This statement presumes childish immaturity on the part of people targeted by statements covered under the previous clause, especially as it goes on to detail a set of elementary school instructions for dealing with ones feelings. This clause might better be excluded, or truncated at the first two sentences.

Please avoid statements about the presumed typical desires, capabilities or actions of some demographic group. They can offend people in that group, and they are always off-topic in GNU Project discussions.

Please be especially kind to other contributors when saying they made a mistake. Programming means making lots of mistakes, and we all do so—this is why regression tests are useful. Conscientious programmers make mistakes, and then fix them. It is helpful to show contributors that being imperfect is normal, so we don’t hold it against them, and that we appreciate their imperfect contributions though we hope they follow through by fixing any problems in them.

Likewise, be kind when pointing out to other contributors that they should stop using certain nonfree software. For their own sake, they ought to free themselves, but we welcome their contributions to our software packages even if they don’t do that. So these reminders should be gentle and not too frequent—don’t nag.

By contrast, to suggest that others use nonfree software opposes the basic principles of GNU, so it is not allowed in GNU Project discussions.

Please respond to what people actually said, not to exaggerations of their views. Your criticism will not be constructive if it is aimed at a target other than their real views.

If in a discussion someone brings up a tangent to the topic at hand, please keep the discussion on track by focusing on the current topic rather than the tangent. This is not to say that the tangent is bad, or not interesting to discuss—only that it shouldn’t interfere with discussion of the issue at hand. In most cases, it is also off-topic, so those interested ought to discuss it somewhere else.

If you think the tangent is an important and pertinent issue, please bring it up as a separate discussion, with a Subject field to fit, and consider waiting for the end of the current discussion.

Rather than trying to have the last word, look for the times when there is no need to reply, perhaps because you already made the relevant point clear enough. If you know something about the game of Go, this analogy might clarify that: when the other player’s move is not strong enough to require a direct response, it is advantageous to give it none and instead move elsewhere.

Please don’t argue unceasingly for your preferred course of action when a decision for some other course has already been made. That tends to block the activity’s progress.

If other participants complain about the way you express your ideas, please make an effort to cater to them. You can find ways to express the same points while making others more comfortable. You are more likely to persuade others if you don’t arouse ire about secondary things.

Please don’t raise unrelated political issues in GNU Project discussions, because they are off-topic. The only political positions that the GNU Project endorses are (1) that users should have control of their own computing (for instance, through free software) and (2) supporting basic human rights in computing. We don’t require you as a contributor to agree with these two points, but you do need to accept that our decisions will be based on them.

This is incredibly and overly broad, even with points (1) and (2), and leaves space for people of ill-intent to shut down virtually any conversation simply by stating that it’s an “unrelated political issue."

By making an effort to follow these guidelines, we will encourage more contribution to our projects, and our discussions will be friendlier and reach conclusions more easily.

Finally, the GNU Code of Conduct doesn’t outline any consequence for violating it, nor does it provide a method for escalating complaints or abuses of the CoC. This “code” is totally unenforceable, which itself signals strongly to people in underrepresented communities that it provides no protection at all.

We, as open source contributers, deserve a healthy, kind, thriving Open Source ecosystem to which we can all contribute without fear of being excluded for who we are. Codes of Conduct are the first step in ensuring that our projects exude this kindness.

CoCs are not one-size-fits-all, but we can all create documents that make our projects better places to work for everyone. For anyone starting an open source project, I highly recommend the Contributor Covenant as a great starting point.