What? And why?

This past week, I’ve learned that licenses and Codes of conduct are essential documents that accompany Free and Open Source Software (FOSS) projects. A Code of conduct is a set of guidelines and expectations that contributors must follow. While each team can technically be super creative and specific, most choose to stick to an existing template. Not to reinvent the wheel. The good thing is that if the code is open source, the code of conduct is too!

Here’s why having such a document is beneficial for any FOSS project:

• Efficiency. Conflict resolution can be tedious, while unresolved issues can stall progress and discourage people from participating in future tasks. Interpersonal conflicts—arising from cultural and linguistic differences, or simply from people being rude—can damage the team spirit, which is crucial in a project that primarily relies on free labor.

• Good PR. Having a code signals that the project’s maintainers are committed to fostering a respectful and inclusive working environment, which can attract new contributors. A project with a code that protects contributors’ rights and dignity is more appealing than one without such guidelines.

How different projects approach their Codes of conduct

When reviewing Go’s Code of Conduct and comparing it to the Contributor Covenant template, I noticed a new addition in the Scope section. It states that the code “applies outside the project spaces when … an individual’s behavior may have a negative impact on the project or its community.” While many private companies enforce similar policies to protect their reputation, I haven’t seen this kind of provision in other FOSS projects. Essentially, this clause discourages developers from associating themselves with the project if they plan to do something stupid.

Another notable difference we found in class is the inclusion of a Values section. While the Contributor Covenant has a section called Standards, its tone is more corporate compared to Values, which feels much more informal. This raises a question: can you always be objective and fair when enforcing principles like “being charitable” or penalizing people for “snarking”?

More examples…

• Eclipse’s Community Code of Conduct is another code “forked” from the Contributor Covenant. Unlike Go’s version, Eclipse explicitly states that its Code “is not intended to govern scenarios or behaviors outside of the scope of Eclipse Foundation activities.” This document also includes a No Retaliation clause and a Investigation of Potential Code Violations section, both of which outline the possible consequences of a wrongdoing by a contributor. I think that because FOSS contributors communicate online and can be anonymous, it is especially important to prohibit any form of retaliation. The document repeatedly mentions that Eclipse has a separate committee overseeing code violations, along with an executive board.

• The Sugar Labs CoC is based on Ubuntu’s CoC rather than the Contributor Covenant, so it has a different structure from what we’ve seen so far. It does not divide the clauses into values or standards and replaces the Pledge section with a brief exploration of the project’s mission and background. Unlike other code, this document is located in the Legal subcategory of the Sugar Labs Wiki. While it does not contain a clause on any legal procedures, it is interesting that it is still considered a legal document.

How much do you really need a Code of conduct

I stumbled upon SoftEtherVPN, a FOSS project that has adopted No Code of Conduct. This code, if it can be called so, begins with “We are all adults. We accept anyone’s contributions. Nothing else matters.” Instead of a set of guidelines, it contains a set of FAQs, the responses to some of which read, “We are not a support group for human emotion” and “Simply because we don’t babysit people on our site … does not mean we hope you feel unwelcome.” I think this example highlights another aspect of FOSS projects: they are often decentralized and there is not always a governing body (like Eclipse’s committee) to watchdog the enforcement of a code. In such a scenario, an extensive code can actually become a burden for the project if there are no efficient ways to enforce it and many developers don’t intuitively follow it. I found this example extremely interesting because I had spent quite a few hours reading and writing about the importance of having a code, but turns out some projects just decided they didn’t need one!