What does toxicity look like in open-source projects?

Toxicity is a huge problem in online communities on social media platforms and multiplayer games, but also in open source.

For example, the Linux Kernel Mailing List is notorious for harsh discussions that discourage newcomers from participating. Toxicity can even cause existing contributors to disengage from projects or abandon them altogether, which has a tangible impact on software quality and security. Moreover, toxicity is a major threat to diversity and inclusion; its impacts are especially felt by women and other minority groups. Toxicity is clearly a problem that needs to be dealt with.

Some communities have turned towards the use of automated detectors of toxicity in open-source discussions. However, such tools tend to lack a fundamental understanding of toxicity and its unique characteristics in open source. We should therefore ask ourselves: when, how, and why does toxicity occur in open source?

Toxicity is often a term that covers various antisocial behaviours like trolling, flaming, hate speech, harassment, and cyberbullying. Research has repeatedly shown that toxic interactions can cause harm, both for people directly involved as well as for observers.

Many open-source maintainers have experienced toxic interactions with the very people who benefit from their often voluntary labour. Toxicity is often written off as a naturally occurring if not necessary part of open source culture, but the opposite is true: for example, researchers have found that impolite issue comments are associated with slower resolution times, unfriendliness in comments deters newcomers, and that unhappiness increases the risk of disengagement.

To understand toxicity in open source, the authors of this paper created a (slightly biased) sample of 100 existing toxic GitHub issues, which were then analysed qualitatively.

Various forms of toxicity can be observed on GitHub:

• Insults were found in over half of the sample. Toxic insulting comments tend to be targeted at people rather than at the code. Insults are often written in an aggressive manner or may criticise the project itself. Although some insults include curse words, fewer use severe language than do not.

• Entitled comments are not common on most platforms (side note: I guess the authors of this paper forgot about warez communities. 😂), but occurred frequently in this sample. Entitled commenters make demands as if they are paying customers (they’re not) and often contain severe language.

• Arrogance is another common form of toxicity, where the author imposes their view on others from a position of perceived authority or superiority. The vast majority of arrogant comments were directed at specific people and are often triggered by technical disagreements.

• Trolling is a form of toxicity that is often seen on other platforms. Such comments tend to use more severe language and target the project rather than people.

• Unprofessional comments are not overly toxic nor are they (probably) intended to be toxic, but can nonetheless create an unwelcoming atmosphere that may be perceived as toxic. Examples include self-pejorative terms, self-deprecating humour, and jokes and puns that are broadly perceived as politically incorrect or unacceptable in a professional setting.

People may have different reasons to post toxic comments; some discussions are opened directly with a toxic comment, while in other cases toxic comments are posted in response to an evolving discussion:

• Problem with the software: Many toxic comments are written when users report a problem with the software. The author of the toxic comment is usually visibly upset and often complains about wasted time. Some comments at least report the problem in some detail, but most are simply rants.

  Although some issues are toxic from the start, toxicity often emerges later, e.g. when maintainers do not immediately respond or solve the problem.

• Technical disagreement: Toxicity can frequently be observed when users have differing views on some technical decision or implementation. This usually happens when discussions get heated.

• Politics/ideology: Toxicity often arises over politics or ideology differences, e.g. beliefs about culture, processes or the involvement of specific companies, like Microsoft.

• Past interactions: In several cases toxic comments referred to past interactions of the author with the project in a non-constructive way, e.g. using personal attacks, complaints or meta-discussions about the process.

The analysis suggests that there are four types of authors of toxic comments:

• About a dozen comments were made by new accounts, which were seemingly created for the sole purpose of posting an issue. These accounts are typically anonymous.

• Repeat issue reporters request help through multiple issues, often across multiple projects, but do not contribute to the community otherwise.

• One would expect experienced contributors from other projects to be more empathetic. Although the language they use is less severe, they do participate in all types of toxicity (even trolling!).

• When project members behave in a toxic manner, it’s usually in response to someone else. Project members rarely attack “unprovoked” and also use less severe language; their comments are often unprofessional or insults that are targeted at code.

Project maintainers deal with toxicity in several ways, e.g. by closing, locking or deleting issues, hiding, deleting and/or editing comments, blocking users, and invoking a code of conduct (side note: which works surprisingly well).

Having said that, in many cases others engage in discussion with someone who has written a toxic message before maintainers do. It’s often possible to turn a discussion into a constructive one, but sometimes engagement can result in even more toxicity!