10 Ways to Destroy Your Community

1,386 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,386
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

10 Ways to Destroy Your Community

  1. 1. 10 Ways to Destroy Your Community A How­To Guide    Josh Berkus, Community Guy
  2. 2. Part I: The Evil of Communities   
  3. 3. They mess up your marketing plans by doing their own marketing and PR   
  4. 4. They mess up your product plans with unexpected innovation   
  5. 5. Theyre never satisfied by any amount of quality and keep wanting to improve the software   
  6. 6. They re-define your partner and customer relationships and confuse your salespeople   
  7. 7. They require you to communicate constantly and who has time for that?   
  8. 8. If Only There Were Some Way to Rid Yourself of the Community Menace ...   
  9. 9. The Berkus Patented Ten­Step Method To Destroy Your Community   
  10. 10. 1. Difficult Tools ● weird build systems ● proprietary version control systems ● limited license issue trackers ● single­platform conferencing software ● unusual & flaky CMS   
  11. 11. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length   
  12. 12. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length 2.  Denounce them venemously   
  13. 13. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length 2.  Denounce them venemously 3.  Ban them   
  14. 14. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length 2.  Denounce them venemously 3.  Ban them 4.  Argue with them in other projects/sites   
  15. 15. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length 2.  Denounce them venemously 3.  Ban them 4.  Argue with them in other projects/sites 5.  Allow them back into your project   
  16. 16. 2. Poisonous people Maximize the damage they can do! 1.  Argue with them at length 2.  Denounce them venemously 3.  Ban them 4.  Argue with them in other projects 5.  Allow them back into your project 6.  GOTO 1   
  17. 17. 3. No documentation DONT …document the code …document the build methods …document the submission process …document the release process …document how to install it   
  18. 18. 3. No documentation DONT …document the code …document the build methods …document the submission process …document the release process …document how to install it …but always tell people RTFM!   
  19. 19. 4. Closed-Door Meetings Good Short­notice online meetings   
  20. 20. 4. Closed-Door Meetings Good Short­notice online meetings Better Telephone meetings   
  21. 21. 4. Closed-Door Meetings Good Short­notice online meetings Better Telephone meetings Best Meet in person, in your secure office   
  22. 22. 5. Legalese, legalese, legalese The longer and more complex the better! Contributor agreements Website content licensing Non­disclosure agreements Trademark licensing terms Bonus: change the documents every couple of  months, without any official notice.   
  23. 23. 6. Bad liaison Someone reclusive   
  24. 24. 6. Bad liaison Someone reclusive or  Someone with no time   
  25. 25. 6. Bad liaison Someone reclusive or  Someone with no time or Someone with no authority   
  26. 26. 6. Bad liaison Someone reclusive or  Someone with no time or Someone with no authority or Someone unfamiliar with the technology   
  27. 27. 6. Bad liaison Someone reclusive or  Someone with no time or Someone with no authority or Someone unfamiliar with the technology or  No liaison at all!  
  28. 28. 7. Governance obfuscation   
  29. 29. 7. Governance obfuscation Three Principles: (1) Decision making and elections should be  extremely complex and lengthy; (2) Make it unclear what powers community  officials & committees actually have; (3) Make governance rules nearly impossible to  change.   
  30. 30. 8. Screw around with licenses License ≈ Identity   
  31. 31. 9. No outside committers I. No matter how much code outsiders write,  only employees get to be committers.   
  32. 32. 9. No outside committers I. No matter how much code outsiders write,  only employees get to be committers. II. If they ask why theyre not promoted, be  evasive!   
  33. 33. 9. No outside committers I. No matter how much code outsiders write,  only employees get to be committers. II. If they ask why theyre not promoted, be  evasive! III.Make sure there are no written rules on who  gets to be a committer, or that the the criteria  are impossible to fulfill.   
  34. 34. 9. No outside committers I. No matter how much code outsiders write,  only employees get to be committers. II. If they ask why theyre not promoted, be  evasive! III.Make sure there are no written rules on who  gets to be a committer, or that the the criteria  are impossible to fulfill. IV.Bonus: promote an employee who doesnt  code to committer!   
  35. 35.    
  36. 36. 10. Be silent   
  37. 37. The Ten Ways 1. Difficult tools 2. Encourage poisonous people 3. Dont document anything 4. Closed-door meetings 5. Lots of legalese 6. Bad liason 7. Governance obfuscation 8. Screw around with licenses 9. Stop outside committers  10. Be silent  
  38. 38. The Ten Ways 1. Familiar Tools 2. Discourage poisonous people 3. Document everything 4. Accessible online meetings 5. Minimize legalese 6. Expert liason 7. Governance simplification 8. Treat licenses with respect 9. Promote outside committers  10. Communicate  
  39. 39. More Advice ● Josh Berkus: josh.berkus@pgexperts.com ● Presentation:  www.pgexperts.com/documents.html ● Blog: it.toolbox.com/blogs/database­soup Copyright 2010 Josh Berkus, distributable under the creative commons attribution license  

×