How (Not) To Build An OSS Community by Daniel Lindsley

Transcript

1. How (Not) To Build An
   OSS Community
   * Hello
   * Enjoying PyCon? Food Coma?
   * Talk about something near & dear: community
   

   View Slide

2. Who?
   Daniel Lindsley
   Run several communities
   Haystack / Tastypie / Django Dash
   

   View Slide

3. What Are We
   Talking About?
   * Building a community takes work
   * I've done this a couple times
   * Failed at building a couple
   * Struggle with this constantly
   

   View Slide

4. Why Is This Hard?
   * Damn fleshy people!
   * So much less predictable than a computer
   * They won't necessarily do what you tell them
   * Short attention spans
   * Other competing projects
   * Limited time
   

   View Slide

5. Let’s Start
   With Failures...
   

   View Slide

6. * Time to hop into the time machine...
   * I started making OSS in college but it never went far.
   * Fresh-faced out of college & sick of all the other PHP web frameworks, I...
   

   View Slide

7. Case Study #1:
   Remarkable Framework
   * You guessed it, wrote my own
   

   View Slide

8. Case Study #1:
   Remarkable Framework
   PHP5 web framework
   * PHP 5 (when that was the new hotness)
   

   View Slide

9. Case Study #1:
   Remarkable Framework
   PHP5 web framework
   Better than the other early options
   * It was pretty good
   

   View Slide

10. Case Study #1:
    Remarkable Framework
    PHP5 web framework
    Better than the other early options
    No one ever used it
    * I built it, but no one came
    

    View Slide

11. Case Study #1:
    Why did it fail?
    

    View Slide

12. Case Study #1:
    Why did it fail?
    Limited docs
    * A tutorial by itself isn’t enough
    * JKM has lots of good thoughts on this
    

    View Slide

13. Case Study #1:
    Why did it fail?
    Limited docs
    No public VCS, just tarballs
    * Opaque development
    

    View Slide

14. Case Study #1:
    Why did it fail?
    Limited docs
    No public VCS, just tarballs
    Lack of exposure
    * This is something that only builds with time/influence
    * POLITELY get it in front of other more prominent members
    

    View Slide

15. Case Study #1:
    Why did it fail?
    Limited docs
    No public VCS, just tarballs
    Lack of exposure
    Lack of support channels
    * IRC
    * Mailing lists
    * The Twitters
    * Etc.
    

    View Slide

16. Case Study #1:
    Why did it fail?
    Limited docs
    No public VCS, just tarballs
    Lack of exposure
    Lack of support channels
    No place to report issues
    * I’d never used a real bugtracker, because LOLcollege
    * SourceForge was still hot, so you know this is antiquity
    * And it was PHP, just before Zend Framework, CakePHP & the others came out.
    

    View Slide

17. View Slide

18. Case Study #2:
    Haystack
    Django library for Search
    Decent usage
    1.1k GH stars
    140k PyPI downloads
    * Three years later, I worked on making search in Django better
    * Some things were done differently
    

    View Slide

19. Case Study #3:
    Tastypie
    Django library for RESTful APIs
    Again, decent usage
    ~1.9k GH stars
    136k PyPI downloads
    * 1.5 years later, now it was time to tackle RESTful APIs...
    * Applied the same approach, to a different outcome.
    

    View Slide

20. Case Study #2 & 3:
    What went better?
    

    View Slide

21. Case Study #2 & 3:
    What went better?
    Lots of docs
    * Tutorials, limited guides, good-ish API docs
    

    View Slide

22. Case Study #2 & 3:
    What went better?
    Lots of docs
    On GitHub within 2 weeks of initial
    commits
    * GitHub drew early adopters & made the development transparent
    * BitBucket is just as good
    

    View Slide

23. Case Study #2 & 3:
    What went better?
    Lots of docs
    On GitHub within 2 weeks of initial
    commits
    IRC + mailing list
    

    View Slide

24. Case Study #2 & 3:
    What went better?
    Lots of docs
    On GitHub within 2 weeks of initial
    commits
    IRC + mailing list
    Announced to others
    * Twitter announcements fueled a lot of initial interest
    * Other people started talking about them
    

    View Slide

25. Case Study #2 & 3:
    What went better?
    Lots of docs
    On GitHub within 2 weeks of initial
    commits
    IRC + mailing list
    Announced to others
    Had its own site/domain
    * Don’t underestimate a vanity URL
    * Promise a designer favors (or better yet, get them using your stuff so they feel obligated to
    help)
    

    View Slide

26. Case Study #2 & 3:
    What went wrong?
    * They haven’t been without their warts though
    

    View Slide

27. Case Study #2 & 3:
    What went wrong?
    Single committer
    * How scalable is a single node?
    * SPOF
    

    View Slide

28. Case Study #2 & 3:
    What went wrong?
    Single committer
    Weak release notifications
    * Didn't post updates to the site on releases
    

    View Slide

29. Case Study #2 & 3:
    What went wrong?
    Single committer
    Weak release notifications
    Some early docs issues
    * Use Read the Docs & be happier
    

    View Slide

30. Case Study #2 & 3:
    What went wrong?
    Single committer
    Weak release notifications
    Some early docs issues
    No contribution guidelines
    * Very little form to the pull requests, requiring lots of cleanup
    

    View Slide

31. Noticing Common
    Themes?
    

    View Slide

32. View Slide

33. How You Start A
    Community
    a.k.a.
    Why you came to this talk...
    

    View Slide

34. Uniting Purpose
    A fragmented community quickly tears itself apart.
    * This often falls out of the software itself, as it was built for a purpose
    * But be warned that some users will have other ideas about how to use it
    * Accommodating (most) everyone puts you in a better position
    * Fewer hostile forks
    

    View Slide

35. Focused Purpose
    Move together or be torn apart by momentum.
    * Be careful not to turn it into an end-all unless you’re sure it can be
    * Spin off advanced/specialized functionality as a plugin that builds on top
    

    View Slide

36. Documentation
    Just because you built it
    doesn’t mean they will come.
    * Except for rare situations (absolute need or so sexy!), without this, no one will use it
    * Case in point: It’s why many of you know about Flask but virtually no one knows about Itty
    * Lack of docs means most people will get frustrated & move on
    

    View Slide

37. Communication
    Will make or break you.
    * This goes along with focus
    * People want to know it’s actively developed on, what the future holds, how to get help, how
    they can help
    * IRC
    * Mailing lists
    * Website
    * Twitter
    

    View Slide

38. Feedback
    Like a guitar amp, sometimes it’s too loud.
    * Users need a forum in which they can voice their issues, their needs, where they find
    shortcomings, what they’d love to see
    * Lots of good ideas
    * Sometimes lots of bad ideas
    * Separate the wheat from the chaff, but do it NICELY
    * Ticket trackers
    * Spend time chatting with the heavy-duty users as well as the newbies
    

    View Slide

39. Show Progress
    If no one can see it, no one will use it.
    * Again, people want to see active development
    * Everyone dreads the creaky old library no one has given any love & could break at any
    moment
    * Should feel like a celebration, both for you & for the community
    

    View Slide

40. Make Contribution Easy
    It’s the only way you’ll get any contribution at all.
    * GH/BB model of fork & pull req
    * Define **how** others can contribute
    * I suck at this one
    

    View Slide

41. Listen
    Graciously accept both positive &
    negative feedback.
    * You should consider yourself a success when you acquire haters
    * Remember there are lots of happy people who are quietly using the software
    * I’m super-thin-skinned, so I struggle with this one nightly
    

    View Slide

42. View Slide

43. I did promise
    PAINFUL
    lessons learned,
    didn’t I?
    

    View Slide

44. View Slide

45. What You Absolutely,
    Positively, Should
    Never Do Under Any
    Conditions
    

    View Slide

46. Feel Obligated
    Unless they’re paying you.
    * I struggled with this, trying to provide support at all hours, even late at night
    * You burn-out very, very quickly
    * If they're not paying you, you don't owe them
    * You need to reserve time for yourself
    

    View Slide

47. Not Letting Others In
    
    * If you even start feeling like you're behind, it's time to get help
    * This isn't as easy as it sounds
    * Addressing quality/style/commit style/attribution/triage/etc.
    

    View Slide

48. Not Documenting
    Enough
    Hint: There’s never enough documentation.
    * It's not enough to just have technical documentation
    * You actually need community documentation as well
    * LICENSE, AUTHORS
    * Standards for code
    * Steps to filing an issue
    * Steps to creating a patch/pull request
    * Possibly a style guide?
    

    View Slide

49. Not Communicating
    Enough
    Consider hiring a town crier.
    * Users aren't staring at your repo all day
    * Make it easy for them to get the information they need
    * Blog posts
    * Mailing list announcements
    * Tweets
    * Et cetera
    * Responsiveness in tickets as well
    

    View Slide

50. Long Release Cycles
    I am the worst.
    * I'm so, so guilty of this.
    * Let go sooner
    * If a major bug fix lands or there's a new feature, push it out the door
    * Don't wait for something that's "big enough"
    

    View Slide

51. Lack Of Empathy
    You might be the first thing they
    stumbled on from Google.
    * Remember that they're likely not an expert
    * They likely don't know the codebase
    * Just like you, they probably just want things to work so they can get on with their day
    

    View Slide

52. Not Listening
    Set aside your ego & open your mind.
    * Sometimes the community is right
    * Listen to their concerns
    * Be open to new ideas
    

    View Slide

53. View Slide

54. Conclusion
    

    View Slide

55. Conclusion
    Running a community is not rocket
    science
    

    View Slide

56. Conclusion
    Running a community is not rocket
    science
    ...but it is a lot of social science
    

    View Slide

57. Conclusion
    Running a community is not rocket
    science
    ...but it is a lot of social science
    Be understanding
    

    View Slide

58. Conclusion
    Running a community is not rocket
    science
    ...but it is a lot of social science
    Be understanding
    Provide a venue
    

    View Slide

59. Conclusion
    Running a community is not rocket
    science
    ...but it is a lot of social science
    Be understanding
    Provide a venue
    Be passionate
    

    View Slide

60. And win!
    

    View Slide

61. Thanks.
    Questions?
    @daniellindsley
    https://github.com/toastdriven
    

    View Slide