How do I handle aggressive or toxic project maintainers?

Question

One thing in OSS I have now run into a few times are project owners or maintainers who are very aggressive. Sentences are taken out of context, asking about a design decision is seen as an attack and a demand for free work, and the most mild of statements are labelled as abusive.

I have tried engaging, but the fever pitch of their reaction started to look like they were going to involve a lawyer over a versioning option. This latest one I think I just need to stop all communication. But is there a better way?

Answer 1

In the end, an open source project is just a bunch of humans, and where there are humans there isn't always harmony. This is a social problem, it is not specific to open source, and there is nothing particular about open source that would help avoid this.

However, open source has an escape hatch: any open source license allows you to fork the project. You can do your own thing, without having to engage with the current maintainers. The two projects can still use each other's patches as long as they stay under compatible licenses.

If you do a better job at maintainership than the current maintainers (and good maintainership involves social aspects such as the tone used to respond to bug reports), then the community may eventually migrate over to your fork. Or may not. Part of the beauty of open source is that the code and the community cannot be shackled to a particular maintainer or vendor.

Such forks (either a fork of the code that won over the community, or the community moving to a similar but separate project) have happened multiple times over the history of open source. An older example might be the XFree86 server that was developed by a Core Team. After some drama most developers eventually moved to the X.org fork that is nowadays used by most Linux distros. A more recent example is the Node.js → io.js fork in 2014 over a disagreement in project governance. However, a few months later the two projects reunited under the governance of a neutral foundation.

Unfortunately, maintainership requires a ton of effort.

If you really want to go that route, you should check a couple of things first:

• Is the project really under an open source license? OSI-approved licenses should be fine.
• Is the project name encumbered by trademarks? For example, you cannot distribute your own version of “Java” or “Firefox” without changing the name and branding.
• Does the license include a requirement to change the name? The Artistic License and the Open Font License come to mind.
• As a practical consideration: is the original maintainer particularly litigious? Just because you have a right to fork the code doesn't mean they will accept this. They could e.g. hit a GitHub repo with a DMCA notice which will force it to be taken down at least temporarily.

Maintaining a good fork isn't just a lot of effort, it will also be perceived as as quite hostile move. This will likely sever your relationship to the original maintainers beyond repair. But if you don't have a workable relationship to begin with, nothing is lost.

Answer 2

Deb Nicholson gave an excellent talk at FOSDEM 2017 called "Handle conflict like a boss". I wrote the whole talk up for LWN, and the original talk is likely available on the FOSDEM servers somewhere, but some points I found important included

• Conflict happens because some people are missing some information

  She showed a slide with a sign from a local "boat and dog wash", and asked us to think about the reaction of the dog washers to a boat washer who announced they'd made things much more efficient by the introduction of a highly-caustic soap that cleaned boats in half the time. The dog washers will be appalled, and say so, and the boat washer in turn may be quite hurt that his or her work in optimizing the wash is unappreciated.

• Passion can become a problem

  The same motor that drives us to do these amazing things can drive us straight onto rocks, as people get caught up in the enthusiasm of the moment and lose sight of the goal.

• Sense of identity can be a minefield, especially when tied up in something task-oriented rather than goal-oriented

  It's all very well to have a project to upgrade the bug tracking system to one that doesn't require hours of volunteer work to keep it ticking along, but the person who's known throughout the community as the volunteer who keeps the bug tracking system running may get upset if they're not fully invested in the upgrade.

It can help to be aware that there are generally three ways people handle conflict: avoidance, which can lead to festering and eventual disconnection; accommodation, which can lead to the adoption of false or unworkable middles out of a desire to make the conflict go away; and assertion or aggression, where behaviour degrades to provoke responses.

She reiterated that more information is generally the best way to help; often the information that some people, usually newer arrivals, are missing is the historical information. That is particularly important because it tends to explain why we do things the way we do them.

While it would be nice if the project maintainers and managers were thinking these thoughts every day, if - as is common - they are far from those people's minds, there's quite a lot you can do if you keep them near the forefront of yours. And if it proves impossible to prise any of these project leaders out of their toxic behaviours, then find another project to contribute to that's better for your blood pressure. As Sarah Sharp once said "there are many FOSS projects, but only one me".