Why People Don’t Contribute To Your Open Source Project

Why People Don't Contribute To Your Open Source Project

10 May 2017

How users generally progress from filing bad issues to filing good issues to making simple contributions to making complex contributions to maintaining an open source project.

Presented at OSCON in 2017 and FOSDEM in 2018.

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 Thanks, everyone.
0:07 Just to start with, I'm coming at this talk with two
0:10 different hats on.
0:11 So I am the lead maintainer of Homebrew, a Mac package
0:14 manager.
0:15 Anyone who used Homebrew ever?
0:16 Cool, thank you very much.
0:19 So has anyone submitted a PR to Homebrew ever, by any chance?
0:23 Woo, well done, you.
0:24 Thank you very much.
0:25 And I can confirm at least several of those people were
0:27 not lying.
0:28 I recognize their faces.
0:30 How many people have opened an issue on Homebrew only to
0:33 have me immediately close it and probably be rude at you by
0:36 mistake, because I'm busy?
0:37 Yeah, sorry.
0:39 I'm sorry.
0:40 So if you want help submitting a PR to Homebrew ever, then get
0:43 in touch with me, and I will try and help you as best I can.
0:46 My other hat that I wear is GitHub.
0:48 Who has heard of GitHub?
0:50 Cool.
0:52 So I don't think everyone who works at GitHub in this room
0:55 put their hand up, which is a little bit worrying.
0:57 I've been at GitHub for about four and a bit years, and I'm
1:00 trying to make it better for open source software and better
1:02 in general.
1:03 So if you would like to talk to me about making GitHub better,
1:06 then get in touch as long as you are going to be nice about it.
1:09 Anyway, so the title here, why people don't contribute to your
1:14 open source project.
1:15 I'm going to come at this from perhaps a funny angle.
1:19 What I'm talking to mainly is open source projects that have
1:23 these things met already.
1:24 So your open source project is already open sourced.
1:28 Please, if you're one of those companies who's like, why is my
1:30 open source project successful?
1:31 I'm planning on open sourcing in three months.
1:33 Then don't come to speak to me.
1:35 I hope that you already have some users of your project, i.e.
1:38 you're building something useful, which is useful to more
1:42 than just you and more than just your organization.
1:45 But you maybe don't have as many people contributing or as many
1:49 people maintaining your project as you would like.
1:52 So you may ask yourself, why is no one contributing to my project?
1:58 But I would like to pivot this and think about a slightly
2:00 different question.
2:02 So if you're a company and you're making stuff for money, then if
2:06 you're not making as much money as you would like, then you might
2:08 ask yourself, why is no one buying my project?
2:12 What product, even?
2:13 Well, so we're going to ignore the fact, we're going to pretend
2:15 that your product is not terrible.
2:18 And instead, let's go and think about your product in the same
2:22 way as we might think about the open source project before.
2:24 So I would argue that it's open source that has users but not
2:29 contributors and maintainers is not terribly dissimilar to the
2:33 idea that your project is created.
2:36 You have a decent product already.
2:39 You have a bunch of people using it already, but you've
2:42 not actually tried to sell it to anyone.
2:44 And as a result, not enough people are buying it.
2:47 So let's think about this through the rest of this talk,
2:50 through four different ways of thinking about this.
2:53 So we're going to talk about grouping the people who are using
2:56 your project already into different categories.
2:59 We're going to talk about a funnel with a terrible metaphor,
3:01 which I like.
3:02 We're going to talk about upselling people through the funnel,
3:05 which is actually going down through the funnel, because I
3:07 haven't really thought this through.
3:09 And how to retain the people who you have put either up or
3:13 down through the funnel, depending on which bit of the
3:15 talk you remember.
3:16 Right.
3:17 So grouping your users.
3:19 So firstly, why are people interacting with your project
3:22 at all?
3:23 So I'm going to say there's three different reasons, basically,
3:26 or three different groups that people interact with any
3:29 open source project.
3:30 We're assuming when I say interaction here that this is
3:33 interacting primarily online, primarily with, say, a GitHub
3:37 repo, if that's the primary face of your open source project.
3:42 So you've got the users.
3:43 These are the people who are using the software.
3:45 They may be file issues.
3:46 They maybe don't.
3:47 We're assuming for this case they don't write the code.
3:50 They don't write docs.
3:52 They're not triaging issues for your particular project.
3:54 They may do it for other projects.
3:56 But your project is going to have, hopefully, at least one
3:59 of these, which is the person who wrote the software, i.e.
4:03 you.
4:04 If you don't use the software you wrote, then you perhaps
4:07 have some bigger problems.
4:09 So the next group is your contributors.
4:11 So these, I'm going to say, again, my definition may vary
4:14 from other people's.
4:15 But my definition is these are people who have written code,
4:18 or docs, or triage on your project.
4:21 And they need some sort of help from other people with getting
4:25 their work included.
4:26 So if we're talking about a GitHub repository here,
4:29 these are people who maybe are helpful in your community.
4:31 They maybe submit PRs.
4:33 But they don't have direct commit access
4:35 to make the changes they want to the project directly.
4:39 And then finally, you have maintainers.
4:41 These are the people who review the incoming changes
4:44 that are coming in.
4:45 They review issues that are coming in.
4:47 And they merge the work of contributors.
4:49 And if they're feeling kind, they maybe
4:51 help users once in a while with the issues
4:53 that they're having.
4:54 So again, you're going to have at least one of these.
4:57 If you start a project by yourself on GitHub or any other similar
5:00 platform, then the first person who started the project, the first user
5:04 perhaps as well, is going to be the first maintainer.
5:07 So let's have a think about how you might put these three groups through a funnel.
5:13 So firstly, I'm going to make a couple of perhaps bold statements.
5:18 So I would say no one became a contributor without being a user first.
5:22 So this is something that maybe isn't always the case in open source.
5:25 But I would argue for healthy projects, the best way of attracting and retaining contributors
5:31 is getting the people who are already using your software to get involved.
5:35 I realize there's perhaps a growing movement of people who think it's a good thing to just
5:39 get up here on an open source project for the sake of it, who might go along and try and contribute
5:43 to a project because they think it will look good on their resume or whatever.
5:46 I would argue that that person is, although they are a good intention, they are probably not
5:51 really helping either the project or themselves as much as they could be.
5:55 The best way I think you can get involved is getting involved with a project where you are
5:59 helping both the project and yourself through your contribution.
6:03 Secondly, no one ever became a maintainer without being a user.
6:06 Even more so, how can you merge PRs from other people?
6:10 How can you support a project if you have at no time used that project?
6:16 But really, what this ends up being often is no one excels as a maintainer without remaining
6:20 a user.
6:21 And I think this is an important part to think about when you're thinking about why you need
6:25 new contributors on a project at all.
6:28 Because maintainers in a project are generally temporary.
6:31 If you wrote some piece of software, chances are you're not going to be using that on a day
6:35 to day basis in five or ten years.
6:38 Other people may be, but you're not likely to be doing so anymore.
6:41 So as a result, at some point, there's going to be a time where it probably makes
6:45 sense for you to hand off that project to other people.
6:48 But you need to make sure that when that time comes, you actually have other people you
6:53 can hand off to.
6:54 Because otherwise, you're going to have a project which just dies when you stop being involved.
7:00 So let's go back to this really awkward metaphor I was talking about before about thinking about
7:04 a product instead of an open source project.
7:06 So in a sales funnel, I believe, I haven't really done anything in sales ever other than
7:13 this one time.
7:15 So this may be completely wrong, but please don't correct me because that would just be mean.
7:19 So this is my understanding of a sales funnel.
7:22 So you have leads, who are the people who may be interested in buying your product.
7:28 You have prospects, who are people who are interested in buying your product, but have not yet bought
7:33 it.
7:34 And then you have sales, who are people who have actually handed you over some money,
7:38 and in exchange, you have provided your product to them.
7:42 So I would argue is a sort of similar tenuous similarity with those three groups I was talking
7:47 about before.
7:48 You have your users, you have your contributors, and your maintainers.
7:52 So we have similar levels of involvement here.
7:55 You have people who are perhaps potentially interested in getting involved.
7:59 You have people who have expressed interest in getting involved, but haven't fully committed
8:04 to maybe being a maintainer yet.
8:06 And then you have the people who are really, really helping you run things.
8:10 So people wonder often in open source projects, they say, well, I've got a bunch of users, but
8:16 no one's really contributing.
8:18 Or I've got a bunch of contributors, but no one wants to become a maintainer.
8:21 So I thought the numbers for homebrew may be kind of helpful.
8:24 So homebrew has, according to Google Analytics, about 4 million users.
8:29 I reckon it's more like about a million monthly kind of users based on our analytics.
8:35 We have 6,000, maybe 7,000-ish homebrew contributors.
8:41 That's 0.05% of our user base.
8:44 And then of them, we have-- I don't know what the current number is today, but sort of 12,
8:49 14,000 homebrew maintainers, which is 0.0015% of our user base.
8:55 And that's-- we have probably about 25 people who have ever been a maintainer on homebrew
8:59 in the nine-year life of the project.
9:02 So that's a pretty dramatic funnel.
9:04 And hopefully, again, if you work in an open source project, hopefully you will have better
9:07 numbers than we do, but still, that shows the levels you can perhaps expect.
9:13 You can expect every user is going to be a contributor to your project.
9:16 And you can't expect that every contributor is going to want to be a maintainer.
9:19 But what you can do is do your best to upsell, to make sure that as many people as possible
9:25 people will pass through those groups.
9:29 So something that I've experienced in open source is that most maintainers are not going,
9:35 "Me, me, please, please, please, I want to be the maintainer."
9:37 Most maintainers are the people involved in a project who are being really, really helpful.
9:41 And then when you ask them to consider being a maintainer, they-- most of the talented maintainers
9:46 I know say no at least once when they're first asked because they think, "No, no, no, I'm
9:51 not qualified to do this.
9:52 I've just submitted a few good PRs, and that doesn't make me qualified to do this.
9:58 And I can't help you because I don't know everything that there is to know about this
10:02 stuff."
10:03 Whereas the people who really, really, really want to be a maintainer, it's normally some
10:06 sort of powery thing or other potential psychology that I'm not going to do today.
10:12 So most of these folks need to be encouraged and they need to be invited to get involved
10:17 with the project.
10:18 And that applies with contributors and that applies with users who you want to start getting towards
10:23 this as well.
10:24 So let's look at some, like, upsell through screenshots here.
10:27 Right, so this is an example of us trying to upsell someone on Twitter.
10:31 So they submitted-- and I don't-- I probably should have blanked out their name.
10:34 So to be clear, this is not someone who I think is doing anything wrong.
10:37 But this is, for example, the type of issue that you might get where if you're not a very
10:43 active software developer or if you're not familiar with the project you're submitting
10:45 the issue to, it's not clear why it's not terribly helpful.
10:49 So what we've tried to say to them is, "Okay, here is somewhere you can go."
10:54 And we linked them to the issue template there so they can go and see, "Okay, here's the type
10:59 of things that we want when you're submitting a new issue."
11:02 So we're trying to upsell that person from basically just a tweet saying, help me, to an issue that
11:09 will give us the information that we need for them to help us.
11:13 And hopefully that means, again, the next time, they will jump straight to the next step because
11:17 they say, "Okay, I know what is required in order for me to be helped.
11:20 So I'm going to follow these steps in advance."
11:22 And actually, fun fact on our issue tracker, if you follow the steps required to fix an issue,
11:27 sorry, to report an issue well, often for us, you will figure out what the problem is through
11:31 doing so and then be able to help yourself, which is tremendously empowering.
11:35 So the next step is similarly on someone's issue tracker.
11:40 We might get an issue formed, filed, and it's not maybe as helpful as it could be.
11:45 So I have a little TextExpander shortcut that expands into this, which asks people step by
11:51 step, "Okay, here's basically the information I need to reproduce this issue."
11:56 I may or may not have used this TextExpander shortcut on my peers or co-workers in the past, and if
12:02 you saw that and you're my co-worker, I definitely typed that out by hand.
12:04 I definitely didn't just fob you off with a shortcut.
12:09 So the next level we try and go to is trying to encourage people who show that they have
12:15 some level of understanding, they maybe submitted a decent issue already, and try and upsell them
12:20 into creating a pull request for us.
12:22 So again, similarly, another little TextExpander shortcut that expands into something where I
12:27 can say, "Okay, it'd be nice if you could submit a PR."
12:30 Now I think there's a common thing in open source that people can kind of say, "Well,
12:34 you know, fobbing people off asking them to submit a PR is not a very nice thing to do."
12:39 But I think it depends on the way you ask, because I think if you just say to someone
12:43 who submits an issue that's very well written now and you just say "Patch is welcome,"
12:48 that's kind of rude.
12:49 Whereas if you say to someone, "Okay, here's the docs on how to submit a PR, and if you
12:53 get stuck, we'll try and help you as best we can," then that's actually helpful, like
12:58 that's good.
12:59 And that shouldn't be seen as being aggressive or rude or anything like that, it's sometimes taken
13:04 that way.
13:05 But I think in open source, again, we're all trying to help each other through some form
13:10 or another, and we don't all have infinite time.
13:13 So if you can help someone help themselves, I actually think that's a tremendously valuable
13:17 thing to do.
13:22 So if you click through to this, we have a doc that looks something like this.
13:26 So we basically walk people through, more or less step by step, what's required to make
13:31 a contribution to homebrew, the type of things we expect.
13:34 We don't want to tell people exactly every single command to run, or the text to edit, or the
13:39 files to change, or whatever.
13:40 Because A, you can't write generic instructions that do that, and B, people need to learn a
13:44 certain amount through going through this process.
13:47 And if they're not able to kind of figure out a certain amount of themselves, then they're
13:51 probably going to struggle with the rest of what's required to make a decent contribution.
13:54 But then this can go further as well.
13:57 So if someone wants to be a maintainer, then we have documented pretty publicly the expectations
14:02 of what we expect from a maintainer.
14:05 How people become maintainers, how people are invited to be maintainers, and this step-by-step
14:09 guide we follow ourselves as other maintainers when we are adding new people to join the project.
14:14 So this means that people can see, OK, well, if you're asking me to be a maintainer, it's
14:19 not this magical, quiet little cabal of people where I don't know what the expectations are.
14:23 The expectations are clearly documented, and anyone who is being a maintainer can be pointed
14:28 out, OK, well, these are the public expectations that are written down for how you should be behaving.
14:34 So people can, and people have in the past, called me out and said, well, on the maintainer
14:39 document it says this, but you're not doing that.
14:41 And that means either I need to change my behavior or, probably more accurately, the document needs
14:46 Because, of course, I'm not doing anything wrong.
14:52 So the next thing that's really important to do is thinking about retaining these folks
14:56 Like, be they users, be they maintainers, be they contributors.
15:00 You need to ask yourself, do you have a leaky funnel?
15:03 I.e., are the people who are traveling down, are they actually making it down the funnel?
15:08 Or are they popping out the sides because you've got big holes there?
15:12 And they are people who want to contribute but can't, or people who want to maintain the project,
15:17 but you're making it too difficult for them to do so.
15:19 So I'd like to think about a few little things that can kind of cause issues for each of these groups.
15:25 So users, firstly.
15:28 So users want your project to be high quality.
15:32 I mean, ultimately, most of us controversially, despite all evidence, want software that actually works.
15:39 And it's important to try and focus on that in your project.
15:42 This is why, for example, people may disagree, but I don't agree with leaving bugs intentionally unfixed in open source projects
15:49 to try and attract more contributors.
15:51 I don't think that helps make the project better for users.
15:55 I know people may laugh about that, but this is a thing that is being done more and more now.
16:01 And I think the intent behind it is great.
16:03 And that's why I won't ever name drop projects who are doing that, because I think they want to have more contributors
16:09 they want to bring more people into open source.
16:11 And that's really great.
16:12 But you need to think, are you doing that at the detriment of the people who use your software?
16:16 And I think there's ways of doing this that I have pointed out and will try and continue to point out
16:21 that do not involve making your software intentionally worse by not fixing things.
16:25 The next thing is, relates to the first one, that users don't want to hear that you merged something
16:31 which broke their workflow because you felt guilty.
16:35 Because someone went and spent a bunch of time making a PR,
16:38 and you really felt bad because they're trying their absolute hardest
16:42 and you merged the PR and then it breaks over 10,000 people.
16:45 That's not helpful to the project either.
16:47 I understand, again, why people do that.
16:50 And it's a very valid, empathetic concern that people have that leads you to that.
16:55 And I've done that a bunch of times myself, to be clear.
16:57 But it's something you need to try and resist to make sure that your users don't leave your project.
17:02 And the final thing I'd say, perhaps fairly controversially, is no V2.0.
17:09 And what I mean by that, it's obviously not actually no V2.0.
17:13 But I mean, you see a bunch of open source projects that have decided that there's too much stuff broken.
17:20 Everything needs to be rewritten from the ground up.
17:22 We need to break compatibility.
17:24 And then we're going to have this beautiful new future where everything can be clean and nice and bug-free and with less code and 100% test coverage.
17:32 And it will be lovely and bunnies and flowers and et cetera.
17:35 And this stuff often, again, it comes from a really well-intentioned place.
17:40 But what ends up happening in these cases 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.
17:49 But if you do so, it's going to be way better now.
17:53 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.
18:04 Or they go off to one of your competitor projects who actually has an easier migration path from your V1.0 than your V2.0 does.
18:13 So thinking along the same lines.
18:17 So what do contributors want and what do contributors need?
18:19 So the first thing is, who's familiar with the phrase byte shedding?
18:24 Okay, some people, not everyone.
18:25 So byte shedding is the idea that if you ask people to debate some complex technical implementation detail, then you may not get many people joining that conversation, be it in open source or in your workplace.
18:37 Whereas if you ask people what color the byte shed should be, everyone wants to get involved and everyone has very strong opinions.
18:43 Because it's very easy to hold very strong opinions about things that are ultimately maybe a bit banal or things that are ultimately, I don't know, just down to individual preference.
18:53 So I think it's important when you're maintaining an open source community to try as much as you can.
18:59 These things can't always be avoided.
19:01 But try to steer the community away from these type of discussions or at least direct them outside of, for example, your issue tracker.
19:09 Because these end up sapping the time of contributors.
19:11 They end up sapping the time of maintainers.
19:13 And then there's just 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.
19:28 Perhaps the opposite of that, it might seem, but it is important still to have open discussions.
19:33 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.
19:42 They do want to get involved with the development process.
19:44 And they may want to do that in a place that is open to them to do so, which isn't your issue tracker.
19:49 So having a chat room, an IRC 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, their ability to get more involved with the community without needing to just stick on the topic all the time.
20:06 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 wider 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.
20:24 If these are not features that you're planning on working on, if these are not features that you're 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.
20:37 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.
20:49 That's not helpful.
20:50 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.
20:56 And finally, onto your maintainers.
20:59 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.
21:10 I think that helps serve maintainers in two ways.
21:13 One way is it helps give them a framework for how they can moderate community discussions.
21:19 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.
21:29 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.
21:38 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.
21:43 And similarly, I think it's on the other way around.
21:46 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 at all possible.
21:57 Secondly, something I think is valuable in open source projects is having a private place for maintainers to have discussions.
22:02 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 ends up looking foolish.
22:23 Like, 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.
22:40 And finally, as I've alluded to, we want to make sure that maintainers are always growing, both as individuals.
22:47 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.
22:53 Hopefully, they 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.
23:11 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's contributed in some way, or are they a maintainer?
23:23 Think about how to get them through the open source funnel. Think about how you can motivate people who are interacting with your project, maybe in a casual way, to 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.
23:38 Think about upselling them through that, with those 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.
23:52 So, hopefully, this time next year, you will all come and want to know this answer to your project, because we will solve all your problems. So, thank you so much, and if anyone has any questions, I'll be happy to answer.
24:21 Yeah, so the question was, I don't have to decide, because sometimes, maybe you don't plan to work on it during the next year, but maybe in three years, this issue will become relevant, and it's good to have a discussion, because at some point, the discussion will unfold, and maybe some ideas will become, and maybe some people will be contributing, or maybe the project itself will be reached that point where we want to implement this. So, I don't know, it's difficult to find this.
24:49 Yeah. So the question was, is it not useful sometimes to keep issues around in case you need them in a few years?
24:55 And for me, the beauty of that is you can always reopen a closed issue.
25:00 So I generally, I don't know how many people work as commercial software developers,
25:05 but in my experience, often with commercial software development,
25:08 if something's not planned in the next six to eight weeks, it literally will never happen.
25:13 So I would err on the side of saying, OK, it's fine to reopen things later on,
25:19 but try and err on the side of assuming you're not going to do stuff rather than assuming you're going to do stuff.
25:24 And then it makes it easier for your community to know what's important right now.
25:27 Sorry.
25:30 Why is, like, I've been at the receiving end of your amazing kind of messages,
25:38 and I actually really enjoy getting, like, an actual, like, something I can read
25:45 and something which has some body to it and maybe a link to the relevant documentation
25:49 over, like, a quick job any day.
25:52 So what do you think it is that makes you so anxious about the candid responses?
25:59 And is that actually something that you feel from people that they get angry about?
26:04 I don't actually know if people actually mind candid responses.
26:09 I think my concern is that people may feel that I haven't given them enough time back.
26:15 But, yeah, that's maybe an illegitimate concern, really.
26:19 But, yeah, and I would advise people to use candid replies in general
26:24 because I think it makes community management a lot easier.
26:26 And I found, personally, the more canned responses I use,
26:30 the more very positive, like, crazy messages I can give to,
26:35 if I'm merging 30 PRs in a day, there's a limit to how much I can come up with creatively
26:41 to be nice to every individual person.
26:42 Whereas if I have a canned response to everyone, yeah, okay, it's somewhat automated,
26:47 but it's genuine.
26:48 Like, I do genuinely think those people rock or whatever.
26:53 Yes, the question was,
27:07 is our project text free to copy?
27:10 And, yes, it's all under an open source license.
27:11 Okay.
27:12 It's time for two more questions.
27:13 Two more questions.
27:14 Anyone?
27:15 I have a couple of small, very small software projects.
27:22 And, for example, for one that I don't really care about,
27:25 I've received the PRs and I've merged them.
27:28 And the one that I actually care about,
27:31 and I can see it's used because I see traffic to it,
27:34 I get, like, an email every, like, two years.
27:38 So what do you do when that happens?
27:40 I mean, there's nothing to interact with that you can try to,
27:43 you know, make people more interested.
27:45 Like, I don't know.
27:46 Yeah, I mean, the question was,
27:48 what do you do if your project has a bunch of users
27:50 but isn't necessarily getting a lot of community action?
27:53 I think in some ways, yeah, I would agree with,
27:56 I don't know if it was a joke or not,
27:57 the person said it's perfect.
27:59 But, I mean, in general, if you have a lot of users
28:01 and you're not getting a lot of bug reports,
28:02 then well done.
28:03 You're better at writing software than me.
28:07 Any last question?
28:08 I heard about a strategy that someone was giving everyone
28:15 retainer access or write access to the repo
28:18 when they opened up a request.
28:20 I think it depends on what, sorry,
28:22 the question was, they heard about someone
28:25 who has given write access to the repo
28:27 for everyone who opens a PR.
28:28 And what do I think about that?
28:29 I think that depends on your project.
28:31 I think if your project is something that requires,
28:34 something that makes releases,
28:36 where you're still going to have a maintainer
28:38 who actually publishes that release
28:40 and makes sure it's not completely broken,
28:42 I think in Homebrew's case,
28:44 it would be possibly the worst thing
28:46 for security in the entire world.
28:47 So, I wouldn't do that.
28:50 But, yeah, I don't think it's always a terrible idea.
28:53 Thank you for coming up.
29:06 Thank you.

Mike McQuaid

Why People Don't Contribute To Your Open Source Project