Listened to a presentation on ways to destroy open source communities
and I think some of the points would benefit netrek. Here are my
notes. Reactions, thoughts? How can we go forward with building up the
netrek dev community?

Zach

Ten Ways to Destroy Your Community
by Josh Berkus

talk given at LCA2010

These are so powerful that any 3 should kill most development communities.

(whining)

1. difficult tools -
*  obscure build systems
*  limited license issue trackers

( setup official website -
  have it be down as often as it is up)

2. poisonous people who turn community against itself with
*  a few ppl who are there just to give you a hard time
*  considered primary cost of managing open source
*  a single poisonous person can wipe out a user community of hundreds
*  argue with them on public forums
*  launch into polemics
*  then ban them from the community by fiat
*  argue with them in other forums
*  after people step up and say "this is wrong" - allow them back on
the project and repeat...

3. prevent documentation
*  no code documentation
*  no user documentation
*  no project documentation
*  no contributor documentation
*  no site or release documentation
*  make sure no useful docs at all
*  if anyone asks for help ask them to reading the f**king manual.
*  if you must have documents give them a restrictive proprietary license

4. make your contributors feel excluded
*  don't let your contributors into the decision making process of the project
*  make sure the poisonous people attend the meetings
*  short notice online meetings

5. legalese - the longer and more complex the better!
*  change it every few months

6. bad liaison - who is the public face of your community
*  someone reclusive
*  find a developer with no friends who hates people
*  or find the busiest developer and make them the community liaison
*  have no liaison at all but keep an email account active

7. governance obfuscation
*  have governance so complicated that contributors can't figure out
how to participate
   3 principles:
    * decision making and elections should be extremely complex and lengthy
    * make it unclear what powers community officials and committees
actually have
    * make governance rules nearly impossible to change
*  have a community council and then don't give them any real power
   great way to create poisonous people
*  no decisions can be made without a super majority

8. screw around with licenses (psychological technique)
*  license ~= identity
*  keep changing the license of your project (GPL to BSD etc.)
*  don't make it easy for someone to fork the project on their own
*  spend a lot of time talking about changing the license without changing it

9. no outside committers
*  no matter how much code outsiders write *only* employees get to be committers
*  protect your core group of contributors
*  have no written rules on why or how someone gets to be a contributor

10. do nothing, be silent
*  this technique is the most powerful and effective and the easiest
*  don't answer questions
*  ignore emails
*  setup a separate email account/mailing list for feedback and ignore it

When I was at Sun we employed all of these techniques successfully.

Every community person you turn away now will save you that much work later.

Best ways to deal with poisonous people:
* Have a lot of documented processes and structure that is fair and accessible.
  Poisonous people will try to portray themselves as a victim to garner support.
* Have a community process for throwing someone off the project - a
community council
  that votes etc.

If people are not contributing on the community forums they do not
have the right
to speak. You must kick them out. Otherwise you have 1 person who is not doing
anything to contribute that is sucking up 20% of the communities online time.

Do not give trolls a voice.

Two main types of poisonous people:
* trolls looking for attention
* people interested in an issue tangential to your project

Don't give them a soapbox.

Losing community happens in days or weeks. Regaining community happens
over years.

Better to under promise and over deliver than vice versa.



<>< http://www.fidei.org ><>