How to Protect Your
    Open Source Project
  From Poisonous People                    0%
                                ...
By The Way
  These are our opinions
•
• There!s more than one
  way to run a community
• Based on our
  experiences...
• ....
Comprehension
  Fortification
 Identification
  Disinfection
Comprehending
  the Threat
Attention    and
     Focus
   These are your scarcest resources




You must protect them
Poisonous people can:
  Distract
•
• Emotionally drain your community
• Cause needless infighting
You Need to Avoid Paralysis
    OCD people can derail forward progress
•
    • Perfectionists
    • People obsessed with p...
Fortifying Against
   the Threat
Build a Strong Community Based On


            Politeness
             Respect
              Trust
             Humility
Best Practices
Have a Mission

  Pick a direction
•
• Limit your scope
        [Examples]
    •
Subversion

      “To create a compelling replacement for CVS”




            Google Web Toolkit
  “To radically improve ...
Mailing List Etiquette

    Don't rehash old discussions:
•
    • Send quot;em to the mail archives


    Don't reply to e...
Document Your Project!s History

  Design decisions
•
• Bug fixes
• Mistakes
• Code Changes (ChangeLog)
If you don!t document your project!s history, you
          will be condemned to repeat it...
   ...over and over and over...
Have healthy code-collaboration policies
    Send commit emails, encourage email review
•


    Do big changes on branches...
Have Well-defined Processes
    Releasing software
•
    – Backport bugfixes
    – Test and Release tarballs


    Accepting...
Voting is a last resort

    A healthy community should rarely need to vote
•
    –   [Example: Subversion!s critical deci...
Maintain Your Standards

       “I have several friends who know him to
     some degree. One of them said quot;he often
 ...
Identifying
    Poisonous People
The warning signs that you should look out for
               ...also known as...
       ...
Communication Annoyances

  Uses silly nicknames
•
• Uses multiple nicknames in different media
• Overuses CAPITAL LETTERS...
Cluelessness

  Unable to pick up on the “mood”
•
• Doesn!t understand common goals of the community.
• Asks incessant RTF...
Hostility

  Insults the status quo
•
• Angrily demands help
• Attempts to blackmail
• Attempts to deliberately rile peopl...
Conceit

    Refuses to acknowledge the opinions of others
•


    Makes sweeping claims
•
    • Usually about the project...
Non-cooperation

  Willing to complain, but not help fix anything
•
• Unwilling to discuss design
• Too insecure to take cr...
Disinfecting Your
   Community
Assess the Damage
Ask Yourself Two Critical Questions


    Is this person draining attention and focus?
•
    • If so, is the person really...
Don!t
Don!t

  Feed the energy creature! (old usenet adage)
•
• Give jerks quot;purchasequot;
• Engage them
• Get emotional
    ...
Do
Do

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


    Look for the fact under the em...
Do

    Know when to give up and ignore them
•
        [Example: different raving lunatic]
    •


    Know when to forcib...
And Finally, Do...
    Address the behavior, not the person
•
        [Example: the banished behavior]
    •
Summary
    Comprehend:
•
    • Preserve attention and focus


    Fortify:
•
    • Build a healthy community


    Identi...
Shhhhhh, Don!t Tell...
This doesn!t only apply to
open source communities.
This applies to all
  communities.
Q&A
Ben Collins-Sussman & Brian W. Fitzpatrick
          sussman@google.com
             fitz@google.com
Upcoming SlideShare
Loading in...5
×

Os Fitzpatrick Sussman

2,726

Published on

Published in: Technology

Os Fitzpatrick Sussman

  1. 1. How to Protect Your Open Source Project From Poisonous People 0% 3! th on is W oi wP os Ns e L Ben Collins-Sussman & Brian W. Fitzpatrick Google July 26, 2007
  2. 2. By The Way These are our opinions • • There!s more than one way to run a community • Based on our experiences... • ... and Karl!s book... • ...which are both based on experiences with Subversion... • ...and Apache
  3. 3. Comprehension Fortification Identification Disinfection
  4. 4. Comprehending the Threat
  5. 5. Attention and Focus These are your scarcest resources You must protect them
  6. 6. Poisonous people can: Distract • • Emotionally drain your community • Cause needless infighting
  7. 7. You Need to Avoid Paralysis OCD people can derail forward progress • • Perfectionists • People obsessed with process Even nice guys can do this unintentionally! • • quot;The perfect is the enemy of the goodquot; [Example: endless discussion] •
  8. 8. Fortifying Against the Threat
  9. 9. Build a Strong Community Based On Politeness Respect Trust Humility
  10. 10. Best Practices
  11. 11. Have a Mission Pick a direction • • Limit your scope [Examples] •
  12. 12. Subversion “To create a compelling replacement for CVS” Google Web Toolkit “To radically improve the web experience for users by enabling developers to use existing Java tools to build no- compromise AJAX for any modern browser”
  13. 13. Mailing List Etiquette Don't rehash old discussions: • • Send quot;em to the mail archives Don't reply to every message in a thread: • • Reply to a summary [Example: Email filibustering] •
  14. 14. Document Your Project!s History Design decisions • • Bug fixes • Mistakes • Code Changes (ChangeLog)
  15. 15. If you don!t document your project!s history, you will be condemned to repeat it... ...over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over again
  16. 16. Have healthy code-collaboration policies Send commit emails, encourage email review • Do big changes on branches for easier review • • “Power plants” slow progress Be generous with branches • Increase your project!s “bus-factor” on components • Don't allow names in files • [Example: the date-parser contributor] •
  17. 17. Have Well-defined Processes Releasing software • – Backport bugfixes – Test and Release tarballs Accepting and reviewing patches • Admitting new committers • – The community founders establish the culture – The culture becomes self-selecting [anecdote: even a founder can be booted!] •
  18. 18. Voting is a last resort A healthy community should rarely need to vote • – [Example: Subversion!s critical decision]
  19. 19. Maintain Your Standards “I have several friends who know him to some degree. One of them said quot;he often walks the fine line between genius and lunatic.! The problem is, genius is such a commodity these days, that it's not acceptable to be an eccentric any more.” --Greg Hudson, Subversion Developer
  20. 20. Identifying Poisonous People The warning signs that you should look out for ...also known as... When to flip the “bozo bit”
  21. 21. Communication Annoyances Uses silly nicknames • • Uses multiple nicknames in different media • Overuses CAPITAL LETTERS • Uses excessive punctuation!!!1!!1!one! • ZOMGWTFBBQ!?!?!
  22. 22. Cluelessness Unable to pick up on the “mood” • • Doesn!t understand common goals of the community. • Asks incessant RTFM questions
  23. 23. Hostility Insults the status quo • • Angrily demands help • Attempts to blackmail • Attempts to deliberately rile people • Makes accusations of conspiracy (paranoia)
  24. 24. Conceit Refuses to acknowledge the opinions of others • Makes sweeping claims • • Usually about the project's future success Re-opens topics that are long settled • • Without reading the archives
  25. 25. Non-cooperation Willing to complain, but not help fix anything • • Unwilling to discuss design • Too insecure to take criticism
  26. 26. Disinfecting Your Community
  27. 27. Assess the Damage
  28. 28. 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?
  29. 29. Don!t
  30. 30. Don!t Feed the energy creature! (old usenet adage) • • Give jerks quot;purchasequot; • Engage them • Get emotional [Example: “your OSS project sucks”] •
  31. 31. Do
  32. 32. Do 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, if possible • [Example: raving lunatic with a real bug] •
  33. 33. Do Know when to give up and ignore them • [Example: different raving lunatic] • Know when to forcibly boot them from community • [Example: statistical analysis as evidence] • Repel trolls with niceness!! • [Example: irc guy] •
  34. 34. And Finally, Do... Address the behavior, not the person • [Example: the banished behavior] •
  35. 35. Summary Comprehend: • • Preserve attention and focus Fortify: • • Build a healthy community Identify: • • Look for tell-tale signs Disinfect: • • Maintain calm and stand your ground
  36. 36. Shhhhhh, Don!t Tell...
  37. 37. This doesn!t only apply to open source communities.
  38. 38. This applies to all communities.
  39. 39. Q&A Ben Collins-Sussman & Brian W. Fitzpatrick sussman@google.com fitz@google.com

×