Hostility, inclusivity, and target mismatch in open source community management

Hostility, inclusivity, and target mismatch in open source community management

The reputation that open source communities have for hostility is justified. Open source communities, particularly those surrounding older projects or those whose members are mostly part of the old guard, tend to be elitist (in the sense that they expect a high level of competence from even new contributors and react with hostility to contributions that don’t meet their standards). Whether or not this is a bad thing depends on which of several groups you belong to within the open source sphere.

There are a couple different ways to look at the purpose of an open source community. One is the FSF attitude: that licensing is a social and moral concern, and so opening up software is valuable in of itself. The second is the Cathedral & Bazaar attitude: development methods associated with open source communities are more efficient at creating reliable software than those associated with traditional proprietary shops. The third I will call the BSD attitude (not because I think BSD maintainers necessarily subscribe to it, but because people who take this attitude often use permissive licenses like the BSDL): open source development methods are sensible because, in the absence of a profit motive, there’s no point in making any particular effort to lock down the source code for your personal projects.

If you hang out with contributors or maintainers of open source projects, you will meet all three types of people. The thing is, these goals have very different ramifications.

The CatB attitude and the BSD attitude both favor hostility, in a sense. Within the CatB attitude, the primary goal is to produce good software — so, low-quality submissions aren’t worth considering, and nurturing beginners to the point where their contributions aren’t a net resource drain is a potentially risky business decision. Within the BSD attitude, the point is to minimize effort, so taking even high-quality submissions is often not worthwhile: forks are encouraged over pull requests, since looking at patches is too much work. In the FSF attitude, however, software freedom is a social justice issue to be weighed against other issues, and the codebase is just the foundation upon which the much more important community is built — in other words, the health of the community takes priority over the functionality of the code.

This is not a defense of elitism on grounds other than technical competence. In theory, discrimination along irrelevant lines damages all three of these goals[1]. Instead, this is to say that for two of the three types of open source contributors, being welcoming to contributors who aren’t already producing professional-level code literally runs counter to their goals. The kind of performative hostility toward low-quality submissions that Linus Torvalds (for instance) is known for is useful in this context: so long as people have a reasonably accurate sense of their own competence & the degree to which their code meets the goals of the project and adheres to the community’s best practices[2], these outbursts act to raise the average quality of contributions — and both good patches that are never submitted and the loss of potentially good future contributors is considered justifiable given the huge number of current contributions.

I don’t consider any of these attitudes necessarily wrong. I value high-quality code, inclusive communities, and my own free time. I think a lot of conflict comes from these concerns being juggled within the same project by people who are unaware that they’re dealing with a completely different set of goals. In particular, people who are primarily concerned with inclusiveness tend to assume that all open source projects are (or should be) primarily concerned with inclusiveness (and see people who are primarily concerned with submission quality as callous), and people who are primarily concerned with submission quality tend to assume that all open source projects are (or should be) primarily concerned with submission quality (and see people who are primarily concerned with inclusiveness as naive). Since many open source projects have adopted community guidelines as a way of codifying intended behavior, it makes sense to explicitly specify the priority of the project in those guidelines.

For my own case, I generally take the BSD attitude with regard to projects I administrate or maintain: releasing my code publicly is what I do because, in the absence of a good reason to keep the source code secret, I feel like only an asshole wouldn’t make a useful utility generally available. To that end, I am considering adding a blurb to the README for my projects indicating that, while I am happy for people to use my projects, I do not intend to provide support or take patches, and that those who want to distribute their own changes should create a fork. (This is something notably done by mewo2’s terrain generator project.) For larger or more long-running projects, I will probably simply do the pull-request hack.

For those of you who take the FSF or CatB attitude, I recommend inserting an indication of your intent into your READMEs as well. Something along the lines of “This project’s community is paramount, so contributors are expected to support each other, to the point of mentoring less experienced community members” or “The quality of this codebase takes precedence over its community, so please expect poor-quality submissions to be summarily rejected”, respectively.

[1] Obviously there are toxic and dysfunctional communities that act against their own goals, and when money is being funneled in or there’s corporate influence, these goals often get put on the back burner with profit motive — often in the form of mere continued existence — becomes the primary motivation between actions; in the case of Silicon Valley VC funding, continued existence may actually depend upon racial or sex discrimination, in the form of maximizing investment by making sure most contributors physically resemble Marc Zuckerberg.

There are also systemic biases that make it harder for certain groups to achieve competence, but of the three attitudes we discuss, only one considers trying to correct for these biases to be within the scope of their projects.

[2] The ability to evaluate one’s own competence is associated with competence — in other words, the Dunning-Kreuger effect applies. What people forget about the Dunning-Kreuger effect is that above a certain level of competence, perceived competence is systematically underestimated. So, if the base level of confidence is lower for some group (for instance, women in the open source community), the most competent members of this group may decide their abilities are below the accepted level — in other words, only a band in the middle of the competence spectrum will actually contribute.

This is a problem that huge projects concerned primarily with code quality won’t bother to address: the bottleneck is typically the time spent by maintainers evaluating patches on the border of acceptability, and there are enough excellent patches just by the law of large numbers that systematically missing high quality patches from a particular group isn’t a big deal.