How Open Source Projects Survive Poisonous People.
Google has had the capacity in the past few years to draw in many of the pioneer's and industry leaders to work for them. Two of these people, Ben Collins-Sussman and Brian Fitzpatrick are leaders in the open source world. Both have worked on Subversion which is the version control system used on this project. Of note, Google hired them to implement Subversion through out their product line, and in the process giving the tool the most significant test I could imagine.
The experiences they refer to throughout the presentation are based on work done for both Subversion and Apache. The topic of discussion focuses on how to avoid the toxic or poisonous people that can infect an open source project. The most important aspect of any contribution is to ensure that the team is not drawn down by people not reviewing the archives. Contributions have to be incremental to the work that has been done, not reiterating what has already happened.
The presenters open with their 4 areas of concern.
- Comprehension
- Fortification
- Identification
- Disinfection
- Distract.
- Emotionally drain your community.
- Cause Needless infighting.
- People can derail forward progress by people being.
- Perfectionists.
- People obsessed with process.
- Even nice guys can do this unintentionally.
- The perfect is the enemy of the good.
Fortifying against the threat.
Politeness, Respect, Trust and Humility are necessary in an open source project. All of the deficiencies that the presenters had experienced originated from these 4 points.
Have a Mission, where do your want to go. Limit your developments scope. Define the project so that future requests can be classified as "its on our list of things to do" or "its not"
Mailing lists are a critical tool of the open source project, etiquette should be monitored and enforced. Review of the archives, don't let users disrespect any previous conversations by not reviewing the archives. A few more of their points include;
- Design documentation.
- Bug fixes.
- Document Mistakes. (Ensures that travels down dark alleys are limited and not repeated.)
- Code Changes (Change Log)
- Code Collaboration policies. Email is the key to participation.
- No powerpoints.
- Do big changes on branches for easier review. (Be generous on creating branches.)
- Spreading the "bus factor" so that developers move around alot. (Bus factor is how many people need to get hit by a bus before the project fails.)
- No names on top of source code files. (Makes people nervous) Everything is owned by everyone. (Cuts the pettiness.)
- Have well defined processes.
- Releasing Software
- Backport Bugs
- Test and release tarballs.
- Accepting and reviewing patches.
- Admitting new committers
- The community founders establish the culture.
- The culture becomes self selecting.
- Voting is a last resort
- A healthy community should rarely need to vote.
Communications Annoyances
- Uses silly nicknames
- Uses multiple nicknames in different media
- Overuses Capital letters.
- Uses excessive punctuation.
- Acronyms are used.
- Unable to pick up on the mood.
- Doesn't understand common goals of the community.
- Asks incessant questions.
- Insults the status-quo.
- Angrily commands help.
- Attempts to blackmail.
- Attempts to deliberately rile people .
- Makes accusations of conspiracy.
- Refuses to acknowledge the opinions of others.
- Makes sweeping claims.
- Usually about the projects future success.
- Re-opens topics that are long settled.
- Without reading the archives.
- Willing to complain but not help with anything.
- Unwilling to discuss design.
- Too insecure to take criticism.
- 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.
- give jerks purchase.
- engage them.
- get emotional
- pay attention to a newcomer.
- even if they're annoying at first.
- extract a real bug report if possible.
- know when to give up and ignore them.
- know when to forcibly boot them from community.
- Comprehend:
- Preserve attention and focus.
- Build a healthy community.
- Look for tell tale signs.
- Maintain calm and stand your ground.
Technorati Tags: Code-of-Conduct, development, software, tradition, Attention-Economy, Genesys