On Mon, Mar 22, 2010 at 09:59:06AM -0400, Zachary Uram wrote: > Listened to a presentation on ways to destroy open source communities > and I think some of the points would benefit netrek. If anybody else would like to catch this session from LCA 2010, here's the link to the conference audio and video ... http://www.r2.co.nz/20100118/ ... and to the main auditorium session ... http://2009.r2.co.nz/20100118/mfc-m-2.htm > (whining) We get a fair bit of that. ENOPATCH. > 1. difficult tools - > * obscure build systems > * limited license issue trackers What, like Launchpad? That's one reason I'm using ditz. Launchpad is okay if you've got low latency. > 2. poisonous people who turn community against itself with > * a few ppl who are there just to give you a hard time Clue. > * 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... Heh. > 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 We're trying to do documentation, but only when it is clearly needed. > 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 Or have no meetings. At all. Ever. > 5. legalese - the longer and more complex the better! > * change it every few months We're not guilty on that one, although the Trouble with RSA was a community killer for a while. > 6. bad liaison - who is the public face of your community > * someone reclusive Me! > * find a developer with no friends who hates people Me! > * or find the busiest developer and make them the community liaison Oh, me! > * have no liaison at all but keep an email account active We're not guilty. Or are we; cow at netrek.org goes where? > 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 We nearly achieved this with the NIT. > * 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 Heh. > 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 Not guilty. The license is adequate for forking. > 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 Not guilty. We're using a distributed repository model, and the master tends to take everything as long as it doesn't break something. > 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 We're fairly good at these. > Two main types of poisonous people: > * trolls looking for attention > * people interested in an issue tangential to your project We sometimes hear from people who might meet those definitions. -- James Cameron http://quozl.linux.org.au/