This week, we went over the ethics and ideology of open-source contribution in more detail, specifically focusing on the communities that facilitate those contributions. We spent a considerable amount of time on leadership structures and licenses, discussed the pros and cons of each, and most importantly, defined how they affected the communities that contributed to open-source projects.

And one of the most important factors in facilitating cooperative environments for open-source projects is ensuring that people feel safe to contribute. The way many projects have chosen to do that is with Codes of Conduct. Codes of Conduct define what behaviour is acceptable or tolerated within a project’s community. And they’re instrumental in ensuring contributors feel safe to push new ideas and new changes.

Go’s Code of Conduct

We, in particular, looked at Go’s code of conduct. It’s a good example of how a project can actively shape its community. It lays out the values the community expects: be patient, respectful, thoughtful, and responsible. Healthy disagreement is fine, but harassment, insults, or other disrespectful behavior aren’t tolerated. It also establishes the leadership structure, making it clear who handles issues. Project stewards and committees are given these responisibilities, so enforcement isn’t vague. The code of conduct is designed to keep the environment welcoming and safe, making it easier for contributors to engage and collaborate without worrying about drama.

However, the Go conduct code outlines the “Gopher Community” values, which apply both inside the project and when representing Go elsewhere, recognizing that your behavior outside can still affect the community, which is something that might be overlooked by contributors if not stated explicitly here. This is a valuable addition, as it realises that the community image expands beyond just the product itself, especially in a user-facing product like Go, which depends heavily on being trusted and favoured by the developer community.

Eclipse

In contrast, Eclipse is much more formal and legalistic. It’s designed for a large foundation with corporate members, so it reads like policy and governance rules. It defines more committees, directors, board positions, oversight, staff roles and responisibilities - all things you’d see in a corporation’s bylaws. In effect, this is like bylaws. However, instead of applying only to employees, it applies to all members and contributors, in accordance with open-source philosophy.

Sugar Labs

The Sugar Labs Code of Conduct considerably different in its approach. It’s based on the Ubuntu Code of Conduct and, in accordance, focuses more on collaboration and learning than strict enforcement. It emphasizes being considerate, respectful, and flexible, and encourages contributors to ask for help and resolve disagreements constructively. It’s not built around what not to do, but rather what to do.

As such, instead of listing “bad behaviors” in detail, it frames everything around how to work together effectively. It does still have committees and procedues (in particular, an Oversight Board and ombudsman to handle disputes) but the format of these roles shows the project values guidance and mediation over punishment.

OpenRC

OpenRC’s code of conduct, however, is interestingly chosen. It’s adapted from the Contributor Covenant v2.1, which is unusual given the type of project it is. For a project built by a small community of passionate contributors aiming to replace something they felt was “too corporate” and “scope-crept,” you would expect a minimal code of conduct outlining ideal behaviours, rather than a list of things to avoid. However, the OpenRC code of conduct, too, seems to focus extensively on preventing “bad behaviours,” outlining strict penalties, systems and councils to enforce penalties and ensure community order and structure, and leadership systems. It emphasizes what types of behaviours OpenRC contributors should not engage in, and outlines penalties and consequences for violations.

Though maybe it makes sense for a project built so heavily around what it’s not (systemd) to have a Code of Conduct that reflects that mentality.