How (Not) To Build An OSS Community

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Why Is This Hard? * Damn ﬂeshy 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

Slide 5

Slide 5 text

Let’s Start With Failures...

Slide 6

Slide 6 text

* 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...

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Case Study #1: Why did it fail?

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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/inﬂuence * POLITELY get it in front of other more prominent members

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

Case Study #2 & 3: What went better?

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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)

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Noticing Common Themes?

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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 ﬁnd 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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

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 ﬁling an issue * Steps to creating a patch/pull request * Possibly a style guide?

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Lack Of Empathy You might be the ﬁrst 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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

Conclusion

Slide 55

Slide 55 text

Conclusion Running a community is not rocket science

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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