Code of Conduct in Open Source Projects

Reviewed by Greg Wilson / 2021-09-18
Keywords: Open Source

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 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.

Tourani2017 Parastou Tourani, Bram Adams, and Alexander Serebrenik: "Code of conduct in open source projects". 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), 10.1109/saner.2017.7884606.

Open source projects rely on collaboration of members from all around the world using web technologies like GitHub and Gerrit. This mixture of people with a wide range of backgrounds including minorities like women, ethnic minorities, and people with disabilities may increase the risk of offensive and destroying behaviours in the community, potentially leading affected project members to leave towards a more welcoming and friendly environment. To counter these effects, open source projects increasingly are turning to codes of conduct, in an attempt to promote their expectations and standards of ethical behaviour. In this first of its kind empirical study of codes of conduct in open source software projects, we investigated the role, scope and influence of codes of conduct through a mixture of quantitative and qualitative analysis, supported by interviews with practitioners. We found that the top codes of conduct are adopted by hundreds to thousands of projects, while all of them share 5 common dimensions.