This document discusses common community anti-patterns, including: - Community members volunteering for tasks but providing vague progress updates and resisting task handoff. - Projects having command and control structures where all committers are from one company and there is no public roadmap. - Communities falling into mob rule without leadership or structure. - Projects becoming "black holes" where a single developer does most work without outside contributions. The document provides treatments for these anti-patterns, such as setting deadlines, making failure acceptable, establishing community governance policies, and ensuring transparency. The overall goal is to create inclusive communities where people feel safe contributing.

1. Community
Anti-patterns
Dave Neary
Neary Consulting
dave@neary-consulting.com

5. “Good artists copy, great artists steal”
Pablo Picasso

6. Cargo cults

8. Community anti-patterns:
Best Practices Run Amok

9. Cookie licker

10. Symptoms
● Community member volunteers for tasks
● Progress reports are infrequent & vague
● “I'm working on a draft”
● “It's nearly ready to go”
● When it's suggested someone takes over, the
task owner resists
● “I'll make time next week”
● “I've almost finished”

12. Causes
● Desire to have things done well
● Best community members always over-commit
● Truly believes they can make time
● Once committed, handing off task is admitting
failure

13. Treatment
● Set deadlines on tasks, and reassign when they
run over
● Make failure OK

15. Help
Vampire

16. Treatment
Good newbie docs
Encourage recent newbies to answer
newbie questions
Teach newcomers how to search for
answers

17. See also:
RTFM

18. Command and Control

19. Symptoms
● Joint Copyright Assignment
● All committers from one company
● No public roadmap, unannounced
features arrive regularly

20. Justification
● Have a company to run
● We need to own the code for our business
model
● The company paid for it, we should be
special
● Community contributions are small
anyway

21. Treatment
● Define policies for community access to project
resources
● Public roadmap process
● Exchange influence for control

22. Headless chicken

24. Bikeshed

26. Leadership

28. Mob rule

29. Beware Dunbar's Number

30. How do your community
members self-identify?

31. Culture of
Doing

32. Avoid
Smoke
Filled
Rooms

33. The
Water
Cooler

34. Fear of
community

35. Work in a glasshouse

36. Open Design
!=
Design by Committee

37. Black Hole

38. “Ironically, since I started working on
SyncEvolution full-time beginning of this
year, I seem to have *less* time left
compared to the previous years when I
did it in my spare time"
Patrick Ohly
“I'm too busy to spend time answering
questions on the mailing list”
OpenWengo developer

39. Treatment
● Ensure “doing things in the open” is part of the
job description
● Train managers & engineers in community
development
● Document who is doing what publicly – and
explicitly leave some thing on the roadmap
clearly marked “Not us”

40. Broken window

41. Symptoms
● Off-topic/bikeshed threads on mailing list
● Wiki vandalism/decreased article quality
● IRC Signal to Noise ratio decreases

42. Treatment
● Document Best Practices
● Remind offenders early
● Spread policing load around

43. Broken record

44. “I'm the bad guy??? How did that
happen? I did everything they
told me to.”
Michael Douglas, Falling Down

45. Treatment: Don't be that guy!
(A gentle reminder is usually enough)

46. Final thought:
Communities are emotional places

51. Community goal:
Create a fun, friendly environment
where people feel safe sharing

52. Thank you!
Dave Neary
dneary@gnome.org
dave@neary-consulting.com