The Open Source Contributor Funnel

28 June 2016

Learn how to encourage and increase participation in your open-source project.

Presented at CodeConf in 2016.

Written up as a blog post: The Open Source Contributor Funnel (or: Why People Don’t Contribute To Your Open Source Project).

Show transcript

0:00 SPEAKER 1:
0:07 Right.
0:08 Thank you, everyone, for coming.
0:09 And I'm going to walk a little bit through today
0:12 some stuff that I've learned through maintaining Homebrew.
0:15 And hopefully it's useful to all of you.
0:17 But if it's not, just shout at me on Twitter,
0:19 because I'm not on the Wi-Fi anyway,
0:21 so I won't know until afterwards.
0:24 Right.
0:25 I have-- this is not the one that is mine.
0:29 Right, sorry, there we go.
0:31 So I'm wearing kind of two hats whenever
0:34 I am involved with GitHub stuff.
0:36 My first hat, which is my older hat, which
0:38 is me being a maintainer of Homebrew.
0:40 I started working on Homebrew in about 2009.
0:43 I'm still working on it today.
0:45 So I think I'm the oldest running maintainer still on the project.
0:49 How many people in here have heard of Homebrew?
0:52 OK, most people.
0:54 How many people use it?
0:56 OK, a reasonable number of people.
0:57 How many people have submitted a pull request to Homebrew?
1:00 How many people of them did I actually accept your pull request?
1:03 Rather than-- I mean, OK.
1:07 People who I didn't accept your pull request,
1:09 please don't talk to me afterwards.
1:11 Because I won't make eye contact, because that's always awkward.
1:14 Right.
1:16 So I'm also working GitHub.
1:17 And how many people have heard of GitHub here?
1:20 And not everyone here who works at GitHub had their hand up there.
1:23 So that's a little bit worrying.
1:26 But hopefully you can help them learn what they're
1:28 meant to be working on during this conference.
1:31 So what I'm going to talk to you about today
1:34 is a thing that I kind of came up with that's called, like,
1:37 the contributor funnel.
1:38 I kind of mentioned it as an offhand remark at a previous conference.
1:44 And people seemed to think it was interesting.
1:46 So then I made, like, a talk out of it.
1:49 So it's basically these kind of four main things that I'm going to kind
1:54 of walk through in this talk.
1:55 So the first is about kind of grouping your users
1:59 into kind of categories so you can kind of think about them
2:02 in different ways because not everyone
2:05 who uses your project and not everyone
2:06 you interact with in your project is going to be the same
2:09 and have the same desires and needs and whatever.
2:12 The next is, like, the funnel, the contributor funnel thing,
2:15 in which all the kind of salespeople will, like, cringe
2:18 as I, like, horribly butcher sales metaphors.
2:21 Then, like, upselling, which, again, is also a sales metaphor
2:24 that I don't really understand but I'm going to use anyway.
2:27 And then finally, like, retaining people because I
2:30 I think something that doesn't always get talked about
2:32 with open source community things is how
2:35 to make sure your project doesn't die.
2:37 It's, like, surprisingly easy to have successful projects
2:41 and do one or two relatively simple things which
2:44 can cause big problems.
2:46 So hopefully we'll kind of work through this together.
2:48 So the first one, grouping your users together.
2:52 So I'm going to split people into three camps.
2:55 Obviously, these are overly broad, but for the sake
2:59 of me being on the stage, let's assume they're correct.
3:03 The first one is kind of users.
3:04 So this kind of--
3:06 by this, I'm assuming we're talking about people
3:09 who are just users and not people who are users and maintainers
3:14 like me as well, for example.
3:16 These people are people who maybe, like, if you're lucky,
3:20 kind of file issues on your project, maybe talk
3:23 on your mailing list, whatever.
3:24 But the vast majority of them are going to be people
3:26 who have no interaction with you.
3:28 They do not have a GitHub account.
3:29 They do not have, you know, maybe even a comprehension of who
3:33 makes this project and why and whatever.
3:36 The next group of people are contributors.
3:39 So these are people who have, at some point,
3:42 interacted with your project.
3:43 Some people would say people who file issues are kind of
3:46 I would personally say people who file, like, really good,
3:50 detailed issues are kind of contributors.
3:51 Someone who just says, like, everything's broken.
3:53 I don't know what to do.
3:54 It's more in the kind of user camp than the contributor camp.
3:58 And these are, like, to use, I guess, on GitHub.
4:01 Like, these are people who may submit pull requests to your
4:03 project, but they don't actually have committed access to your
4:06 project.
4:07 And then finally, on Homebrew, what we call, at least,
4:09 maintainers.
4:10 So these are the people who do have committed access to your
4:12 They're the people who interact with your community, who
4:15 review and merge external contributors' work, and
4:19 generally are kind of both the gatekeepers and the people who
4:22 are probably setting the direction of the process-- of
4:25 their project more than anyone else.
4:27 Even that may be because they decide on what goes into a
4:31 roadmap, or it may just be that they're the people doing the
4:33 bulk of the work, and what they work on gets implemented in
4:37 the stuff that they don't work on doesn't.
4:39 So the next thing is the funnel.
4:42 So there's my understanding of sales, which is very limited.
4:48 I once-- my only real sales experience is I once had to do a
4:52 sales visit when the person in sales at a previous company was
4:56 ill, and it was in Germany, and all the paperwork was in
4:59 German, and I don't speak any German.
5:01 So that was not a good start to my sales experience.
5:05 This is probably not a good analogy either.
5:08 But my understanding of what a sales funnel is, is that you
5:12 have-- you, again, group people into kind of categories by how
5:18 far they are through the process.
5:19 So at the top, you have kind of leads.
5:22 And this is people who you think they could be kind of
5:26 interested in buying your product.
5:28 But you've maybe not had any interaction with them yet.
5:31 You've maybe not, like, actually solicited any opinions from
5:33 them or whatever.
5:34 The next are kind of prospects.
5:35 Again, I may not understand this properly, but my understanding is
5:39 that these are people who you've had some sort of interaction, and
5:42 they've expressed some sort of interest, but they haven't given
5:44 you their credit card yet.
5:45 And then at the bottom, you have sales, which is when things have
5:49 actually gone through, and they're people who have given you some
5:52 money, and the transaction is completed in some way.
5:55 So I kind of think about this in the same way with these three
5:58 groups we had before.
5:59 So in any project, you're going to have a lot more users than you're
6:05 going to have contributors, and you're going to have a lot more
6:06 contributors, probably, than you have maintainers.
6:09 When you start a project yourself, you may have one of these three
6:13 groups, and that one person may be you, or at least, you know,
6:16 someone who's a user and a maintainer.
6:18 Hopefully, as projects grow, you're going to have more and more users
6:21 that come along.
6:22 And what I see projects struggling with sometimes is how to kind of,
6:27 as your number of users grows, and maybe your number of contributors
6:30 grows, and maybe your number of maintainers grows, how do you keep
6:33 kind of feeding into that pipeline?
6:35 What are the things that successful projects do to get people from one
6:39 stage to the other?
6:40 So some kind of homebrew numbers on these.
6:43 So homebrew has, according to Google Analytics, about a million people.
6:47 I'm going to say about 500,000 users that we think are kind of somewhat
6:52 active in a given month.
6:53 In homebrew's history, we have about 5,000 contributors.
7:00 We have probably 5,500, 6,000, but I'm going to assume that a certain
7:04 number of them are, you know, duplicate emails or whatever.
7:07 And we have, at the moment, about 10 active homebrew maintainers,
7:11 and like 20 people who have been maintainers in the total,
7:13 so in the kind of lifetime of the project.
7:16 So that puts the number of contributors at like 1% of the users,
7:21 the maintainers at 0.002%, if my math is correct, which is probably not, of the total
7:28 number of users on the project.
7:29 So that's like a really dramatic funnel.
7:32 I think if you were in sales and you were dealing with something like those type of
7:36 numbers, you would probably be not doing a very good job.
7:39 But I think we are, we consider ourselves at least like relatively successful with this.
7:45 And one of the things that I think kind of contributes to us having such a decent number of at least
7:50 contributors is what we do to try and like upsell people.
7:55 So again, another sales term I don't really understand, but this is what I'm going to call when we kind of
8:02 push someone who maybe doesn't want to between one of these levels here.
8:06 So our first kind of upselling thing that we try and do is if we get like a random Twitter mention,
8:13 then trying to kind of, because people don't necessarily have a GitHub account, people don't
8:17 necessarily aren't familiar with, you know, the kind of open source software way of like soliciting
8:23 issue reports.
8:24 So you might just get a random person who kind of complains on Twitter or asks a question.
8:28 And then we try and kind of push them to like a little guide to say like, okay, here's how
8:33 you can open an issue that is going to be useful to us.
8:37 Another one is trying to like upsell like bad issues into good ones.
8:41 Like I have a bunch of text expander macros that I use that kind of expand the text out for
8:45 me.
8:46 So I can kind of quickly say things like this that I say again and again to try and tell
8:50 people, for example, you know, it's common to have an issue where someone will say everything
8:56 is broken and they don't really provide much in the way more detail than that.
9:01 So what I try and do is this is like my little step-by-step guide that I very occasionally use
9:07 on coworkers if I'm feeling particularly rude to try and like tease like a good issue report
9:14 out of people and just try and like this is the information that probably anyone needs to
9:18 actually be able to solve an issue or at least be able to kind of triage in a sensible way.
9:24 So after that, if you have someone who's filed like a relatively good issue report and you
9:29 know, they seem like they're kind of relatively savvy and or just very motivated or it's a
9:35 problem that's very, very niche and just affects them, they obviously care about it a lot but
9:39 like no one else really does, then we try and like push them towards making a pull request.
9:44 Again, that's another little text expander macro I use when I see these type of issues that come
9:50 into the repository or I see kind of people commenting in a certain way or whatever.
9:54 And we've got this nice little document.
9:56 This is kind of a subset of it that kind of tries to walk people through step-by-step of
10:01 how to submit a pull request to Homebrew that's actually going to get merged.
10:05 So I would say a certain amount of this, like GitHub, it should be making it easier to do
10:10 these things ourselves and we do recognize that but I think it's definitely worth documenting
10:14 your project and not assuming necessarily that people know how to use GitHub, not assuming they
10:19 know how to use Git, not assuming really anything or kind of programming knowledge or whatever and
10:24 just trying to make it as easy to have a step-by-step guide for people as you can.
10:30 Because ultimately, if someone knows all these things already, they either won't read the
10:33 document or they can kind of skim through it really, really quickly.
10:36 Whereas if someone does have no experience with this stuff, then having a document like
10:40 this can help, you know, get in their first pull request.
10:44 And we tend to see reasonable amount of uptake for this.
10:48 You know, at least, I would say, maybe 50% of the time we kind of post something like this
10:52 and ask people to try.
10:54 People will at least kind of try or at least sort of attempt to kind of get there to a pull request.
10:58 And then the beauty of pull requests is that if they have like anything that they can open
11:02 a pull request for, then we can have that iteration such that we can get it to a point where it's
11:06 really good.
11:07 And hopefully they can learn something and we can kind of help them in doing so.
11:11 So another one we do as well, which is kind of hard to upsell, is trying to upsell our contributors
11:17 into maintainers.
11:18 So again, on this we have a nice little-- we try to open source all our kind of docs for this
11:23 stuff.
11:24 And we have our nice little checklist of how we go about doing that process.
11:28 If we see someone who's kind of contributing regularly, kind of high-quality contributions
11:32 and more than one person notices, then we kind of chat amongst ourselves as maintainers.
11:36 We have like a private Slack room for this type of thing.
11:39 And then we go and kind of send them an email and walk through like the kind of checklist with
11:44 them of everything they should do when they join the project.
11:46 And it's kind of nice because I'm a big fan of these type of documents and making them
11:50 open because it means that when I forget to add them to a particular system, then they can
11:56 then go and open a PR themselves to go and make sure that the next person who gets added to the
12:00 project gets added to the right systems and whatever.
12:04 And I guess the last point which bears sort of dwelling on a little bit is that I think it's really
12:12 important to think about the ways these different groups of people are positively or negatively
12:19 impacted by changes on the project.
12:22 So like always be thinking about these changes you're making and the kind of organizational structure
12:28 you have as a project as how it's going to repel or attract people who are either maintainers,
12:34 people who are contributors, or people who are users.
12:36 So starting off with the users, the thing I think is the most important thing for any software
12:43 project really is users care about the project working.
12:48 It sounds like a fairly stupid thing to say, but it's surprising how many projects will do
12:53 some big architectural rewrite or some big thing that they feel is really useful for them
12:58 from a technical perspective perhaps or an organizational perspective, but actually demonstrably makes
13:02 the software worse for the people who actually use it.
13:05 And this is problematic because for obvious reasons those organizational changes, those
13:12 developmental changes aren't actually in themselves making anything better for the users.
13:17 They may in the longer term make it easier for you to ship features or whatever, but if
13:20 you're like breaking their stuff and they just want to be able to use the software, then all
13:25 of a sudden your users go and find some other piece of software to use.
13:28 Or if they're more technical, go and start a replacement to your software that actually is high quality.
13:34 The second point here -- I've wrote a pull request about this -- sorry, I wrote a blog post about this,
13:39 I haven't got a blog before, and it's trying to make the point that something I struggled with particularly
13:45 in the early days of Home Room is that the side effect of trying to upsell people and getting people
13:50 who maybe don't have a super technical background to try and create pull requests is that sometimes you're going to work and work and work and work and get to a point where you realize there's actually no way with this person we're going to get a pull request that's hired on.
13:55 And in the early days for some of the stuff I would go and end up merging some of the stuff anyway because I felt so bad after having this person put in so much time, having me put in so much time, so bad to not have anything to show for it in the project itself.
14:08 So I would merge this stuff and then like in the long term it produces all these type of issues.
14:13 So I think it's really important to never be kind of nudged into merging things out of guilt and sometimes as well, like people can get mouthy on pull requests and people can, you know, say it's like outrageous that this didn't get merged or whatever.
14:26 And like you need to kind of be able to hopefully tell people that that's not acceptable to kind of shout at you like that, but also like trying to deal with that in a way that you can think about the wider user base and not just the individual who is currently upset that they're working on.
14:43 And the first one that's the final one, sorry, that's maybe a little bit contentious is in Homebrew at least we've taken this ethos of no 2.0 we had a document.
15:04 I'm sure a lot of projects have this and we have a lot of documents like that inside GitHub as well, these kind of dream documents that, you know, when we get to go and do it all again and rewrite this all from scratch, here's all the perfect, amazing things we're going to do that will make everything magically better.
15:24 And this kind of tracks back to the first point again, if you do like a 2.0, you know, rewrite everything from scratch type approach to a project, chances are you're just going to introduce like a huge number of bugs, a huge number of regressions and drop a bunch of features that people care about.
15:41 And at the end of the day, people are going to look at your clean, wonderful code that does 10% of what it did before and they're going to think that it's crap.
15:48 So I would encourage you to really think before you kind of throw everything away and start again, because at that point you're creating a new project, you're barely the same project anymore.
15:58 And skipping onto contributors, I think the thing that help contributors want to stay around and help keep a healthy community are not having too much bike shedding.
16:10 I assume most people are familiar with the term bike shedding, but basically it's this idea that if you want to, you know, ask people really technical questions and really complex, like architectural issues, then you won't get a lot of responses.
16:23 If you ask someone what color the bike shed should be, like everyone can chip in because the barrier to entry on that discussion is so low.
16:29 So like trying to keep kind of conversations fairly focused and trying to not solicit 8 million opinions on anything where people can chip in, I think is it helps your project become a bit more focused and helps contributors stay motivated.
16:46 And similarly, having somewhere that people can have these conversations as viable, like often that's a mailing list or IRC channel where people can kind of have discussions about maybe more abstract, higher level things that don't involve code or a specific issue.
16:58 And something we do in Homebrew, which is, again, a little bit contentious, is we don't really accept feature requests.
17:05 The reason for this being, as I mentioned before, you have maintainers who are the people who end up doing the bulk of the work.
17:11 And unless a maintainer is actively working on your feature and none of the Homebrew maintainers are paid to work on Homebrew, unless one of them is passionate enough to build it or an external contributor is passionate enough to build it, chances are this isn't going to get built.
17:23 So there's no point having some issue that sits open for three or four years as a feature request that never actually gets built.
17:30 You're better to close out. And often that can be something that motivates people to go and then build it themselves and introduce that into the product.
17:36 And the final group of people, maintainers, as been mentioned already in talks, so I won't go over it in too much detail.
17:42 I think code of conduct is super important. I think it holds maintainers accountable within themselves and also the wider community accountable to just be polite in their way that they interact with each other and trying to be kind and friendly.
17:56 And in my experience, 95% of the time, if you call someone out and say, "Hey, this is not appropriate according to our code of conduct," they'll just apologize immediately.
18:06 And the other percent of the time, they might quibble a little bit and 0.1% of the time, they get very overexcited and start shouting at you on Twitter or whatever.
18:14 In which case, it's, you know, I feel like those people were time bombs anyway, so it's better to just get them out of your project.
18:21 Another one we found really useful is private chat for discussing if we're going to have new maintainers, discussing kind of organizational things in the project.
18:29 And you don't have that sense that like 5,000 people are watching every word that you're saying, so that kind of closeness is a little bit more helpful.
18:36 And it's nice as well, if you're kind of resolving interpersonal conflicts between maintainers, to have that privacy to be able to do that.
18:42 And the last thing, which I guess is the whole thing that this whole talk is about, is trying to have your project be always growing.
18:49 That the thing that really gets maintainers down and helps burn people out more than anything else, I think, is the sense that they can't go on vacation, they can't leave the project for six months or whatever, because if they do, the project will die.
19:01 And always trying to make sure, no matter what stage your project's at, that you're getting more and more people contributing, more and more people maintaining, and just trying to like build that up, is I think the safest thing long term for your project success, to ensure that your project will not die if one person decides they need a break right now.
19:20 And giving people space to have breaks is a good thing to do.
19:24 So, I walked through these kind of four things briefly, like, remember, you want to group your users into the categories, maybe my categories are not the ones you want to do, but it's still a good way to segment people to think about things.
19:37 Think about how you can funnel people from the top to the bottom by kind of upselling them, maybe with little kind of templates to kind of push them in the right way, and lots of docs and stuff like that.
19:45 And then finally, think about when you have people who have moved from being a user to a contributor, or a contributor to being a maintainer, how you can keep them where they're meant to be, and like, helpfully contributing to your project nicely, and enjoying working with you, and you enjoying working with them.
20:01 So, that's the gist of what I wanted to tell you, and we're not doing questions right now, but you can, if you want to talk about managing a healthy GitHub community, or this contributor funnel stuff, or anything related to Homebrew, then find me afterwards, I'll be around, or on Twitter, or send me an email, or whatever.
20:19 So, thanks very much.

Mike McQuaid

The Open Source Contributor Funnel