Protecting your open source project from poisonous people

This previous Thursday I attended a talk by Brian “Fitz” Fitzpatrick of Google on “How to Protect Your Open Source Project from Poisonous People”. Brian started Google’s Chicago Engineering office in 2005 working as an engineer on Google Code. He now leads several of Google’s Chicago engineering efforts, including Google Code, the Data Liberation Front, and the Google Affiliate Network. He also serves as internal advisor for Google’s open source efforts.

Brian started off the talk by recommending “Producing Open Source Software“, a free book written by Karl Fogel. I’ve added the book to my future reading list, and will try to take it in once the semester ends.

A lot of students within Computer Science think that the hardest part about making software is inventing algorithms or finding ways to use obscure data structures for improved performance. As someone who has worked within industry now for a few years, I immediately knew where he was going with this. I agreed with Brian when he said that the actual hardest problem is working with other people.

Poisonous people on a project can make others leave and cause fighting over little things. To reduce this problem, you’ll want to build a strong community based on politeness, respect, trust, and humility. If a person joins on to the project and is causing a disruption of some sorts, it is best to identify behaviors and address them the best way you can. Notice there that addressing behaviors is the goal, not addressing people.

Addressing behaviors vs. addressing people comes up in a lot of conflict resolution scenarios, and often the importance of it is overlooked. Jay Smooth describes a very similar scenario very well.

Brian also recommended defining a mission for the project. As he said, if the mission isn’t already defined, someone else will define it for you.

Feel free to read the rest of my notes from the talk as I’ve typed them up on a Google Doc.