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
2. Who? Daniel Lindsley Run several communities Haystack / Tastypie / Django Dash
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
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
5. Let’s Start With Failures...
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...
7. Case Study #1: Remarkable Framework * You guessed it, wrote my own
8. Case Study #1: Remarkable Framework PHP5 web framework * PHP 5 (when that was the new hotness)
9. Case Study #1: Remarkable Framework PHP5 web framework Better than the other early options * It was pretty good
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
11. Case Study #1: Why did it fail?
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
13. Case Study #1: Why did it fail? Limited docs No public VCS, just tarballs * Opaque development
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
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.
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.
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
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.
20. Case Study #2 & 3: What went better?
21. Case Study #2 & 3: What went better? Lots of docs * Tutorials, limited guides, good-ish API docs
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
23. Case Study #2 & 3: What went better? Lots of docs On GitHub within 2 weeks of initial commits IRC + mailing list
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
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)
26. Case Study #2 & 3: What went wrong? * They haven’t been without their warts though
27. Case Study #2 & 3: What went wrong? Single committer * How scalable is a single node? * SPOF
28. Case Study #2 & 3: What went wrong? Single committer Weak release notifications * Didn't post updates to the site on releases
29. Case Study #2 & 3: What went wrong? Single committer Weak release notifications Some early docs issues * Use Read the Docs & be happier
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
31. Noticing Common Themes?
33. How You Start A Community a.k.a. Why you came to this talk...
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
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
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
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
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
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
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
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
43. I did promise PAINFUL lessons learned, didn’t I?
45. What You Absolutely, Positively, Should Never Do Under Any Conditions
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
47. 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.
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?
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
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"
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
52. Not Listening Set aside your ego & open your mind. * Sometimes the community is right * Listen to their concerns * Be open to new ideas
54. Conclusion
55. Conclusion Running a community is not rocket science
56. Conclusion Running a community is not rocket science ...but it is a lot of social science
57. Conclusion Running a community is not rocket science ...but it is a lot of social science Be understanding
58. Conclusion Running a community is not rocket science ...but it is a lot of social science Be understanding Provide a venue
59. Conclusion Running a community is not rocket science ...but it is a lot of social science Be understanding Provide a venue Be passionate
60. And win!
61. Thanks. Questions? @daniellindsley https://github.com/toastdriven