Summary from “Open Source Projects and Poisonous People” by Brian Fitzpatrick and Ben Collins-Sussman

You have four steps to get rid of that annoying poisonous people:

  • 1. Comprehension: understand which kind of people you’re dealing with. Preserve attention and focus.

  • 2. Fortification: how to fight against it or how to protect yourself against it. Build a healthy community.

  • 3. Identification: how to identify poisonous people. Look for tell-tale signs.

  • 4. Disinfection: how to disinfect your community from the poisonous person. Maintain calm and stand your ground.

In an open source project, you’ve got two main resources: attention and focus. These resources are the scarcest. You must protect them. To understand the annoying feeling given by poisonous people, imagine that you have a group of people and pile of money in a table and someone comes in the room and start taking money out of that pile. That’s what the founder of an open source project feels with poisonous people. They take attention and focus from the group, and that’s a huge loss project talking.

  1. Comprehending the threat.

Poisonous people can:

-Distract. They keep distracting you, draining you.

-Emotionally drain your community.

-Cause needless infighting.

You need to avoid paralysis. OCD (Obsessive-compulsive disorder) people can derail forward progress:

  • Perfectionists. They keep full focusing on their part of the project to make it better even if it’s not needed anymore.

  • People obsessed with process. They always want to have a process to work, the need you to give them orders.

Even nice guys can be poisonous unintentionally. Sometimes they don’t even realize that they’re starting to be like that.

You need to disengage yourself in order to keep moving forward, not getting stuck in an endless discussion just to try to prove your point. A nice form to do this is by telling them something like “We’re going to try this and see if it works”.

  1. Fortifying against the threat.

The first thing to do is build a strong community based on four things:

-Politeness. They have to be kind with newcomers.

-Respect. Respect each other to keep growing as a healthy community.

-Trust. Reliability with the team is important to make everyone feel welcome.

-Humility. Conceited people are really annoying.

Document your project’s history. If you don’t document your project’s history, you’ll need to repeat it over and over again to every user who asks. Document things like:

  • Design decisions.

  • Bug fixes.

  • Mistakes: this is the most important thing you need to document. If you document mistakes, you won’t need to repeat it to every person who comes out with a “new” idea that you’ve tried before and didn’t work. You’ll show people that you’ve actually thought about it and they won’t try to do it again.

  • Code changes.

Have healthy code collaboration policies:

  • Send commit emails, encourage email review.

  • Do big changes on branches for easier review.

  • Be generous with branches.

  • Increase your project’s “bus-factor” on components: you need to let people participate in a part of the project together. Try to make groups of work, because sometimes there’s an important part of your project being made by just one person and suddenly that person disappear (that’s why they call it “bus-factor”, because it seems that he was hit by a bus and died), the code is there and no one knows anything about it or about its logic.

  • Don’t allow names in files.

Have well-defined processes:

  • Releasing software. You need a release process documented for your software.

  • Accepting and reviewing patches.

  • Admitting new committers

    • The community founders establish the culture: if you start your project being a nice team full of nice, well-going people, you will attract more of that people. But if you start angry and screaming, then you will attract more angry screaming people. Plan what kind of community you would want to have.

    • The culture becomes self-selecting

Voting is a last resort: a healthy community should rarely need to vote.

  1. Identifying poisonous people

Communication annoyances:

  • Uses silly nicknames. Such as “Superhacker666” or “Darkshadowfalconfromspace”.

  • Uses multiple nicknames in different media. For example, in Yammer his nick is “Pancho Pantera” and in Skype his nick is “Mr. Hacker”.


  • Uses excessive punctuation, like “Hello there!!!1!!1!one!”.

  • Exaggerated talking people, with expressions like “ZOMGWTFBBQ!?!?!”.


  • Unable to pick up on the “mood”

  • Doesn’t understand common goals of the community.

  • Asks incessant RTFM questions.


  • Insults the status quo.

  • Angrily demands help. This person is always asking for help and gets angry if he/she doesn’t get it quickly.

  • Attempts to blackmail.

  • Attempts to deliberately rile people. Better known as trolls.

  • Makes accusations of conspiracy (paranoia).


  • Refuses to acknowledge the opinions of others. They presume their ten degrees and important titles refusing to accept external opinions.

  • Makes sweeping claims. Usually about the project’s future success

  • Re-opens topics that long settled without reading the articles.


  • Willing to complain, but not help fix anything.

  • Unwilling to discuss design.

  • Too insecure to take criticism.

  • You are not your code. It’s not about you, it’s about the code and how to make it better. If you never receive any feedback you never get better.

  1. Disinfecting your community.

Ask yourself two critical questions:

  • Is this person draining attention and focus?

    • If so, is the person really likely to benefit the project?

  • Is this person paralyzing the project?

    • Is the dispute likely to finish soon?


  • Feed the energy creature. If you follow their game, you’re feeding them.

  • Give jerks “purchase”. They will feel important if you focus on their comments.

  • Engage them.

  • Get emotional. If they see you weak, they will attack you even more.


  • Pay careful attention to a newcomer. Even if they’re annoying at first.

  • Look for the fact under the emotion.

  • Extract a real bug report.

  • Know when to give up and ignore them.

  • Know when to forcibly boot them from community.

  • Repel trolls with niceness.

  • Address the behavior, not the person.

One of the most important facts about these instructions and steps is that this doesn’t only apply to open source communities, this applies to all communities.