Code of Conduct in Open Source Projects

It's easy to believe that the world only ever gets worse, but it's not true. A decade ago, most open source projects didn't have codes of conduct, and many others were in the midst of bitter arguments over whether they even should. Today, having a CONDUCT.md file in a project's root directory is as normal as having a license. Enforcement may be spotty, and codes of conduct won't solve tech's systemic failures on their own, but it is progress.

Tourani2017 was the first empirical study of Codes of Conduct in open source. Its authors found that eleven codes of conduct were commonly used, the most common being the Contributor Covenant (which this site uses). While the details vary in important ways, these CoCs specify their purpose, what is considered acceptable behavior, what is not, enforcement mechanisms, and scope (i.e., when and where the CoC applies). To find out how CoCs are used, the authors interviewed several project leaders, who said:

• The main reason for adopting a CoC was experience with negative behavior in previous projects or communities.
• CoC features were mostly chosen on the same basis, though CoCs in commercially-backed open source projects had to balance company policies with community expectations.
• CoCs evolve to reflect experience and in response to changing needs, just like code.
• Most complaints about CoCs came from people outside the project.
• Enforcement mechanisms varied widely. (Note: Aurora2019 is very helpful and highly recommended, but didn't appear until two years after this study was published.)
• "…codes of conduct promote a friendly and inclusive environment, but may induce a policing environment." I personally think the word "policing" is a bit loaded: every community has norms and rules; as Freeman1972 pointed out half a century ago, the only question is whether it's formal and accountable or informal and unaccountable, and the former is much more inclusive than the latter.

Finally, a note about our choice of papers. When I trained as an engineer forty years ago there were still debates about whether software should be considered "technology", or whether that word should only be used for physical things. The eventual answer was that software did count, largely because hardware was useless without it ("no chips without salsa"). Today, many developers would be puzzled by someone calling a Code of Conduct or an agile development process a technology, but these are every bit as much "made things" as bricks, hammers, and algorithms. We don't just create things: we create new ways of creating, and how we ship is every bit as worthy of study as what we ship.