Managing A Healthy GitHub Community

18 March 2016

Learn how to grow your open-source project’s community and ensure that it remains a healthy, happy and fun place.

Presented at FOSSASIA in 2016.

Show transcript

0:00 Thank you.
0:07 Sorry, I'm going to be coughing lots because I seem to be, I've come down with a cold like
0:15 a day before, so instead of being the person who gets infected by someone on the plane,
0:19 I'm now the person who's like given 400 people the same thing that I've got.
0:23 Can you hear me in the back?
0:26 Am I loud enough or do you need a microphone?
0:28 Okay, cool.
0:30 Great, so I'm going to talk to you today about managing a healthy GitHub community.
0:35 Although it's worth kind of mentioning, it occurred to me after submitting the talk that
0:39 like pretty much everything I'm going to say is valid, whether your open source community
0:43 is on GitHub entirely or not at all or whatever, whatever level in between.
0:48 I think these principles can kind of apply regardless.
0:51 So I come to you today wearing like two different hats at once.
0:55 So I'm a maintainer on homebrew.
0:58 Does anyone, I see a few Macs in here.
1:00 Does anyone use homebrew at all?
1:02 Yeah, cool.
1:03 Hopefully some of you like it.
1:05 Basically, I've been a homebrew maintainer for, I guess, almost seven years now, a lot
1:11 longer than I've been at GitHub.
1:12 And I'm like now the kind of longest running homebrew maintainer, possibly the oldest one
1:18 as well, which is a little bit sad.
1:19 But then as of like two and a half years ago, I'm also working GitHub on their API team.
1:25 So I think like sometimes these two roles can kind of collide with each other and it's kind
1:32 of difficult sometimes to give people advice about open source in a way that is being kind
1:37 of both helpful but doesn't, you know, criticize the great work my co-workers are doing that
1:42 I might think I could do better sometimes.
1:44 And I'm sure they think exactly the same thing about my work.
1:46 So hopefully I'll be able to kind of give you some sort of understanding of some of the
1:51 things I've learned through maintaining homebrew and being at GitHub on the best way of kind
1:56 of managing that.
1:57 Oh, so as well, does anyone in here use GitHub?
1:59 Cool.
2:01 Hopefully you like it as well.
2:03 Right.
2:04 So most open source projects start out like this, right?
2:08 There's one person alone in your bedroom or your office or whatever just like working on
2:14 a project by yourself.
2:16 So how many people in here would say like there's an open source project that you maybe
2:20 run where you're the only maintainer, like you're the only person working on the project
2:24 and maybe no one else is working on it except for you?
2:26 Anyone?
2:28 Yeah, yeah, a few people.
2:30 Right, no one wants to put up their hand because everyone wants to be like a big successful
2:34 open source project.
2:35 And then when you become a big successful open source project, you understand that actually
2:40 that's maybe not the best thing because you have to deal with lots of complex things.
2:44 Right, so when your project's like small and you're the only person working on it, it's
2:48 kind of fairly easy to kind of scale.
2:50 It's fairly easy to work on it.
2:51 You've probably built it for some sort of purpose you have in mind.
2:55 Quite possibly you're kind of scratching your own itch.
2:57 And then that makes it like easy for you to kind of work out maybe what you're going to
3:01 do next and stuff like that.
3:02 What users kind of come along will tend to be kind of fairly sporadic and if they are
3:07 kind of vocal generally in the relatively early days, people tend to be fairly kind, which
3:11 is nice.
3:12 So then maybe a few years later or whatever, your project gets a bit of popularity and it
3:17 starts to look a little bit more like this.
3:19 So you've got like a few people who are kind of using it.
3:22 You maybe have a few people who are working on it.
3:23 Maybe no one else is working on it kind of as much as you, but you've kind of had some
3:28 contributions from other people and stuff like that.
3:29 Like I would say this is kind of, you know, maybe a medium-sized open source project.
3:33 If you have kind of less than 10 people kind of in, say, a given month who are sort of actively
3:39 working as kind of maintainers or like active contributors on your project.
3:43 And this is when you start to see kind of community issues kind of coming up.
3:48 But when it gets really interesting is when your project starts to look a bit more like
3:50 this.
3:51 When you start having huge numbers of people who are kind of using your project, a lot of
3:55 people are very vocal about changes that are made in your project.
3:58 And you have like more and more people who are kind of wanting to contribute.
4:01 So that's when like the principles I'm going to kind of talk about today, that's when they
4:06 really come in particularly relevant.
4:07 But I think all of this stuff is great for kind of building a community right from day one
4:12 when you kind of open, when you're open sourcing like your code for the first time, thinking
4:17 about like, okay, as this project grows, what do I want the growth of this project to be
4:22 like, and how do I want people in this project to interact with each other?
4:25 So the way I found easiest to sort of think about this is splitting the people who kind
4:31 of you interact with in your project into three groups, basically.
4:34 So people may be in more than one of these groups, but for the moment we'll pretend that
4:40 they're kind of segmented groups and completely independent.
4:44 So these groups are the maintainers.
4:46 So by this, I basically mean someone who is contributing code in some form to your project.
4:52 Depending on how you manage your project, that person may or may not have commit access.
4:57 That person may or may not be employed by a company, employed by you, you check their work,
5:02 whatever.
5:03 Like it's like there's lots of different ways of doing this.
5:06 But I'm broadly talking about people who are kind of actually writing code that ends up
5:10 going into your project here.
5:11 And the next group is vocal users, and I'm differentiating them from quiet users by these
5:20 are the people you hear about, particularly as your project gets bigger.
5:22 These are the people who they create issues.
5:25 They talk about you on Twitter.
5:27 They may or may not say nice things about you.
5:30 They may or may not recommend the project to their friends and write blog posts about how
5:34 how to use your project or why your project sucks or whatever.
5:37 But these are also generally the people who are kind of living in IRC channels, mailing lists,
5:43 stuff like that for your project.
5:44 And then the third group is the quiet users.
5:47 And I think it's important to remember this group because quite often in open source, they
5:51 can get forgotten about.
5:52 Because these are the people who, you know, they downloaded your software a while ago.
5:56 They're running it on their machines.
5:58 You know, if they're on, for example, a Linux machine, they might be something that AppGet
6:03 installed and they have no contact with your project at all.
6:05 They have no idea who you are.
6:06 They might not even really know your project's name.
6:08 But these are often, with most non-terrible pieces of software, like this is going to
6:16 be your biggest group, particularly as your project grows, particularly as your project
6:20 becomes more mature.
6:21 And I think it's this group that it's very important to kind of consider while you're
6:25 planning what your project should be doing.
6:27 So I'll talk more about this.
6:29 I'm going to break out each group and then talk about things which I think the top three
6:34 things that each group you can kind of do to foster that group and the things they care
6:39 about.
6:40 So, firstly, you're kind of maintainers.
6:43 So while all of these three groups are pretty important, obviously without maintainers, depending
6:49 on what type of software you have, without your maintainers, your software will probably
6:53 end up dying eventually.
6:54 Because if your software is not receiving any bug fixes, any security updates, any new
6:58 features, then depending on the software, it may end up dying.
7:03 In Homebrew's case, as a package manager, people are relying on us to kind of, on a day-to-day
7:08 basis, continually kind of add new versions of software and stuff like that and keep things
7:12 up to date for them.
7:14 So if we all, all the maintainers just disappeared off the project and never worked on it anymore,
7:18 then what would happen is people would find Homebrew's out of date, they would never get
7:23 updated, and then they would move on to something else.
7:25 So personally, and this is maybe contentious, but I think the maintainers are not the most important
7:31 people in the project.
7:32 But if you're a maintainer, they're maybe the most important people for you to focus
7:36 on, because those are the people who, like, over time, they're going to come and go, and
7:41 those are the people where you really need to make sure that you have them to keep your
7:44 So the three things I think are nice for maintainers.
7:48 The first thing, getting talked about more and more now, but it's code of conduct.
7:52 So Homebrew's had one since the relatively early days.
7:55 FOSS Asia has one for this conference.
7:57 But basically, just, like, a description of what is acceptable and unacceptable behavior
8:02 Like, most of the time, this stuff doesn't need to be kind of hard.
8:06 It doesn't need to be complicated.
8:07 And it's, you know, some people say, oh, can you not just tell people to be nice to each
8:11 other?
8:12 And it's like, well, yeah, that's part of it.
8:13 But, you know, that doesn't always come obvious to people.
8:17 And particularly with maintainers, who are often working on open source in their free time,
8:21 if every time I interact with my open source project that I'm working on, I get abused by
8:27 people, I don't want to work on that anymore, right?
8:28 I'm going to go play with my dog or something else fun that doesn't involve me getting abused.
8:33 So personally, I think a code of conduct is really helpful towards that, because we found
8:37 on Homebrew, like 99% of the time, if someone is rude, if someone is abusive, if you point
8:42 into a code of conduct and say, hey, can you read our code of conduct and just try and be
8:46 a little bit nicer in the future, then most of the time people will just apologize and
8:51 then we all move on and that's fine.
8:53 And then in the minority of cases where people don't, then you need to question, like,
8:56 whether that person's contributions to the project outweigh the kind of negative they're
9:01 So we found in Homebrew, another thing that doesn't get talked about very often, but something
9:06 that's really helped us as maintainers, is having a private chat.
9:09 So beyond IRC, having some sort of way of communicating amongst just the maintainers, maybe, about, particularly
9:17 around code of conduct issues, for example.
9:20 The maintainers want to be able to talk to each other and discuss and kind of interact.
9:24 And also, like, you know, if you like the people you work with on a project, then you're going
9:29 to probably want to spend more time talking to those people and more time working on that
9:33 So, you know, stuff like me saying to the Homebrew maintainers, hey, like, I'm going, I'm going
9:38 to be doing a conference and then I'm going to Indonesia on holiday.
9:42 And just bear in mind, I'm not going to be committing for a while.
9:44 Like, that's, I don't really want to post that on a public mail list.
9:47 That feels kind of weird.
9:48 But yet, it's kind of nice to be able to discuss that with people and have them say, oh, you
9:52 know, have a nice holiday and ask about it when I'm back or whatever.
9:54 And those kind of bonds between maintainers are, I think, what helps keep your project strong.
10:00 And I alluded to this a little bit earlier, but I think with maintainers, you need to
10:04 always try and keep your project growing.
10:05 One of my, what I consider almost my primary responsibility on Homebrew now is just trying
10:10 to find people who are kind of contributing to Homebrew and trying to encourage them, trying
10:14 to get them kind of get people so that they either have commit access or so that they're
10:19 kind of working towards getting to a place where they can get commit access to the project.
10:23 Because, you know, not everyone's going to work on open source forever.
10:27 As I said, I'm kind of the longest running Homebrew maintainer, but there's been a bunch
10:30 of others who've kind of come, done great work for a few years, and then for whatever
10:34 reason, they've kind of left the project.
10:36 You know, sometimes it's just they have less free time.
10:38 Sometimes there's another project that interests them now.
10:41 And that's kind of inevitable.
10:42 So if you want to keep your project going, you want the maintainers to kind of keep
10:46 maintaining the project, you're going to need to make sure you keep having more
10:48 and more maintainers.
10:49 So on the next category of people, vocal users.
10:56 So vocal users are like a great bunch because generally they're so excited about your project
11:03 that they just want to talk.
11:04 They want to talk lots and lots.
11:05 They may want to go on your issue tracker, on your mailing list, on your IRC channel and
11:09 just talk and talk and talk.
11:10 And when something's great in your project, they'll tell everyone how great it is.
11:13 When something's bad, they'll tell everyone how bad it is.
11:15 And like that enthusiasm is really valuable.
11:18 But there's a few things that kind of negative things you need to sometimes keep in check
11:22 with those types of users.
11:23 The first one is trying to stop bike shedding.
11:26 I don't know if, are people familiar with what the term bike shedding means?
11:29 Okay, some people, not everyone.
11:31 So bike shedding is the idea that, you know, if you maybe say to a few, you know, if you
11:36 work in an engineering lab or whatever and you say, okay, we're going to build the next
11:40 superconductor or whatever.
11:43 Does anyone have any thoughts on how that should be done?
11:45 Then, like, that's a really expert level thing and people are like, oh, I don't really know.
11:49 Whereas if you say, okay, well, we're going to build a bike shed or we're going to paint
11:52 the bike shed a certain color.
11:54 What do people think?
11:55 Then everyone has an opinion and everyone will come in and say, you know, I think it should
11:59 be, it should definitely be red.
12:00 Oh no, it can't be red.
12:01 It should definitely be blue.
12:02 And like, basically when things have a low barrier of entry like that, like you can get a
12:07 lot of people expressing very strong opinions on a topic, which is actually really
12:11 disruptive a lot of the time.
12:13 It doesn't help.
12:14 And particularly with this, it's worth remembering, as I mentioned before, you have your quiet users
12:19 who are not participating in this process.
12:20 So if you kind of encourage everything to be a big discussion amongst the people who aren't
12:26 working on your project, then often you can end up with kind of skewed ideas of how best
12:32 to actually solve problems and it can be difficult for maintainers to communicate with each other.
12:38 On the flip side, like a mailing list or RSC channel is like invaluable.
12:43 You know, as I said before, vocal users, they want to talk about your project and they want
12:46 to interact with each other.
12:47 And as a result, a really good way of doing that is having channels where you say to them,
12:52 you know, here are places where you can talk about the project.
12:55 You can talk about more or less whatever you want.
12:57 You can help each other.
12:58 You can discuss and things like that.
13:00 And that can be a really useful avenue for those people to kind of feel like they are
13:04 valued members of your community, whilst at the same time trying to keep development spaces
13:10 focused on development.
13:11 In Homebrew, we found this quite useful to try and push people from the issue tracker
13:16 and pull requests when kind of having some of these more off-topic discussions to the mailing
13:21 list or IRC and then these conversations can go on there instead.
13:24 And finally, and this might be a bit contentious, like I would say closing feature requests.
13:31 So another thing that's quite common if you have a lot of vocal users is people will express
13:35 a lot of views on, you know, it would be great if your project did this, it would be great
13:38 if your project did that.
13:39 And what happens a lot of the time with kind of projects that have been around for a while
13:43 is their bug trackers end up, 50% of the issues in there are people filing new feature
13:48 requests and saying, wouldn't it be great if like Apache, as well as being a web server,
13:52 could also like, you know, have an email client or something like that as well.
13:56 And for some of these things, like some projects are great at this, some projects are really
14:01 I think Homebrew is somewhere in the middle, I think we're fairly good.
14:04 I think it's very important as a project maintainer to when there's stuff that people
14:09 submit, which you know immediately, your immediate reaction is we are never going to do that.
14:14 Then like politely explaining to people that you're never going to do that.
14:18 And letting them know and just closing the feature request immediately, in my opinion,
14:22 is kind of the kindest way of doing that.
14:24 On Homebrew, we take that a step further where we say, basically, unless any of the active
14:28 maintainers plan on working on this, then we close the feature request out and we say to
14:33 people, okay, we will or won't accept a pull request that implements this functionality, but
14:38 we're not, for the sake of our issue tracker, we're not going to leave this open indefinitely,
14:41 because this isn't something we're actively pursuing.
14:43 So, the kind of third group of users, we'll do questions at the end if that's alright, thank
14:51 you very much.
14:52 The third group of users are your quiet users.
14:58 So this is probably the majority of people who use your project, right?
15:01 So with Homebrew, I only meet these people when I'm at like a conference like this and I
15:07 go and say to someone like, oh hey, like, do you use Homebrew, do you like Homebrew, whatever,
15:11 and they're like, oh yeah, yeah, I know, I really like Homebrew and stuff.
15:14 And a lot of the time, the majority of the time, those people have never, they don't follow
15:18 our Twitter account, they're not, you know, they're not posting or reading GitHub issues,
15:23 they're not on our mailing list, whatever.
15:24 So their only interaction with the software, as I said before, is actually using it.
15:28 So, and I found kind of myself, when I talk to those people, they have very, very different
15:33 views of what the problems are in your software compared to the vocal users.
15:37 So, an example with Homebrew, you know, we have people who, we have like strange options
15:42 that allow you to kind of maybe configure Homebrew to behave in radically different ways.
15:46 And a lot of our vocal issues get upset where we kind of break those strange corner cases.
15:51 Whereas what our quiet users get concerned about is things like in Homebrew, we use a lot
15:56 of like crazy terminology, like when you install a package, that's a formula and it gets installed
16:01 into a keg and things like that.
16:03 And that's not obvious to a lot of people what that stuff means.
16:07 And when you propose changing it, maintainers and vocal users are often like, no, we love
16:11 this, we think it's great, this needs to stay the way it is.
16:14 Then every time I come to a conference, I get five people who say to me, oh, you work on
16:18 Homebrew, it's great.
16:19 But like, what is a keg?
16:20 I understand like, this is so confusing.
16:22 So I think this is a thing that is common with software development in general, that it's
16:27 kind of hard often to try and solicit the people who are actually using your software compared
16:32 to the people who just want to talk about it.
16:34 But I still think that it's kind of, I'm going to break down into three little things that
16:38 you can do to focus on like what broadly these users tend to want.
16:43 First one is high quality, like most of the time, most of your users care about your software
16:48 working well.
16:51 In open source, something which I think separates people's opinion quite strongly, but I come
16:57 quite heavily down on one side of, is are you better to have, you know, 100 features which
17:03 work 50% of the time, or are you better to have, you know, 10 features that work 100% of
17:08 the time?
17:09 And I'm definitely in the category that you're better to have fewer features that work well
17:12 than loads of features, all of which are kind of a bit flaky and don't necessarily work
17:17 as well as they should.
17:19 So I think if you have a project that you focus on being high quality, that will make
17:23 your users happy and it will make you get more and more users.
17:27 Whereas if you let that quality drop, eventually you'll be replaced by another project which
17:30 has focused on quality.
17:33 Another one, and this is something that's affected me personally, as a maintainer I think it's very
17:37 important, particularly to your quiet users, to not allow yourself to merge things out of
17:41 guilt.
17:42 There's a particular situation in the homebrew where someone worked really, really hard on
17:46 solving a problem a few people had requested, and their implementation was not great.
17:51 Like, I kept sort of making suggestions for changes they should make and stuff like that,
17:56 and they made all the changes and things like that, but the underlying design was just poor.
18:00 And I tried to suggest that to them, but they don't seem to kind of really get it.
18:03 And in the end I ended up merging this feature, despite the fact that I kind of knew it wasn't
18:09 high enough quality, because the person had put so much effort into it that I felt bad rejecting
18:13 their pull request.
18:14 And that's something that still causes kind of grief to this day, is the fact that we
18:18 kind of merged this feature prematurely, rather than kind of waiting for a better implementation.
18:24 So, and the last one is, I would say, and this is a bit contentious, but no v2.0.
18:30 Again, a really common thing with software is you get, like, you know, you have all the stuff
18:35 when you're writing your project that is annoying, various little, like, legacy issues and stuff
18:40 like that, and it's nice to think, ah, you know, I just wish I could throw all the code
18:43 away, start again, and then it will be all clean and great the next time around.
18:47 And that almost always kills projects, because when you do that, you end up getting rid of
18:54 all the bugs that you know, and all the bugs that you fixed, and replacing them all with
18:57 the bugs that you didn't know, and all these new bugs.
19:00 And then you break everything, and you have features that your users relied on, which you
19:04 haven't got around to implementing yet, and stuff like that.
19:07 So I think, I think it's a valuable thing to try and iterate.
19:11 Obviously you can have a v2.0, that's a slightly silly example, but trying to focus on backwards
19:17 compatibility, trying to focus on maintaining features, and trying to focus on improving
19:22 quality and improving the stuff that your software supports and does over time, and resisting
19:28 the temptation to throw everything away and start again.
19:31 a lot more fun, but it sucks for your users.
19:35 Right, so, little overview.
19:37 We talked about the three groups of people.
19:40 We talked about the sizes of projects.
19:41 This stuff is probably most relevant when your project is medium or large size, if you have,
19:46 kind of, starting to get more than you just working on it.
19:49 And once you start having, like, tens of maintainers, hundreds or thousands of users, this stuff gets
19:54 a bit more interesting.
19:55 But, I think the main things I would say to remember is try and separate your users when
20:01 you think about these things into maintainers, vocal users, and quiet users, and think about
20:06 how changes you're making on your project affect each of those groups.
20:09 And if you do so, I think you'll have a much more successful open source project.
20:13 Thank you very much.
20:15 Does anyone have any questions?
20:16 Yeah, I have one.
20:20 Thank you very much for sharing the perspective.
20:23 And my question is, like, one particular point you should mention is what, like, the easiest way
20:29 to deal with kind of growth growing is to close things early, and sometimes don't hesitate to have a,
20:36 as far as I understood, but hesitate to have a grief of closing things that we've worked on,
20:42 in case they didn't get the design right or something like that.
20:45 So, doesn't this perspective hurt the potential maintainer's tool?
20:50 Because, like, I'm not sure how many people have that experience, but, like, I saw people being rejected
20:57 on their first pull request ever, and it was to homebrew.
21:00 Yeah.
21:01 It was discouraging them.
21:02 Yeah.
21:03 Yeah, that's a really good point.
21:10 To repeat it in case anyone didn't hear, there was asked about, basically, correct me if my
21:15 summarization is wrong, that is there not a tension between saying you should kind of close pull requests
21:20 early, close issues early, and people's maybe first contribution to a project like homebrew being
21:25 something that gets closed immediately?
21:27 And does that not cause problems for the community?
21:29 And I think that's a really good question.
21:31 I think it's definitely tricky to play, and I think the way to do that is about how you close things.
21:39 And I think particularly in homebrew, and particularly myself as an individual, I've got a lot better at
21:43 doing that, about making sure when you close things that you say to people, okay, like,
21:48 this is what, like, this is why we can't accept this, we're really sorry, and try and explain to
21:53 them why and saying, but, you know, there's maybe something in here that you can do which will help
21:57 And also trying to, if people have mistakes that are correctable, trying to kind of get them to a point
22:03 where, you know, lots of review, lots of feedback to help people get to that point.
22:07 But as if you close an issue and just say RTFM noob or whatever, like, then that's when people get
22:13 discouraged and they leave and they don't want to work on the project anymore.
22:16 But yeah, no, great point.
22:17 Just to follow up, did you ever have experience of people being pissed off by that until the point you
22:25 escalated to pointing to the code of conduct, and that saying you stopped, you cannot complain
22:33 of that anymore or email, and do you have experience of that?
22:35 So the question was if you ever have people who get annoyed by that and then have to be
22:40 pointed to the code of conduct because they've kind of been upset by the process.
22:43 Yeah, that happens, that happens sometimes. And like, generally, there's a positive outcome of
22:49 that. But yeah, there's, you know, probably once a year, probably no more than once a year,
22:53 we have someone who makes a pull request, it gets rejected for whatever reason, and they flip out,
22:58 and they need to get basically blocked on the project. Because, I mean,
23:01 sometimes that, like, it literally gets to the point where people will, like, follow you on Twitter,
23:06 abuse maintainers on Twitter, all this type of stuff, just because they're upset, a pull request
23:10 didn't get merged. And I think, like, you know, that's clearly unacceptable behavior, no matter the
23:15 quality of their pull request. Like, if you start doing stuff like that, our attitudes, we will just
23:20 close your pull request, regardless. So, any other questions? Yep.
23:24 I once read this blog post called the pull request hack, where you give commit access to the person who
23:32 opens a pull request. I mean, it works in the cases where you're not interested in working on your project
23:39 anymore, and you're looking for maintainers for it. So, you just give commit access to anybody who opens a pull request,
23:46 and they've done the right thing. But, I mean, I find it a bit odd, and what are your thoughts on that?
23:54 Yeah. So, the question was about, like, there's kind of this blog post about the pull request hack,
24:00 that's basically, like, if anyone makes a pull request to your project, you merge it. After you merge the
24:04 pull request, you just immediately give them commit access to your project. And I think for, yeah, for small
24:09 projects, I think that can work really well, particularly on projects you don't want to maintain anymore. And I've done that,
24:14 kind of, that approach online. I've probably done it after three or four pull requests rather than just one.
24:19 But, yeah, but I think it's, when you get bigger projects, like Homebrew, for example, like, if we took that
24:24 model, like, the quality would just go, like, very quickly. So, yeah, it's a balance, but an interesting one.
24:30 One more question? Anyone?
24:33 Do you think there's a difference between company-managed open source projects versus community-managed?
24:42 Yeah, that's a good question. And hopefully, I'm going to try and say this with my Homebrew hat on,
24:48 rather than my GitHub hat on. But yeah, the question was if there's a difference between
24:51 company-managed and community-managed open source projects. I think a big criticism that I've had,
24:57 even internally at GitHub, and we talk about this fairly publicly, is that you need to be really
25:02 careful with company-managed ones to be clear, almost like what I said about closing feature requests.
25:07 So if your company knows this is the direction this project's going to take, and effectively,
25:12 we're releasing the code in the open, but people in the community don't get to decide the direction
25:16 of this project, then you should be, like, super explicit about that. You should close pull requests
25:20 early. You should close feature requests early. You should add to your README to make sure that you
25:24 clarify that, like, you know, this is the way we're doing things. You know, if you want to work on
25:29 this project, apply for a job with this company. And I think that's a more honest way of doing things.
25:34 And I think on the community side of things, I personally, where I found that it's kind of
25:39 interesting is where the two overlap. The people I found the most, I work on Homebrew entirely in my
25:43 free time. Well, pretty much, unless someone at GitHub screams that something needs fixed.
25:47 But yeah, so when it gets awkward is when I interact with someone who runs a company-sponsored
25:54 open source project, who's been told, you need to get your project into Homebrew by Friday,
25:59 you know, for your performance review to be good this year. And then when we're not as quick as they
26:03 like us to be, they start shouting and screaming. And that's someone who's, you know, being paid to
26:08 contribute to Homebrew. And the maintainers on Homebrew have never been paid for anything. And so,
26:13 yeah, there's definitely tensions there. And I think it's something that we'll see more about in
26:18 future. But I think some of it is just companies learning how to do open source better and learning how to
26:23 interact better with the community. But yeah, great question. Thank you so much. Yeah. Thank you
26:26 everyone for coming. All right.

Mike McQuaid

Managing A Healthy GitHub Community