 Thanks everyone. Just to start with I'm coming at this talk with two different hats on so I am the lead maintainer of Homebrew a Mac package manager anyone used homebrew ever cool. Thank you very much I So I didn't want to make a PR to homebrew ever by any chance whoo well done you thank you very much And I can confirm at least several of those people were not lying. I recognize their faces How many people have opened an issue on homebrew only to have me immediately close it and probably be rude at you? My mistake because I'm busy. Yep. Sorry. I'm sorry So if you want help submitting a PR to homebrew ever then get in touch with me And I will try and help you as best I can my other hat that I wear is github who has heard of github Cool So I don't think everyone who works at github in this room put their hand up Which is a little bit worrying I've been a gal for about four and a bit years and I'm trying to make it better for open-source software and better in General so if you would like to talk to me about making github better then get in touch as long as you are gonna be nice about it anyway, so I Told the title here why people don't contribute to your open source project. I'm gonna come at this from perhaps a funny angle What I'm talking to you Mainly is open source projects that have these things met already So your open source project is already open sourced Please if you're one of those companies who's like why is my open source project successful I'm planning on open sourcing in three months then don't come to speak to me. I Hope that you already have some users of your project. I you're building something useful, which is useful to more than just you and more than just your organization But you maybe don't have as many people contributing or as many people maintaining your project as you would like so You may ask yourself. Why is no one contributing to my project? But I would like to pivot this and think about a slightly different question so if you're a company and you're making stuff for money then if you're not making as much money as you would like then you Might ask yourself. Why is no one buying my project? Product even well, so we're gonna ignore the fact We're gonna pretend that your product is not terrible and instead Let's go and think about your product in the same way as we might think about the open source project before so I would argue that the it's open source that has users but not contributors and maintainers is not Terribly dissimilar to the idea that your project is created You have a decent product already. You have a bunch of people using it already But you've not actually tried to sell it to anyone and as a result not enough people are buying it So let's think about this Through the rest of this talk through four different ways of thinking about this, right? So we're gonna talk about grouping the people who are using your project already into different categories We're gonna talk about a funnel with a terrible metaphor, which I like We're gonna talk about upselling people through the funnel, which is actually going down through the funnel because I haven't really thought this through And how to retain the people who you have put either up or down through the funnel depending on which bit the talk you remember Right so grouping your users So firstly why are people interacting with your project at all? So I'm gonna say there's three different reasons basically or three different groups that people interact with any open source project We're assuming when I say interaction here that this is interacting primarily online primarily with Say a GitHub repo if that's the primary face of your open source project So you've got the users. These are the people who are using the software. They may be file issues They maybe don't we're assuming for this case. They don't write the code. They don't write docs They're not triaging issues for your particular project. They may you do it for other projects But your project is going to have hopefully at least one of these which is the person who wrote the software I you if you don't use the software you wrote then you perhaps have some bigger problems So the next group is your contributors So these I'm going to say again my definition may vary from other people's but my definition is these are people who have written code or docs or triage on your project and They need some sort of help from other people with getting their work included so If we're talking about a github repository here, these are people who maybe are helpful in your community They may be submit PRs, but they don't have direct commit access to make the changes They want to the project directly and then finally you have maintainers These are the people who review the incoming changes that are coming in they review issues that are coming in and They merge the work of contributors and if they're feeling kind They may be help users once in a while with the issues that they're having So again, you're going to have at least one of these if you start a project by yourself on github or any other similar platform Then the first person who started the project the first user perhaps as well is going to be the first maintainer So let's have a think about how you might put these three groups through a funnel, right? So firstly I'm going to make a couple of perhaps bold statements So I would say no one became a contributor without being a user first So this is something that maybe isn't always the case in open source But I would argue for healthy projects the best way of attracting and retaining contributors is Getting the people who are already using your software to get involved I realized this perhaps a growing movement of people who think it's a good thing to just get up here on an open source project for the sake of it who might go along and try and contribute to a project because they think it will look good on their resume or Whatever, I would argue that that person is Although they are a good intention They are probably not really helping either the project or themselves as much as they could be the best way I think you can get involved is getting involved with a project where you are helping both the project and yourself through your contribution Secondly, no one ever became a maintainer without being a user Even more so how can you merge PRs from other people? How can you support a project if you have at no time used that project? But really what this ends up being often is No one excels as a maintainer without remaining a user And I think this is an important part to think about when you're thinking about why you need new contributors on a project at all Because maintainers in a project are generally temporary if you wrote some piece of software Chances are you're not going to be using that on a day-to-day basis in five or ten years other people may be But you're not likely to be doing so anymore So as a result at some point there's going to be a time where it probably makes sense for you to hand off that project to other people But you need to make sure that when that time comes you actually have other people you can hand off to Because otherwise you're going to have a project which just dies when you stop being involved So let's go back to this really awkward metaphor I was talking about before about thinking about a product instead of an open-source project so In a sales funnel, I believe I haven't really done anything in sales ever other than this one time So this may be completely wrong, but please don't correct me because that would just be mean This is my understanding of a sales funnel So you have leads who are the people who may be interested in buying the product in buying your product You have prospects who are people who are interested in buying your product But have not yet bought it and then you have sales who are people who have actually handed you over some money and In exchange you have provided your product to them So I would argue is a sort of similar tenuous Similarity with those three groups I was talking about before you have your users You have your contributors and your maintainers so we have similar levels of involvement here You have people who are perhaps Potentially interested in getting involved you have people who have expressed interest in getting involved But haven't fully committed to maybe being a maintainer yet and then you have the people who are really really helping you run things so People wonder often in open source projects. They say well I've got a bunch of users But no one's really contributing or I've got a bunch of contributors, but no one wants to become a maintainer So I thought the numbers for homebrew may be kind of helpful So homebrew has according to Google analytics about four million users I reckon it's more like about a million monthly kind of users based on our analytics we have 6000 maybe seven thousand ish homebrew contributors That's point zero five percent of our user base and then of them we have I Don't know what the current number is today, but sort of 12 13 14 homebrew maintainers Which is point zero zero one five percent of our user base And that we have probably about 25 people who have ever been a maintainer on homebrew in the nine-year life of the project So that's a pretty dramatic funnel and hopefully again if you work in an open source project Hopefully you will have better numbers than we do but still that shows The levels you can perhaps expect you can't expect every user is going to be a Contributor to your project and you can't expect every contributor is going to be want to be a maintainer But what you can do is do your best to upsell to make sure that as many people as possible We'll pass through those groups so Something the I've experienced in open source is that most maintainers are not going me me please please I want to be the maintainer most maintainers are the people involved in a project who are being really really helpful and Then when you ask them to consider being a maintainer they Most of the talented maintainers I know say no at least once when they're first asked because they think no no no I'm not qualified to do this I've just submitted a few good PRs and that doesn't make me qualified to do this and I Can't help you because I I don't know everything that there is to know about this stuff Whereas the people who really really really want to be a maintainer. It's normally some sort of power a thing or other Potential psychology that I'm not going to do today So most of these folks need to be encouraged and they need to be invited to get involved with the project And that applies with contributors and that applies with users who you want to start getting towards this as well So let's look at some like upsell through screenshots here Right, so this is an example of us trying to upsell someone on Twitter So they submitted and I don't I probably should have blanked out their name So to be clear, this is not someone who I think is doing anything wrong But this is for example the type of issue that you might get where if you're not a very active software developer Or if you're not familiar with the project you're submitting the issue to it's not clear why it's not terribly helpful so what we've tried to say to them is Okay, here's somewhere you can go and we link them to the issue template there so they can go and see Okay, here's the type of things that we want when you're submitting a new issue So we're trying to upsell that person from basically just a tweet saying help me to an issue That will give us the information that we need for them to help us and hopefully that means again the next time They will jump straight to the next step because they say okay I know what is required in order for me to be helped So I'm going to follow these steps in advance and actually fun fact on our issue tracker If you follow the steps required to fix an issue so I to report an issue well often for us You will figure out what the problem is through doing so and then be able to help yourself Which is tremendously empowering So the next step is similarly on someone's issue tracker We might get an issue formed a filed and it's not it's not maybe as helpful as it could be So I have like a little text expand the shortcut that expands into this which Asked people step-by-step. Okay. Here's basically the information I need to reproduce this issue I may or may not have used this text expand the shortcut on my peers or co-workers in the past And if you saw that and you're my co-worker. I definitely typed that out by hand I definitely didn't just fob you for the shortcut So the next level we try and go to is trying to encourage people who show that they Had some level of understanding they may be submitted a decent issue already and try and upsell them into creating a pull request for us So again, similarly another little text expand the shortcut that expands into something where I can say okay It'd be nice if you could submit a PR now I think there's a common thing in open source that people can kind of say well You know Phobbing people off asking them to submit a PR is not very nice thing to do But I think it depends on the way you ask because I think if you just say to someone who submits an issue That's very well run now, and you just say patch is welcome. That's kind of rude whereas if you say to someone Okay, here's the docs on how to submit PR and if you get stuck We'll try and help you as best we can then that's actually helpful like that's good And that shouldn't be seen as being aggressive or rude or anything like that It's sometimes taken that way, but I think in open source again We're all trying to help each other through some form or another and we don't all have infinite time So if you can help someone help themselves, I actually think that's a tremendously valuable thing to do So if you click through to this we have a doc that looks something like this So we basically walk people through more or less step-by-step what's required To make a contribution to homebrew the type of things we expect We don't want to like tell people exactly every single command to run or the text to edit or the files to change or whatever Because a you can't write generic instructions that do that and B People need to learn a certain amount through going through this process And if they're not able to kind of figure out a certain amount themselves Then they're probably gonna struggle with the rest of what's required to make a decent contribution But then this can go further as well So if someone wants to be a maintainer then we have put documented pretty publicly the Expectations of what we expect from a maintainer how people become maintainers how people are invited to be maintainers and this step-by-step guide We follow ourselves as other maintainers when we are adding new people to join the project So this means that people can see okay. Well, if you're asking me to be a maintainer It's not this magical quiet little cabal of people where I don't know what the expectations are the expectations are clearly documented and Anyone who is being a maintainer can be pointed out. Okay. Well, these are the public expectations that are written down for How you should be behaving so people can and people have in the past called me out and said well On the maintainer document it says this but you're not doing that and that means either I need to change my behavior or Probably more accurately the document needs updated because of course. I'm not doing anything wrong So the next thing that's really important to do is thinking about retaining these folks as well Like be they users be they maintainers be the contributors You need to ask yourself. Do you have a leaky funnel? Ie are the people who are traveling down? Are they actually making it down the funnel or are they popping out the sides because you've got big holes there? And they are people who want to contribute but can't or people who want to maintain the project But you're making it too difficult for them to do so So I'd like to think about a few little things that can kind of cause issues for each of these groups So users firstly so users want your project to be high quality I mean ultimately most of us controversially despite all evidence wants software that actually works and It's important to try and focus on that in your project. This is why for example People may disagree, but I don't agree with leaving bugs intentionally unfixed in open source projects to try and attract more contributors I don't think that helps Make the project better for users I know people may laugh about that but that this is a thing that is Being done more and more now and I think the intent behind it is great And that's why I won't ever Like name drop projects who are doing that because I think they want to have more contributors They want to bring more people into open source and that's really great But you need to think are you doing that at the detriment of the people who use your software? And I think there's ways of doing this That I have put it out and will try and continue to point out that do not involve making your software intentionally worse by not fixing things The next thing is relates to the first one The users don't want to hear that you merge something which broke their workflow Because you felt guilty because someone went and spent a bunch of time making a PR And you really felt bad because they're trying their absolute hardest and you merge the PR and then it breaks over 10,000 people that's not helpful to the project either. I understand again why people do that and it's a very valid Empathetic concern that people have that leads you to that and I've done that a bunch of times myself to be clear But it's something you need to try and resist to make sure that your users don't leave your project and the final thing I'd say perhaps fairly controversially is No v2.0 and what I mean by that is obviously not actually no v2.0 But I mean you see a bunch of open source projects that have decided that there's there's too much stuff broken Everything needs to be rewritten from the ground up We need to break compatibility and then we're gonna have this beautiful new future Where everything can be clean and nice and bug-free and with less code and a hundred percent test coverage And they'll be lovely and bunnies when flowers and etc like and this stuff often Again, it comes from a really well-intentioned place But what ends up happening in these case is you say to your users Oh, I'm sorry that we broke all of your workflows and you need to rewrite every single use of our application now But if you do so it's gonna be way better now and What ends up happening then in those cases is that your users end up either Sticking on your old version forever, which isn't great because then the incentive to get involved with your project diminishes Or they go off to one of your competitor projects who actually has an easier migration path from your v1.0 Then your v2.0 does So Taking along the same lines. So what the contributors want and what the contributors need So the first thing is no who's familiar with the phrase bike shedding Okay, some people not everyone so bike setting the is the idea that if you ask people to You know debate some complex technical implementation detail Then you may not get many people joining that conversation be an open source or in your workplace Whereas if you ask people what color the bike shed should be Everyone wants to get involved and everyone has very strong opinions But it's very easy to hold very strong opinions about things that are ultimately maybe a bit banal or things There are ultimately I don't know just down to individual preference So I think it's important when you're maintaining open source community to try as much as you can these things can't always be avoided But try to steer the community away from these type of discussions or at least direct them outside of for example Your issue tracker because these end up sapping the time of contributors They end up sapping the time of maintainers and then this is time that people are not spending working on the project But are instead debating something which often either doesn't really matter that much or Is not going to be decided by the people who are getting really involved in that discussion Perhaps the opposite of that it might seem but it is important still to have open discussions like Contributors particularly people who are maybe more power users and are getting involved with contributing to your project They do want to get involved with discussions around your project They do want to get involved with the development process and they may want to do that in a place that is open to them to do so Which isn't your issue tracker so having a chat room an IOC channel a slack channel a Discourse forum whatever it may be having an open space for those folks is really great to help them with you know They're their ability to get more involved with the community without needing to just stick on the topic all the time And the last thing I think is that it's important to try and and again This is a homebrew thing that I would like to see why they're adopted But maybe controversial is don't create hundreds and hundreds of issues and don't allow Your users to create hundreds and hundreds of issues just asking for feature a and feature b and feature c If these are not features that you're planning on working on if these are not features that you are actively planning on collaborating with your community on and helping people make a pull request so that feature is great that feature request should be closed You it doesn't make sense to leave this stuff open for contributors to go and submit a PR only to realize later on well I actually felt too bad about closing the original issue, but I don't really want to accept your PR That's not helpful have your issues that are open such that if anyone turned up tomorrow with a perfect solution to that issue You would be able to merge it and Finally on to your maintainers I think the first thing that I think is really important in any project is a code of conduct an expectation of what is The acceptable behavior on that project. I think that helps serve maintainers in two ways one way is it helps Give them a framework for how they can moderate community discussions I think often in open source you can get some very very entitled users who do not pay you any money But they expect you to answer their beck and call whenever they would like And I think it's reasonable for maintainers to have a document that says if those people step over the bounds And if they're starting to be rude that says no actually you can't be rude Here's the document you agree to when you agree to participate in our community please do not be rude or you're not welcome here and Similarly, I think it's on the other way around I think it helps the community keep the maintainers accountable because also maintainers should also seek to be helpful and polite and not rude whenever tool possible Secondly something I think is valuable in open source projects is having a private place for maintainers to have discussions I think it's good that a lot of things happen in the open and open source But I think it's helpful when Disagreements could sometimes be resolved privately between maintainers so that they don't have a peanut gallery necessarily watching them be rude to each other or With heated emotion or having a technical dispute in what one person that ends up looking foolish But that's not helpful for anyone I think to happen in the open and I think having it in the open could sometimes over inflate Emotions on everyone and it's helpful to have a private place Not always and as little as possible where disputes can be resolved without having to have people watching and Finally as I've alluded to we want to make sure that maintainers are always growing Both as individuals people should feel that when they join the project that in a year or two years time They've learned more stuff about the project Hopefully learn more stuff about software development and that they are getting better and better at doing their job But then also that the number of maintainers are growing as well that you are bringing new people into the project So when other people want to leave that you have more people who can come in and replace them and continue to keep the project alive hopefully indefinitely So thinking about those four things I was saying so think about grouping your users into categories think about when you're interacting with Anyone in your project are they someone using the project? Are they someone who has contributed in some way or they maintainer think about how to get them through the open source funnel Think about how you can motivate people who are interacting with your project me in a casual way So maybe get a little bit more involved and then when they're already getting involved to level up and then become a maintainer hopefully one day Think about upselling them through that where there's little nudges that you can do at each of those stages and how to retain them as well So that they want to stay being involved with your project and your community so that you can continue to grow Without losing more people than you have attracted So hopefully this time next year you will all come I want to know this answer to your project because we will have solved all your problems So thank you so much, and if anyone has any questions, I'll be happy to answer Yeah So the question was is it no useful sometimes to keep issues around in case you need them in a few years and for me The the beauty of that is you can always reopen a closed issue. So I generally I don't know how many people work as Commercial software developers, but in my experience often with commercial software development if something's not planned in the next six to eight weeks It literally will never happen So I would err on the side of saying okay It's fine to it's fine to reopen things later on But try and err on the side of assuming you're not gonna do stuff rather than assume you're gonna do stuff And then it makes it easier for your community to know what's important right now. I Don't I don't actually know if people actually mind can responses I I think my concern is that people may feel that I haven't given them enough time back But yeah, that's maybe an illegitimate concern really and but yeah, and I would advise people to use canned replies In general because I think it makes community management a lot easier and I found personally the more can responses I use the more very positive Like crazy messages I can give to if I'm merging 30 PRs in a day There's a limit to how much I can come up with creatively to be nice to every individual person Whereas if I have a can response to everyone. Yeah, okay, it's it's somewhat automated But it's genuine like I do genuinely think those people rock or whatever Yes, the question was is our project Text free to copy and yes, it's all under an open source license. So two more questions anyone Yeah, I mean the question was what you do if your project has a bunch of users But isn't necessarily getting a lot of community action. I think in some ways, yeah I would agree with I don't know if it was a joke or not the person said it's perfect But I mean in general if you have a lot of users and you're not getting a lot of bug reports, then well done You're better at writing so far than me Any last question I think it depends on what the question was They heard about someone who has given right access to the repo for everyone who opens a PR on what do I think about that? I think that depends on your project I think if your project is Something that require something that makes releases say a ruby gem or whatever where you're still gonna have a maintainer Who actually publishes that release and make sure it's not completely broken, then that's fine I think at homebrew's case it would be possibly the worst thing for security in the entire world so So I wouldn't do that. But yeah, but it's I don't think it's always a terrible idea