Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How (Not) To Build An OSS Community

How (Not) To Build An OSS Community

PyCon 2013 - A rough & tumble guide, based on the pains of experience, of what to do/not do when trying to build an OSS community.

daniellindsley

March 16, 2013
Tweet

More Decks by daniellindsley

Other Decks in Technology

Transcript

  1. How (Not) To Build An OSS Community * Hello *

    Enjoying PyCon? Food Coma? * Talk about something near & dear: community
  2. 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
  3. 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
  4. * 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...
  5. Case Study #1: Remarkable Framework PHP5 web framework Better than

    the other early options * It was pretty good
  6. 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
  7. Case Study #1: Why did it fail? Limited docs *

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

    public VCS, just tarballs * Opaque development
  9. 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
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. Case Study #2 & 3: What went better? Lots of

    docs * Tutorials, limited guides, good-ish API docs
  15. 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
  16. Case Study #2 & 3: What went better? Lots of

    docs On GitHub within 2 weeks of initial commits IRC + mailing list
  17. 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
  18. 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)
  19. Case Study #2 & 3: What went wrong? * They

    haven’t been without their warts though
  20. Case Study #2 & 3: What went wrong? Single committer

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

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

    Weak release notifications Some early docs issues * Use Read the Docs & be happier
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. Not Letting Others In <Insert Gollum Quote Here> * 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.
  34. 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?
  35. 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
  36. 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"
  37. 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
  38. Not Listening Set aside your ego & open your mind.

    * Sometimes the community is right * Listen to their concerns * Be open to new ideas
  39. Conclusion Running a community is not rocket science ...but it

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

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

    is a lot of social science Be understanding Provide a venue Be passionate