Mike McQuaid on the Greatest Lessons He’s Learned in Over 16 Years at Homebrew

07 October 2025

Interviewed by GitHub Podcast

Homebrew’s project lead Mike McQuaid joins Abby and Andrea to unpack what it really takes to sustain one of the most-used developer tools on macOS and Linux.

Show transcript

0:00 This is the GitHub Podcast, a show dedicated to the topics, trends, stories, and culture
0:08 in and around the open source developer community on GitHub.
0:11 I'm one of your hosts.
0:13 My name is Abby from the open source programs team, and I'm joined with my lovely co-host,
0:17 I am Andrea Griffiths, Senior Developer Advocate at GitHub, and I am delighted to be here today
0:24 because we are talking to the amazing Mike McQuaid.
0:28 And if you ever use Mac for development, you've probably used his work without knowing it.
0:33 Mike is the project leader of Homebrew, the package manager that's installed on tens of
0:37 millions of Macs worldwide.
0:39 Project he's been maintaining for over 16 years, I think longer than anyone else.
0:44 So that makes him one of the most experienced open source maintainers in the world, and we're
0:49 just delighted to have Mike here with us today.
0:51 We're going to talk about Homebrew, his evolution and growth as a maintainer throughout the years,
0:56 and also the open source zone upcoming to GitHub Universe.
1:00 Hey Mike, welcome to the show.
1:01 Hey, thanks for having me.
1:03 Can you tell us a bit about like, why did you start contributing to Homebrew?
1:07 What it is?
1:08 So Homebrew, my like one-liner to describe what it is, I guess, for the probably fairly
1:15 savvy group who would be listening to this would be, it's basically like a pack app store
1:21 for open source software in your terminal.
1:24 And so we have other non-open source software and stuff in there as well, but that's like
1:28 what most people use it for most of the time.
1:30 And also, I guess another way would be saying if you're like a developer and you're on a
1:34 Mac, chances are you install a bunch of stuff.
1:37 All the stuff that you don't install with like NPM or RubyGems or PyPy or whatever, you're
1:41 probably installing with Homebrew.
1:42 So like your database and all that type of stuff.
1:44 So you're likely to have used Homebrew.
1:46 Some people that might be listening to this or watching us now are probably as old as
1:52 Homebrew or younger than Homebrew, which is kind of wild, right?
1:56 Yeah.
1:57 Homebrew is all day known.
1:59 Homebrew is all day known.
2:01 Listen, I'm not one of those that is like back in my day, but for real, we don't appreciate
2:06 Before Homebrew, Mike, what do people have to do?
2:10 Like what were we subjected to then?
2:13 So Homebrew was made by a guy called Max Howell originally.
2:17 So he was working at a startup in London and he was complaining about Mac ports, a package
2:24 manager, still a very good package manager around to this day.
2:26 He was complaining in the pub in London, as you do when you're in London.
2:30 And I think apparently one of his coworkers eventually snapped and said like, well, if
2:34 you know so much, why don't you just go and make your own package manager?
2:37 So he went home having had some beer and then wrote up his design for a beer themed package
2:44 manager, which then became Homebrew.
2:45 So I guess my involvement was maybe a few months into having created Homebrew.
2:52 Like a few people were starting to use it mainly in the Ruby community to begin with.
2:55 And I heard about this from like a friend of friend.
2:58 I was also a tech startup in London at the time.
3:00 And I tried to build a thing on top of Mac ports to sort of make it work in a more, what
3:06 I didn't realize at the time, more Homebrew-y way.
3:09 And then I came across Homebrew and I was like, oh, this is cool.
3:11 I'm going to use this, right?
3:13 And I didn't start using it thinking I was going to contribute code or maintain or anything
3:18 like that.
3:19 But I'd done bits and pieces in open source over the years with like KDE and Linux and
3:23 various other bits and pieces.
3:25 So when I had a problem, like it was fairly natural for me to go and be like, okay, I'm
3:30 going to go and submit a change to Homebrew.
3:31 I was going to say submit a pull request, but actually Homebrew predates pull requests being
3:36 on GitHub.
3:37 So the way it started is me and Max would both be on IRC and I would like DM him on IRC
3:44 with a link to my commit on GitHub in my fork, which he would then, you know, check out locally
3:50 and pull that in and then push it and whatever, right?
3:53 And eventually it got to the point that like I contributed a few bits and pieces and he
3:57 was like, hey, like, why don't you be a maintainer and help me do some of this?
4:01 So I think I was the third person to join with Max being the first.
4:06 And yeah, and then I just sort of never got around to not doing that.
4:10 And I still am doing it to this day.
4:12 I didn't realize there was a time GitHub didn't have pull requests.
4:15 So that's news to me.
4:17 That's amazing.
4:18 You joined this team.
4:20 You became a maintainer.
4:21 At the time, it was only the two of you.
4:23 How many maintainers are there now?
4:25 I'm actually, I need to check because it like varies from week to week, month to month.
4:30 And we just had, we're about to have some new people join and we just had some people leave.
4:34 So we've got, let's see, 29 people as of today.
4:37 And yeah, I would say like on a day to day basis, not all of those people are involved,
4:43 but like on a week to week basis, probably like at least probably half of them are involved
4:46 in some way.
4:47 But yeah, but still, it's not a lot of people considering Homebrew has, we don't have exact
4:52 numbers, but perhaps tens of millions of users.
4:55 So yeah, it's not bad going for 30 people.
4:58 Oh, of course.
4:59 And the OSI did a little blog post about you.
5:01 You said the ratio from, you have a hundred to one contributor to maintainer ratio, which
5:05 is really impressive.
5:06 How do you think you got to that place?
5:08 You have so many contributors.
5:09 So not to bore the listeners too much with package management minutiae, but the way most
5:15 package managers like Homebrew kind of work is you have one maintainer for each package.
5:19 It may well be a maintainer maintains like multiple packages or whatever, but essentially
5:23 you tend to have like potentially even thousands of maintainers packaging things.
5:27 When you go to like stuff like NPM, there's probably literally millions of maintainers maybe
5:31 at this point.
5:32 But at Homebrew, the way we did it is like, okay, like the goal of the maintainers is not
5:37 to do all the work, but essentially to shepherd the work that is coming in from other people.
5:41 So that's been part of it.
5:43 Part of it is like the Homebrew's, I guess, DSL, like domain specific language, like the
5:49 way you define what gets installed and how it gets installed is like very readable and
5:54 it's written in Ruby and it's pretty easy even if you've never done literally any program
5:57 for let alone any Ruby before to kind of contribute and fix things and whatever.
6:01 And then the other thing which I'd like to take at least partial credit for is I'm, I
6:06 am and Homebrew is very, very, very into like automation and tooling and stuff like that.
6:11 Right.
6:12 So you can make your first contribution to Homebrew by running like a single command that
6:16 will change the version and commit it and make a pull request and open the pull request
6:21 for you.
6:22 So like we've just made it really, really, really easy to make a contribution, but not in
6:29 the way that some projects have done where they make it easy by kind of maybe keeping
6:33 issues around that remain unfixed, essentially like giving people a scratch pad to play with,
6:37 but like actually letting people easily contribute valuable work for us.
6:41 And then the other thing on the automation side is like we, we again, try and have as much
6:46 human review instead turn into like automated tests.
6:50 And to, you know, I guess there's chat in enterprise-y, software-y circles about shift
6:56 But basically what that means from like the Homebrew perspective is like what might have
7:01 started off as being a human says, Hey, I review your PR, please do X.
7:06 Then maybe turns into a CI check that says the same thing like automatically for you.
7:11 So a human doesn't need to be awake, but then we, we integrate with like your editor now.
7:15 So if you use like VS code, making a Homebrew formula or whatever, then we will provide in
7:20 line in editor without you having to do anything other than have Homebrew install guidance of
7:25 like what you should be changing and what you should be doing.
7:26 And if you have like auto formatting enabled, then you can literally like do the wrong thing,
7:30 press save and watch it like all jiggle around and automatically do its stuff, which I
7:34 still find very cool.
7:35 So all of that stuff, basically, I guess we've just tried to make it very, very easy to contribute
7:40 and try and eliminate that friction from the process whenever we can.
7:43 You're reading a ton about being a maintainer about, of course, helping contributors come
7:54 into the project.
7:55 Some of your, my favorite writing of yours is about contributor funnels and that myth that
8:00 maintainers can just tell people what to work on.
8:03 The technical aspects of automation and making it easy using the tools to get folks to a place
8:09 where they're contributing and it's meaningful to them is awesome.
8:12 But also there is a human perspective there.
8:15 How do you keep people motivated?
8:16 How do you make volunteers want to do this when you can't really give them deadlines or say
8:21 like, okay, well, this needs to be done first.
8:23 Like I, that's always mind-boggling to me for a project this size.
8:27 And that is depended on by millions of developers every day.
8:31 I mean, I think the, the short answer is, I guess, soft power instead of hard power.
8:36 Like, so like nowadays we have like a governance structure and I'm in the project leader and
8:40 I'm elected and blah, blah, blah.
8:41 So I have a certain amount of hard power in which I can say to people, I mean, I can't
8:46 really say you must do this, but I can say we will not do this.
8:50 Right.
8:51 We're not going to move forward wherever.
8:52 But in my mind, every time you do that, you sort of lose something a little bit.
8:56 Like ideally everything is a conversation negotiation and you convince people that it's the right
9:01 thing to do or they should work on this or whatever, rather than telling people what they
9:06 have to do.
9:07 And I guess one of the nice things about open source is like, you know what?
9:11 In the workplace, people also prefer to be told like, Hey, I'd like you to do X rather
9:17 than being like, I command you to do X.
9:19 Generally people don't like that very much.
9:21 And I certainly don't.
9:23 And I think that's the main thing.
9:24 I guess another big thing we do on Homebrew, which has made me in some ways and some places
9:29 on the internet, a slightly controversial figure.
9:31 And if you Google Mike McQuaid's low end swear word that begins with A, then you can find
9:38 quite a lot of people talk about how I'm not very nice to deal with.
9:42 But the reason why I'm sometimes not very nice to deal with is because sort of the reverse
9:46 of that contributor funnel, right?
9:48 So all of the maintainers of Homebrew use Homebrew, right?
9:51 And we can exist and happily use Homebrew and find Homebrew to be a useful tool, even if
9:57 no one else does.
9:58 But the problem is, is all of these maintainers who are doing this primarily in their spare
10:03 time, primarily either completely unpaid or essentially with a very small stipend that
10:08 in no way matches any sort of reasonable hourly wage.
10:12 Most children delivering newspapers are probably getting a better hourly wage than a homebrew
10:15 maintainer does for their work.
10:16 As a result, they need to want to do this stuff, right?
10:20 And if you deal with really unpleasant people being unpleasant to you, then you don't want
10:25 So in Homebrew, we have a very, very low level of tolerance for people being unpleasant.
10:33 And we would rather lose a potential future contributor, maintainer, advocate for Homebrew
10:38 or whatever, than we would lose a maintainer.
10:40 Because as I mentioned before, when you have millions of users and 30 maintainers, sorry,
10:45 we can afford to lose some users.
10:48 We can't afford to lose maintainers who burn out just because people are being unpleasant
10:53 to them.
10:54 So for me, it's, you know, like if you know me in my open source life or personal life
10:58 or whatever, like my take is I'm going to try and be nice and friendly and I try and let
11:02 people maybe treat me a little bit worse than they should.
11:05 But like if you come after my peeps, right, they're my people and I'm going to be defensive
11:09 of my people and I'm going to look after them.
11:12 And to me, like that's how you keep people involved, right, is people knowing that you
11:16 have their back when other people might be being unpleasant to them.
11:19 And I guess the second piece of that that's a little bit more recent that I feel like in,
11:24 you know, post-COVID remote culture, et cetera, that I think has been super important is like
11:28 we try and get together.
11:29 We generally have a homebrew like AGM that we try and coincide with like Foz them every
11:36 year just because it's most of our maintainers are in Europe.
11:38 It's a free conference and it's unticketed and people can just turn up and do as much
11:42 as they want.
11:43 And yeah, that like getting to meet people and know people face-to-face is always helpful.
11:48 I mean, that's a huge part of open source, right?
11:51 Is that ultimately it's a wider startup product development, et cetera.
11:56 Whereas like most of the time you're going to have more people who want more stuff than
11:59 And there's two ways generally of handling that.
12:03 One is to just tell them upfront, no, and people don't tend to like that, but it saves
12:07 everyone's time and they move on.
12:08 Or you make promises, which you just break.
12:12 And sometimes you break those promises by essentially having an issue that sits open for
12:16 10 years and someone's like, yeah, we was definitely going to do this.
12:18 And then no one ever does.
12:19 And is it not better to be told?
12:21 No, actually it turns out we're not going to do this.
12:22 And sometimes that stirs people into action as well.
12:25 Because again, an open source, as I'm sure people hate it when I say this, but I had never
12:29 written any meaningful about Ruby before I'd been involved with Homebrew.
12:32 I'd never really been a maintainer that reviewed anyone else before I did that in Homebrew.
12:36 And like, you can just do this stuff and learn it.
12:39 And if you really, really want it bad enough, you will find a way to like learn it and do
12:43 it right.
12:44 You mentioned Fostum and I absolutely love stopping by the Homebrew booth at Fostum.
12:49 Sometimes you can get a shiny sticker.
12:51 I think if you ask the right person, we have non-shiny stickers and we have shiny stickers
12:56 for people who either contributed or people who donate any amount of money.
12:59 So if you want a shiny one, that's how you get one.
13:01 Oh, awesome.
13:02 Oh, that's the secret.
13:03 But you'll also be at the open source zone at GitHub Universe this year.
13:08 So GitHub Universe is at the end of October, October 28th and 29th.
13:11 How was it last year?
13:13 Last year was great.
13:14 So it was myself and Patrick, who was one of the Homebrew maintainers, were there last
13:18 This year, it will be Patrick and Izzy.
13:20 They're going to have a really good time there, I suspect.
13:23 I guess one of the nice things about open source stuff in person is like rarely on the internet
13:27 do people say like, oh, hey, I use your tool every day.
13:30 I like it.
13:31 Whereas when people walk past a booth, they say that stuff and that makes you feel good
13:36 because often you don't get a lot of that.
13:38 But also just like talking to users of Homebrew and like problems they've had and things they
13:42 maybe don't know about and things that we can kind of do to improve.
13:46 And like, again, it's good from my perspective to get kind of a sense with your project that
13:51 maybe higher level things like so rarely do you get an issue that's just like Homebrew
13:57 feels slow.
13:58 Whereas when you talk to lots of people and like that's their main cause of concern,
14:02 It just feels slow.
14:03 So then we went away from Universe last year.
14:07 We had our AGM at FOSDEM and we were like, okay, like one of the main things we want to
14:11 focus on is Homebrew feels slow.
14:13 Let's make it not feel slow.
14:15 And we worked on a bunch of stuff in that direction.
14:17 And some of it is already landed and some of it's probably going to land like maybe just
14:21 before Universe actually in ways to make Homebrew both feel and be like much faster.
14:26 So like that type of feedback is really lovely to kind of get and be able to turn that all
14:30 the way through to like actual stuff that people are going to be able to use.
14:33 That's amazing.
14:34 I love that.
14:35 So see, folks, when you go to these conferences and you talk to the maintainers, things actually
14:40 Indeed.
14:41 You actually take it all in and take it back to the teams.
14:44 And listen, you still say no when you need to say no because you have to.
14:50 But I'm looking forward to meeting EC and Patrick.
14:53 Yeah, so the open source zone is a lovely corner of GitHub Universe where it's all different
14:57 open source projects get featured.
14:59 Every year there's a call for applications.
15:01 So there's a chance for any open source project to get a booth at GitHub Universe, which is
15:05 My favorite thing about the open source zone was just the conversations that sparked.
15:09 I remember just standing in the open source zone.
15:12 Mike, you called me over and you introduced me to this researcher I had to meet.
15:15 And she's been amazing.
15:16 And she did a lot of great work with different GitHub people since Universe.
15:20 So just the connections that happened in that space were great.
15:24 I love the serendipity of this stuff.
15:25 And I mean, I think it's something that's kind of wonderful about open source and tech
15:28 in general, right, is that often so many people are willing to help so many people.
15:32 And I've had a couple of people reach out to me in the last few weeks and be like, hey,
15:36 Bumbu did this thing.
15:37 We're a small open source project.
15:38 Can you give us some guidance?
15:39 I would encourage, again, anyone listening to this, you know, if you have questions like
15:44 that and you want to connect with another human and want them to maybe help you out,
15:48 then just ask.
15:49 They're going to say yes, probably a lot more than you think.
15:51 And also people like me will reply to your email a lot more than you think.
15:56 And we'll do what we can to help you out.
15:58 Okay, going into this topic, because I think that for folks that are listening to this and
16:09 have you in the same pestle I do, Mike, as the goat maintainer, right?
16:14 And so you've been maintaining this project for so long.
16:17 Of course, things have changed.
16:20 Earlier in the call, we're talking about how a lot, there has been a lot of happening,
16:23 obviously, in a span of 16 years.
16:25 So I have two questions there.
16:28 For one, I think, how does your, the way that you maintain this project change?
16:32 Especially, let's say, back then to now, since you become a father to, like, obviously,
16:36 priorities change.
16:38 Everything shifts a bit.
16:39 How has the way that you approach maintainership evolved?
16:42 And then for folks who are coming in, the new maintainers, you mentioned there's going to be
16:46 some new ones coming in, helping people become active maintainers, handing off responsibilities
16:51 and grow in these projects without losing that institutional knowledge is a challenge.
16:57 How do you do that?
16:58 That's definitely front of mind.
16:59 And that's definitely a thing that has changed over the years is how much I'm concerned about,
17:03 like, I guess what they might call the bus factor.
17:06 I guess for anyone who hasn't heard that, it's a slightly grisly definition, which is
17:09 essentially, like, how many people need to get hit by a bus before the project dies, basically.
17:15 And, yeah, there's certain parts of homebrew where I wouldn't say the bus factor is one
17:21 on anything, but there's definitely bits where, you know, you have a maintainer who's on holiday
17:26 for a few weeks and you realize, like, no one really knows how to fix this without them.
17:31 And it's, you're like, okay, this probably means we need a bit more documentation or whatever.
17:36 I don't really like writing very much, particularly documentation, but it's often, like, just really
17:42 necessary to do.
17:43 And often I find myself in a situation where it's, like, actually, like, okay, I could write
17:47 a bunch of code or whatever, but, like, probably the most valuable thing for me to do is to,
17:51 like, write down a doc, right?
17:52 So, for example, something that's on my to-do list right now is, like, we are a package manager
17:57 and we package software.
17:58 And on the internet, people use software to do a wide variety of things.
18:02 And we have been historically, like, on a case-by-case basis deciding, okay, like,
18:06 what might be too much violence or what might be too much stuff with, like, sex or whatever
18:11 for us to package it or not package it.
18:14 And again, you get the fun facts of being, like, an international project where you come
18:19 in not just what the project should be doing, but, like, individual maintainers' views on,
18:22 like, well, my country thinks sex is no big deal and violence is a big deal, or my country
18:27 thinks the other way around, or I work in a big corporation and we're going to probably
18:30 block this and we don't know what homebrews to get blocked.
18:32 And then people being like, well, if they block for that type of thing, then good.
18:36 So, like, all of these type of negotiations and generally, like, that is best suited by
18:41 writing down a document and then we can discuss something written down and then that can be
18:46 almost like it settled and moved on.
18:47 I guess related to that, I have become, particularly since becoming a father and spouse and stuff
18:53 like that. Like, I try to do less arguing with people on the internet, as satisfying as it can
18:59 sometimes be. It rarely achieves very much and I try to, like, I'm a pretty liberal use of the kind
19:05 of lock thread feature, not because I'm like, oh my goodness, if anyone else speaks here, the worst
19:10 thing would happen, but just because it's like, okay, look, sometimes we get to a point where it's
19:14 like, you're not going to change my mind, I'm not going to change your mind. Let's not go back and
19:18 forth on this. Let's just move on and you can take this to another place. For me, homebrew still
19:23 is not something which, at least directly, has ever kind of driven money into my pocket. So it's
19:30 like, it has to be something I actually enjoy doing and I don't really enjoy dealing with people who
19:34 are shouting at me or calling me names. So as a result, there's times where, I mean, literally for
19:38 me, other maintainers have different views. Like, if someone files a legitimate bug and they're just
19:43 being really mean about it, I'm just going to be like, well, I don't have any desire to fix that.
19:47 If someone else comes along and says like, me too, I'm affected by this and they can say it in a nice
19:52 way, then cool. I might help them. People say, oh, it's a marathon, not a sprint. But I kind of
19:57 genuinely think that about like open source. And I maybe have a blog post brewing at some point about
20:02 doing things for a long time. I was at GitHub for 10 years. I've been with my now wife for 23 years.
20:07 My best friend comes around to my house every week. We've been friends for like 30 years. And like,
20:12 I want to be able to still doing homebrew, still be doing homebrew when for 20 years,
20:16 maybe even 30 years, who knows, maybe even more if it still even exists at that point.
20:20 And what's going to keep me doing that is enjoying it and not burning out and all that good stuff.
20:25 And that also, I feel like helps me provide an example to other maintainers inside or outside
20:30 homebrew to similarly, like how to survive long-term in what's not always easiest environment.
20:37 Absolutely. Let's print all of that out and put it in a t-shirt.
20:39 You know, I haven't stopped and thought about the fact that, yeah, this is obviously a global project
20:46 and you're dealing with not just the way that you approach building software, but how it's done
20:53 anywhere else in the world. And you have to take all of that into account of how you manage a project
20:57 this size. So that necessary community management key. And listen, folks, Mike's been doing it for 16 years.
21:07 We'll take some notes. You definitely know what you're talking about.
21:09 You mentioned GitHub and homebrew sort of growing up together and like you were one of GitHub's early
21:15 employees. I'm really curious to hear your thoughts on how GitHub's relationship with open source
21:20 projects like homebrew have changed over the years.
21:23 Yeah. I feel like it's sort of goes up and down, right? Like, like anything does. But I mean,
21:28 fundamentally for me, I think the open source community is in some way forgotten that like it,
21:34 and I guess from having been on the on-call rotations on GitHub and stuff, like lots of people use
21:39 GitHub and lots of resources are given away for free for open source. And I feel like in some ways I can be
21:46 more defensive of GitHub in that way than I was. Maybe when I was an employee, when people were like,
21:50 oh, you're just paid to say that. And now I'm not paid to say that. But like, particularly now with
21:55 GitHub actions minutes and stuff like that, there's a huge amount of infrastructure that is available
21:59 between, I don't know, GitHub actions and co-pilot and repo hosting or whatever. In the early days in
22:05 which I was doing open source, like all of that stuff had to be built individually for each project.
22:10 And it had to be maintained by people and they were getting woke up in the middle of the night if
22:14 things went down and all this type of stuff. And like now you don't have to do that for the vast
22:20 majority of projects and you have a vast amount of very high level impressive technology available
22:26 mostly for free. And that's great. To me, like that's the foundation of the relationship between
22:32 GitHub and open source. It's just like the stuff that is given away for free and used for free.
22:36 And you know, GitHub benefits from that as well, because that's how GitHub grew. Like GitHub grew
22:41 essentially by convincing a bunch of open source projects, you should use this. And then a bunch of
22:45 business followed from that. I also think I guess the relationship, it's depends what GitHub is
22:51 particularly passionate about at any given time and how much that aligns. So if you're a big fan of
22:57 co-pilot, which I am personally, then you're probably quite excited about what GitHub is doing with
23:02 co-pilot right now. If you don't care about that, like if, if all you live in is GitHub PRs,
23:07 then I can understand why you might get frustrated when the PR page is either slower or not getting
23:12 faster or quick enough or whatever it may be. And so, yeah, I think like that's maybe how stuff
23:17 changes over the years. And I guess finally, like, you know, GitHub is part of Microsoft now and
23:21 it's like a big, bigger, more grown up company. And you can't just necessarily message your friend
23:26 that works there and get stuff sorted that way. But there's good things about that and bad things
23:31 you read about using AI as, you know, good out of complete. And, you know, you just mentioned that
23:43 actually, yeah, you are, you are a fan of co-pilot. You review thousands of contributions to the project
23:49 that they're saying. Have you seen the quality of the contributions change? What can we do? How can we
23:55 help maintainers when we're wanting to use AI tools? So I think on the maintainer side, there's some stuff
24:00 that's there already. Like, I think like the co-pilot code review, it's not a replacement for
24:05 a human, but it definitely catches certain cases in a way that's really helpful and saves time for a
24:12 human sometimes. It's funny, like pre all the current AI wave, maybe like 2018, one of my blog posts called
24:17 Robot Pedantry Human Empathy, kind of about this, where I was talking about how people will accept a
24:23 robot or I guess now an AI being super pedantic about like, oh, you made a typo here and here and
24:29 here and here and here. Whereas when your human co-worker does that, you tend to think that they're
24:33 just rather annoying. So I think like leaning into stuff like that is quite helpful. And I guess
24:38 different people have had different experiences. I feel like I've had probably a pretty good experience,
24:42 maybe because I know the homebrew code base so well with like assigning issues to co-pilot. The fun
24:46 thing is, if you want to go see, you can go and look because it's all on the public record of the PRs.
24:49 I think I just two to three months ago assigned every bug on homebrew on the package manager side,
24:54 at least to co-pilot just to see what would happen. Right. And what happened was they all got fixed.
24:59 Did co-pilot get a hundred percent of the way there itself? I don't think in any of the cases it did,
25:04 but it certainly saved me a lot of time and would get between 50 and 95% the way there on the first
25:11 time. And then with a couple of prompts get probably 60 to 99% there. And then what I do is I then just
25:19 go and take over, take the wheel and then finish off the last bits. And that was still very helpful.
25:24 Particularly with dealing with, I guess, people talk about it with writing a bit more like the kind
25:28 of blank page problem of like, okay, there's about 10 different ways of fixing this bug. Like I can't
25:32 decide which one to do. And then I'm just like, okay, right, co-pilot, you pick, and then I'll fix
25:36 whatever you try and do. And I also think with homebrew, we maybe benefit a little bit more with that
25:42 stuff because we were early adopters of like GitHub's like issue, mandatory issue templates. In fact,
25:47 I feel like part of the reason this got built is I just whined so much about it internally for such a
25:52 long period of time. One of the nice things about that is like, you know, we, we get people to provide
25:56 step-by-step reproduction instructions in that. And then the AI model can then go and see that and
26:02 just essentially do what the person has told them to do to find the bug and then do it again to find
26:08 the repro. So yeah, stuff like that is kind of helpful. I guess on the human side, like I wouldn't
26:12 say we've had a marked level of almost like contribution, either improvement or decline.
26:18 Probably I think the cases where people are using AI tooling locally themselves very well is not
26:26 visible. And I think that's fine. Like personally, I don't care if you did a hundred percent of the work
26:32 or copilot data or clone code or cursor or whatever, as long as you as the human have given it a once
26:38 over and been like, okay, like this looks good, or I'm going to tweak this or whatever before you want
26:44 a homebrew human to review it. That's fine with me. In my mind, that's the key to successful AI usage,
26:49 right? We're still, I think we probably will be forever, but we're still in the era where a human
26:55 needs to be in the loop somewhere. You need to have a human review the output before their coworkers do
27:00 it. And if you get very good at code review, then you are more likely to get better at doing that with
27:06 an AI as you would with a human. But in some ways, the interactions feel pretty similar. Even a human
27:11 who's not using AI, we may go through like five or 10 rounds of back and forth in a PR. And then
27:17 eventually, provided I have the permissions on their fork to do so, I'm just like, look, I'll do the last
27:22 bit, right? Rather than me trying to tell you what code to write, I'll just go and write the codes and
27:27 then we can merge the PR and we can move on. Sometimes that final little bit, it just makes
27:30 sense for the maintainer to jump in and do it. Yeah. So Mike, bummed we won't see you at Universe
27:35 this year, but if someone listening goes to the open source zone, stops by the homebrew booth,
27:40 what should they say to Issy and Patrick? First, assuming you use homebrew, say thanks, good job. But then
27:46 after that, I just encourage you to, in a nice, polite, respectful way, like say, what things about
27:52 homebrew would you like to see be better, right? And they will collect that feedback and we'll do better
27:58 with that. My also tip for that with feedback for homebrew or any other technology process is to try and
28:04 focus when you're saying that on the problem that you're experiencing and not the solution that you
28:09 perceive. One of the perils you have of having technical users, whether you work at GitHub or we work on
28:15 homebrew or whatever, is people who can write code themselves tend to jump straight from I have the
28:20 problem to I can see in my head what the code should be to solve the problem. I'm going to tell
28:24 you that. But like, if you don't know the homebrew code base, like the back of your hand, which you
28:29 probably don't, then it's more helpful for people to know like what are the pain points of the problems
28:33 you're experiencing rather than what you perceive the solution to be.
28:41 Well, let's move to the section where we all share an open source project that we're excited
28:45 about. Mike, you're our guest. Are you ready to go first?
28:49 Yeah, so I've got like a bit of a deep cut actually right now. So there's a tool called
28:54 SOMO, S-O-M-O. It's under the GitHub user Theo PFR, who's Theodore Pifer, I think, a 24-year-old
29:04 programmer and student from Munich. So it is a cool little application written in Rust that shows what
29:11 ports on your local Mac are open and closed. And this is a very niche thing that you probably only
29:21 need every few months. But like if you accidentally end up starting your Rails server or MySQL server or
29:27 something like that on a port, and then another thing is like saying, hey, I can't open this port
29:33 because this other thing's got the port, then this is a very nice, easy way to figure that out. It's a
29:38 cool little tool that I've liked recently.
29:39 Thanks for bringing this up. Starting it right now. Boom.
29:42 Andrea, do you have yours?
29:45 Yes. This just so happened to be a Microsoft in-source project that was just released, I guess,
29:51 a couple of weeks ago, the spec kit, that toolkit for us to start thinking about spectrum development and
29:57 utilizing that methodology with the help of AI to basically ship faster. I'm excited to use it. I think
30:04 it's great that we're investing on beyond the AI tools themselves and ways to help the humans work
30:11 with the tools better. So now we're moving into a world where, yeah, everybody has the power of
30:18 co-pilot or whatever your preferred tool is. Understanding spectrum development, understanding
30:24 the who, the what they have beyond the immediate problem and the code is huge. So if you're an
30:30 entrepreneur or if you want to be, I think it's a good approach to building software. What about you,
30:36 Abby? What's yours?
30:37 Mine's a deep cut. I came across it recently. It's a super old project, but my friend,
30:42 my friend Luke, he made CSS Diner. It's flukeout.github.io. Flukeout's his handle. And it's
30:49 like just this fun little tool to help you learn CSS. And there's this little animation of like
30:54 plates dancing. And it tells you to select the plates. And then you learn how to use CSS to like
31:00 select it. It's really fun. It's a nice way to learn how to code like CSS at least. And it's kind
31:05 of old, but I wish I want to see more projects like this. This is why I bring it up. I want to see
31:09 people make fun educational tools.
31:12 Abby, I love this. This is so cute. And then it even has a help I'm stuck. So it gives you like a
31:18 little, yeah, this is a great little tool. I love this. Shout out to that human.
31:21 Well, to everyone who's been listening, this has been the GitHub podcast where we talk about the
31:26 topics, trends, and culture around the open source community on GitHub. My name's Abby. You can find
31:31 me at abbycabs, most places on the internet.
31:35 I'm Mike McQuaid, everywhere on the internet. Pretty much mikemcquaid.com is my blog where you
31:41 can find links to posts and talks and social stuff and all that good stuff.
31:46 And I'm Andrea Griffiths, a la Columbia Dev in all places. I'm andreagriffiths.dev. That's
31:52 my site. And it's been fun to be here with you two. Thank you. This was delightful.
32:01 Thank you.