Bcc

In thinking about group governance practices, it seems like setting out explicit norms can be broadly useful, no matter the particular history that's motivated the adoption of those norms. In a way, it's a common lesson of open source collaborative practice: documentation is essential.

For what it's worth, I don't think this is an ideological presumption, but an empirical observation. Lots of people have noticed lots of open source communities where the stated goal of decision-making by "meritocracy" has apparently contributed to a culture where homogeneity is preferred (because maybe you measure the vague concept of "merit" in some ways by people who behave most similarly to you) and where harassment is tolerated (because if the harasser has some merit -- again, on that fuzzy scale -- maybe that merit could outweigh the negative consequences of their behavior).

I don't see the critiques of meritocracy as relativistic; that is, it's not an argument that there is no such thing as merit, that nothing can be better than something else. It's just a recognition that many implementations of claimed meritocracy aren't very systematic about evaluation of merit and that common models tend to have side effects that are bad for working communities, especially for communities that want to attract participants from a range of situations and backgrounds, where online collaboration can especially benefit.

To that point, you don't need to mention "merit" or "meritocracy" at all in writing a code of conduct and establishing such a norm doesn't require having had those experiences with "meritocratic" projects in the past. Having an established norm of inclusivity makes it easier for everyone. We don't have to decide on a case-by-case basis whether some harassing behavior needs to be tolerated by, for example, weighing the harm against the contributions of the harasser. When you start contributing to a new project, you don't have to just hope the leadership of that project shares your desire for respectful behavior. Instead, we just agree that we'll follow simple rules and anyone who wants to join in can get a signal of what's expected. Others have tried to describe why the practice can be useful in countering obstacles faced by underrepresented groups, but the tool of a Code of Conduct is in any case useful for all.

Could we use forking as a mechanism for promoting inclusivity rather than documenting a norm? Perhaps; open source projects could just fork whenever it became clear that a contributor was harassing other participants, and that capability is something of a back stop if, for example, harassment occurs and project maintainers do nothing about it. But that only seems effective (and efficient) if the new fork established a code of conduct that set a different expectation of behavior; without the documentary trace (a hallmark of open source software development practice) others can't benefit from that past experience and governance process. While forking is possible in open source development, we don't typically want to encourage it to happen rapidly, because it introduces costs in dividing a community and splitting their efforts. Where inclusivity is a goal of project maintainers, then, it's easier to state that norm up front, just like we state the license up front, and the contribution instructions up front, and the communication tools up front, rather than waiting for a conflict and then forking both the code and collaborators at each decision point. And if a project has a goal of broad use and participation, it wants to demonstrate inclusivity towards casual participants as well as dedicated contributors. A casual user (who provides documentation, files bugs, uses the software and contributes feedback on usability) isn't likely to fork an open source library that they're using if they're treated without respect, they'll just walk away instead.

It could be that some projects (or some developers) don't value inclusivity. That seems unusual for an open source project since such projects typically benefit from increased participation (both at the level of core contributers and at lower-intensity users who provide feedback) and online collaboration typically has the advantage of bringing in participation from outside one's direct neighbors and colleagues. But for the case of the happy lone hacker model, a Code of Conduct might be entirely unnecessary, because the lone contributor isn't interested in developing a community, but instead just wishes to share the fruits of a solitary labor. Permissive licensing allows interested groups with different norms to build on that work without the original author needing to collaborate at all -- and that's great, individuals shouldn't be pressured to collaborate if they don't want to. Indeed, the choice to refuse to set community norms is itself an expression which can be valuable to others; development communities who explicitly refuse to codify norms or developers who refuse to abide by them do others a favor by letting them know what to expect from potential collaboration.

Thanks for the interesting conversation,
Nick