How Open Source Projects Survive Poisonous People (And You Can Too)
OSCON 2006 Session Report
Title: How Open Source Projects Survive Poisonous People (And You Can Too)
Speakers: Brian W. Fitzpatrick, Ben Collins-Sussman — Google, Inc.
The central theme of this talk is that attention and focus are the currency of an open source project and which must be protected. Poisonous people can erode both of these attributes. The speakers presented their opinions based on their experiences with the Subversion project. As they describe it, the Subversion project uses the “community model” rather than the “benevolent dictatorship model.” The implication is that surviving poisonous people in this model may require more subtlety.
While discussing poisonous people, the speakers also gave their take on the environment and culture of a healthy open source project.
Avoid Paralysis
Besides focus and attention, I think another key element of a project is momentum. The speakers’s take on this is to avoid paralysis. Specifically, watch out for perfectionists as well as the process-obsessed. Both of these types of people are often well-meaning but their traits, in some cases, can bog down a project. The quote they used (I missed the attribution) was, “The perfect is the enemy of the good.”
Interact Effectively with the Community
When interacting with members of the community, it is important to use politeness, respect, trust, and humility. In addition, it is important to have a thick skin and not take things too personally. When dealing with users on discussion lists, don’t try to reply to every message in a thread. Also, don’t rehash old discussions; when these come up, send people to the mail archives or documentation.
Document
In addition to documenting the current state of the project, it is also important to document the history. A changelog captures bug fixes and enhancements. Just as important to capture, however, are design decisions and lessons learned (i.e., mistakes made). By documenting design decisions, one can avoid rehashing settled matters on the discussion lists.
Have Healthy Code-Collaboration Policies
The speakers recommended the following (non-inclusive) list of healthy code-collaboration policies:
- Send commit emails and encourage reviews of the committed code.
- Make big changes on branches for easier review.
- Encourage developers with big ambitions (1) to pre-announce their intentions and (2) to have them commit in small pieces on a separate branch. This gives everyone the chance to both review the design as well as review the code as it develops. Huge, unreviewed commits (i.e., “power plants”) slow progress and can lead to animosity between the committer and the developers.
- Be generous with code branches.
- Maintain a high “bus-factor” on the components of the project. The “bus-factor” represents how many developers would have to get hit by a bus before development on a component would become crippled.
- Don’t allow names in files. This is part of the culture of humility.
Have Well-Defined Development Processes
This speakers emphasized the need to have well-defined development processes in place at the beginning of the project. This includes software releases (e.g., backport bug fixes, test releases, tarball builds), patch acceptance/review, and admitting new committers (the project founders establish the culture and from there it becomes self-selecting). In rare cases, issues must be put to a vote (remember, there is no benevolent dictator in their model), but this should be a last resort; a healthy community rarely needs to vote.
Detect Poisonous People
Because poisonous people put a drain on the project, it is important to detect them. Some common traits of poisonous people include: use of silly (or multiple) nicknames, overuse of capital letters in their postings, generally clueless (e.g., they are unable to pick up the mood of the discussion, they don’t understand project goals, they don’t read the documentation), are hostile (e.g., insults, demands, threats of blackmail, accusations of conspiracy), and a lack of cooperation (willing to complain–but not help, unwilling to discuss design, too insecure to take criticism).
Handle Poisonous People
Once you have identified a poisonous person, don’t engage them, don’t get emotional, and don’t take the flamebait.
That said, do pay careful attentions to newcomers even if they are annoying at first—they may turn out to be valued contributors. If someone posts a flame, try hard to discern the issue and address only that. Ultimately, you must know when to give up and ignore them (or even expel them from the community). Stay cool but stand your ground.
The talk wrapped up with a summary of the above followed by some Q&A.
