Ben Collins-Sussman and Brian Fitzpatrick’s excellent “How Open Source Projects Survive Poisonous People (And You Can Too)” presentation closed out my first day here at OSCON. Ben and Brian poured out their collective learning on how to manage poisonous people in open source projects. Their experiences with the Subversion community gave them tons of insights on how to spot poisonous people, how to protect against them and what to do if your project gets infected by these people.

The premise for their talk was: “Attention and focus are your scarce resources and you need to protect them”. Poisonous people tend to distract communities and scatter the attention and focus of the people who should continue developing new features or fixing bugs. Communities must avoid deadlock by not letting people derail forward progress. For instance, people in the community can ask endless questions or focus on perfection (in a design or feature set) and bogart the attention of developers.

To avoid this, Ben and Brian suggest building a strong community by adhering to these values:

  • politeness
  • respect
  • trust
  • humility

A poisonous person who enters the community and does not adhere to these values, will quickly find themselves at odds with the rest of the community. Some more concrete practices for building a resilient community include:

  • Document your project’s history (design decisions, bug fixes, mistakes, code changes) If you don’t, you will tell the story over and over, wasting your time.
  • Have healthy collaboration practices: Send commit mails, encourage people to review those, carry out big changes on a branch, don’t use branches sparingly.
  • Increase your project’s bus factor. If one person gets run over by a bus, make sure they don’t take the only knowledge of a piece of code to their grave.
  • Don’t allow names in source files — this creates unnecessary sense of ownership of a piece of code. Your version control system should keep track of who worked on it for credit/copyright reasons.
  • Grant partial commit access. Not everyone needs to have commit access to an entire code repository.
  • If you don’t trust someone, don’t give them commit access.

Robust OSS projects should also have a well defined process for releasing software, how to make bug fixes, testing/releases and adding new committers. The community that starts the project sets the tone for the project and that culture becomes self selecting. A healthy community should be able to reach consensus — leave voting on issues as a last resort when the community is split on an issue.

Next, Ben and Brian offered suggestions for how to spot poisonous people in your community. Be wary of people who have multiple nicknames, silly nicknames (l33t speak, for instance) or all CAPS nicknames. Also avoid people with a general lack of clue, people who are unable to pick up on a mood, people who don’t understand the goals of the community and people who ask questions that could easily be answered by RTFM. While none of these are certain signs of poisonous people, they can often times be an early warning sign.

Also, watch out for hostile people who insult the status quo, angrily demand help, have a sense of entitlement, who blackmail others, who deliberately rile people up and those who make accusations of conspiracy (signs of paranoia). Conceited people also present dangers — be wary of people who refuse to argue with other’s opinions, who make sweeping claims (often times about the future success of the project) and people who re-open topics that have been long settled.

Finally, look out for people unwilling to cooperate with others. Be wary of people who complain, but are unwilling to help fix the problem at hand, people who refuse to discuss design and people who cannot take criticism.

Then Ben and Brian moved on to their last section where they presented some ideas for dealing with people who have infected your community. First, assess if this person is draining attention and diverting the focus of the community. If so, ask if this person is likely to benefit the project.

They suggested that you don’t: Feed their negative energy, give a**holes purchase, engage them or get emotional. Doing so will only encourage the person to continue with their antics.

Ben and Brian suggested that you do: Pay attention to a newcomer, even if they are annoying at first and look for fact under the emotion (extract the real issue from an emotion laden bug report). Also, know when to ignore a problem person, know when to forcibly boot someone from the community and repel trolls with niceness.


Phew. This talk was packed with many goodies as you can tell from the density of this post. I wish I could recount all the brilliant examples they used to illustrate their points, but I guess you really needed to have been here to get the full effect of their talk.

I personally feel privileged to have heard this talk — I’ve been frustrated with various poisonous people I’ve encountered in my open source projects. When someone is insulting your hard work after putting out a release its hard to think objectively about these poisonous people. But now that Ben and Brian helped organize my chaotic experiences into a more coherent approach to dealing with poisonous people, I think I will be better prepared for the next time when I’m annoyed with poisonous people.