Inside Modern Software Engineering with Homebrew’s Mike McQuaid

20 August 2026

Interviewed by Giant Robots Smashing Into Other Giant Robots

Sami is back this week with Mike McQuaid as they take a deep dive into the importance of open source maintainers.

https://podcast.thoughtbot.com/619

Show transcript

0:00 Hello everyone and welcome back to another episode of Giant Robots Smashing Into Other
0:11 Giant Robots, the podcast where we explore the design, development and business of your
0:17 great products.
0:19 Now today I am joined by Mike McQuaid, Administrate CTPO, Homebrew Project Leader, an engineering
0:26 and product leader with 18 years of experience reducing developer friction and scaling open
0:32 source software used by tens of millions.
0:36 How do I find you on this morning, Mike?
0:38 Yeah, very good.
0:39 This morning always feeling slightly cringy after my intro that my American co-workers
0:45 in the past have helped me to write because apparently my previous one was far too humble.
0:50 But yeah, otherwise good.
0:52 How are you today, Sam?
0:53 Yeah, I'm doing good.
0:55 As we mentioned, kind of off air, it's a strange one with England recently going out
0:59 the World Cup.
1:01 I'm happy this is not a sports podcast.
1:03 We don't have to deal with that too much.
1:05 But often what I do is I try to do research a bit about my guests before they come on.
1:10 I mean this as a compliment that it was particularly difficult to do research on yourself because
1:15 there's so much out there.
1:17 Like you're doing lots of talks, you're writing lots of articles.
1:21 How would you package yourself?
1:23 And this is going to be even more cringe than your intro.
1:25 How would you, if you were me, how would you have introduced yourself?
1:30 Oh, I mean, probably similarly, right?
1:34 I guess for me, what I've found interesting.
1:37 So I've had an interesting kind of career in open source, if you can call it, I guess, career
1:43 in inverted commas.
1:44 And then a parallel kind of career doing proprietary software, various companies, right?
1:50 And I think for me, it's been interesting seeing the commonalities between the two and what
1:54 each can learn from each other and how they can feed into each other.
1:58 And also the very stark differences between the two.
2:01 So I think more recently, maybe my talks, blog posts, et cetera, are either I'm trying to
2:08 speak to both audiences or I'm trying to explain to both audiences why the other audience is
2:13 very, very different from what they might expect.
2:16 But those, so those worlds, so just so people understand, so if I'm correct, you're talking
2:20 about open source, you mainly are working with Homebrew, which is a package manager for
2:26 macOS that helps people to kind of install third-party software.
2:30 It might do more than that.
2:31 That's how, that's what my usage is of it.
2:34 And then you're also working with Administrate.
2:38 Are you saying those two worlds, which seem quite disparate, actually influence and intersect
2:45 with each other?
2:46 Yeah.
2:47 So I think there's commonalities there.
2:48 I mean, I guess the thing that might be surprising to anyone, maybe not surprised to you, Sammy,
2:52 might be surprising to some of the listeners, at least on this, is Homebrew, package manager,
2:57 used by a bunch of people using Macs, although increasing numbers on Linux and Windows now too.
3:02 But I have never been paid to do that as my full-time job ever.
3:08 Homebrew has never had enough money to ever have essentially an employee.
3:11 Like, I probably have had three-month periods sporadically when things have intersected with
3:17 my employer and homebrew such that I've been able to spend the majority of my time doing
3:21 homebrew-related stuff.
3:22 That's probably happened two or three times in my 17 years or whatever working on it.
3:27 So, yeah.
3:28 So those worlds are pretty separate from that perspective.
3:31 And, you know, I have an old-day job.
3:32 I'm a CTPO now, which is Chief Technology Product Officer.
3:37 I've got like, I don't know, 20-something people under me in the org.
3:41 And, yeah, so I guess, okay, so what, in my mind, what are the differences between the two?
3:47 I think they're fairly, some of them are fairly obvious.
3:49 Like, one of them is for money.
3:51 The other is either no or essentially close to zero money.
3:57 But I think the commonalities there are more interesting, I guess, as you mentioned.
4:03 So I think, so I spent 10 years working at GitHub.
4:06 I ended up being a principal engineer there by the time I left.
4:08 And they were quite into early on of like working quite like an open source project in lots of ways of,
4:16 you know, being a bit more self-directed.
4:18 People work when they want to work.
4:19 People communicate primarily asynchronously in writing on GitHub or, like, I guess,
4:26 particularly later on, like a chat or whatever.
4:28 But, like, the expectation was not we will resolve all problems in a meeting, right?
4:33 If anything, there was quite a lot of cultural pressure, particularly early on, to not do that.
4:38 And I would say that's kind of similar in open source as well.
4:41 And I think what the two worlds can learn from each other, I guess,
4:45 like particularly a lot of the companies I've been at is, you know,
4:49 we're in this post-COVID world where a lot of us had never done any remote work really before COVID.
4:56 Well, I was fortunate enough to have done it since 2009 exclusively.
5:00 But we have a lot of companies now who work at least somewhat remote some of the time.
5:05 If you're also a big enough company that you have people in, say, the U.S. and Europe, right,
5:10 then those companies can really benefit from that open source, writing-centered, asynchronous way of working, right?
5:20 And in my experience, many companies, maybe most companies, suck at that because no one really told them or explained to them how that should work.
5:30 And also different parts of the company have strongly positive or negative associations with let's write everything down and do everything async as opposed to let's have meetings to resolve every problem.
5:41 That's really interesting because I did a podcast a couple months ago with a senior developer, maybe even a principal, from 37 Signals.
5:50 And they operate heavily on like this async policy kind of the way they work.
5:56 And one of the things she said to me was like, it was really, really hard to get used to.
6:01 You're basically writing a lot of things down and there's very little kind of synchronous communication.
6:08 But she was kind of describing like the power of it.
6:10 And we do work a lot like that at Thoughtbot as well.
6:12 We're kind of set up as a remote company.
6:14 And a lot of decisions and things are done through even pull requests on GitHub where we can have discussions and track those discussions.
6:23 It's a really good way of working.
6:25 I want to drop back to when you talked about Homebrew and kind of being an open source maintainer.
6:32 I've never spoken to an open source maintainer before, but I've used your things.
6:38 I don't know if I've ever appreciated that you do everything for free.
6:42 Like, what does that look like?
6:43 Because how much time are you giving to this project?
6:47 So, I mean, the time is really variable and probably very hard to measure because a bunch of it is multitasking, right?
6:58 Because there'll be times where I'm waiting for some CI on a work thing.
7:02 And I'm like, well, I could just stare at a wall, right?
7:06 Or I could quickly review and merge a Homebrew pull request or whatever, right?
7:10 So, that's a hard part of it.
7:13 I guess there's also – I made a little mini site recently called the Open Source Resistance that was essentially spelling out how I and a bunch of other maintainers, many of whom didn't want to be specifically named, work.
7:24 Which is like, that's how I've done the majority of my Homebrew work probably for the last 10 years is my employer has not specifically said, right?
7:31 You can spend 20% of your time working on Homebrew or whatever.
7:34 I've just done it.
7:35 They've known about it and they've been fine with it.
7:37 And the specific amount of time on a given day, a week, a month is variable and not documented or written down or whatever.
7:44 And that's fine with them and it's fine with me, right?
7:47 And, you know, different companies have different approaches on that.
7:50 But I guess my idea was like, okay, this is actually how most open source happens, right?
7:54 Like, we talk a lot about evenings and weekends in open source maintenance, but certainly if you're like me and you're married and you have a family and stuff like that, then the evenings and the weekends become a little bit of a tougher sell.
8:04 So, I don't do as much in evenings and weekends now.
8:07 I do more during the day.
8:09 But back to the specific, like, the payment side of things.
8:11 Yeah, I mean, so basically, like, Homebrew – it's funny because I've been working on it for so long.
8:15 Like, Homebrew, when I started, has essentially no costs.
8:18 It was just a project on GitHub and everything was done with our local machines or the machines of the contributors and that was that.
8:25 And then over time, we have costs.
8:28 So, alongside costs, we did fundraising and donations and all this type of fun stuff, right?
8:35 But we're in this slightly awkward middle size right now where we get about, I think, roughly about $100,000 a year.
8:42 We probably, you know, spend but a reasonable amount of that.
8:47 And some of it, to increase the amount that we are spending, goes to, like, some proportion of maintainers.
8:54 If you're active enough over a three-month period, each quarter, you're entitled to a $900 stipend, basically, which equates to $300 per month, which, for at least the amount of time that I put into Homebrew,
9:06 I would imagine most 12-year-old children who do paper rounds get better dollar per hour of their outputs than I am getting.
9:13 So, it's definitely, it's a, like, a nice thank you, here's some of our money.
9:18 But we're not in a place that we can afford to pay someone full-time.
9:22 But then what drives you?
9:24 What's driving you to do this?
9:25 And I know that might sound like a really shallow question.
9:28 No, it's a really important question, I think.
9:30 Yeah, I want to understand it.
9:31 So, I mean, originally, like, back when I got started, so I guess in some ways, my open source, like, career, if you will, right?
9:38 So, I got into tech relatively traditionally, went to university, studied a computer science degree, fell into the, you know, the habit that is Linux on the desktop.
9:50 When I got to university, like, got very involved with, like, well, I was an active, I guess, participant in forums and IRC channels and bug trackers and whatever.
10:00 Started dabbling with some code of my own.
10:02 Got involved.
10:03 I was, shortly after leaving university, I became a maintainer of, like, for a few years of KDE.
10:09 Like, I contributed through that, through Google Summer of Codes.
10:12 I was then involved with KDE for a few years, and then that kind of dropped down, and Homebrew kind of picked up and sort of took over.
10:19 But as a result of that, it's like, so something they used to say a lot when I was getting started that I rarely hear now, and I wish I heard more, is people would be like, how do I get started in open source?
10:28 And the advice everyone always gave was scratch your own itch, right?
10:32 So, find a problem with an open source project that you yourself have, and go and fix that problem, right?
10:38 And we are, I mean, this is a longer conversation, I guess, but we are lucky enough in the age of AI and LLMs that if the project accepts AI and LLMs, and if you're respectful and careful with how you use, it's never been easier to scratch your own itch with the project you use.
10:55 And, basically, that's how I got involved.
10:57 I started doing that, and Homebrew, in Homebrew's case, I sort of built a sort of clunky version of Homebrew myself.
11:05 I saw Homebrew, I was like, this is much better.
11:06 I switched to that.
11:07 I started using it, and I was like, I found problems, so I fixed the problems, and then I just never really stopped doing that for 17 years.
11:14 But, I guess, the motivation of, like, why do I do it now, my probably biggest thing there is because I enjoy it, right?
11:20 Like, I do it because I find it fun, and I find it enjoyable.
11:24 And, again, I think that's a helpful framing, because I think it can't and doesn't need to be fun for every single maintainer every second of every day, but it needs to be fun more often than not.
11:37 When I go to my lovely wife at the end of the day, and I've been doing a bit of other stuff, it needs to be that it's something that lifts me up and doesn't drag me down.
11:46 If I'm going to be grumpy with my children in the evening or whatever because I'm grumpy about something that happened today, if that's paying my bills, then, okay, that's not ideal, but it is what it is.
11:57 If that's something where I'm, like, literally not really getting paid anything, and certainly the time and energy and personal expenses I put in, I'm probably spending more of my own money than I am getting, then that's not sustainable, right?
12:08 And my wife and friends and family, whatever, have told me a few times over the years, it's not sustainable, and I've made changes, and that's why I'm still doing it and haven't burned out and all that good stuff.
12:17 Yeah, that's amazing to hear because there is a lot of conversation about burnout in the open source file.
12:24 Like you're saying, you're giving a lot of time.
12:26 It's probably costing you.
12:28 Is there anything, then, you've learned over the 17 years that, you know, you could share or you wish you would have known when you started that would have been helpful tips?
12:39 In a funny way, I think I was really lucky to get a lot of those pretty early.
12:44 As I said, like, I, you know, I had the early experiences working with KDE.
12:48 Like in the period in which I was a contributor, I attended this KDE conference that was called Academy with a K in the Canary Islands in, I can't remember what year it would have been, like 2008 or something like that.
13:00 And the other funny thing about that conference, that time in that year, was they co-located it with the GNOME conference.
13:07 So if you're not a Linux person, like, you might not be aware that essentially, like, KDE and GNOME are almost like the big competitor kind of desktop environments, right?
13:16 And in some ways, it would be, like, Apple and Microsoft both being, like, our company off-site this year, I guess maybe not even them, like, more like, right now, OpenAI and Anthropik being, like, okay, let's host our company off-site together and collaborate together and whatever, right?
13:31 And it was, like, that was a bit of a, like, mind-blown sort of moment because, again, like, often the people online, the conversation would be all of these GNOME users fighting with all these KDE users about, you know, GNOME sucks and KDE rocks and vice versa, right?
13:44 But the actual people involved are happily collaborating together in a way.
13:48 But the other big thing was, like, you saw that there's so many friendships and relationships and whatever, and I guess I realized quite early on, maybe it took me a while to articulate it, but, like, the people working on KDE are not doing it primarily for the users.
14:04 They're primarily doing a lot of what they do for their friends who also work on KDE, right?
14:09 So, actually, what you need is not, it's kind of, you know, we always go on about work.
14:15 I'm sure you've had the same county of, like, you know, you need to think of the customer and the user and blah, blah, blah.
14:19 I actually think in open source, you maybe need to do a bit less of that, right?
14:22 And think of the maintainers.
14:24 How do you build good relationships with other maintainers that have good interactions and have those people be your friends and your support network and whatever?
14:30 Because at the end of the day, if there's an issue that's kind of urgent or whatever, I'm going to fix that for my maintainer friend who I've had a bunch of beers with in Brussels at Fosdheim over the years more quickly than I am going to do it for some random user.
14:43 And in fact, that random user, they might be like, this is going to cost us $10 million as a company if this isn't fixed by tomorrow.
14:49 And I'm like, again, a privilege of open source.
14:51 I'm like, I don't care.
14:53 Like, that's not my job to fix your stuff.
14:56 Like, that's your job to make sure your stuff is fixed.
14:59 And that's the way open source works.
15:01 But if it's my friend asking me for help, I'm going to help them.
15:04 Yeah, there definitely is a bit of tension there.
15:07 When using open source, you do see, like, people open issues, want things to be fixed, but then don't necessarily contribute to the fix or aren't willing to open a PR when a maintainer says, that's great.
15:18 Thank you for finding it.
15:20 Can you have a go at trying to fix it?
15:22 What do you wish they knew or understood about maintainers that might make that relationship a little bit more comfortable?
15:29 So I think the, I wrote a blog post about this a while ago, right?
15:34 That was rather inflammatoryly, if that's a word.
15:38 Yeah.
15:39 It's not, I invented it.
15:42 Named open source maintainers owe you nothing, right?
15:45 And the, in some ways, the reveal is in the title, right?
15:49 But what I draw into is, if you look at the license of basically any open source project, what it says is, it's essentially like a EULA, right?
15:56 Like, we have all these, when you use various bits of software, you've got EULA or your terms of service or whatever.
16:01 And back in the days when we were using desktop software, you had to click through this license agreement in the installer in order to install the software, right?
16:08 Open source actually has the same thing, right?
16:10 And if you read that, like, and as boring as it may be for some people, I encourage you, if you use open source, even more vaguely regularly, right?
16:17 Pick a nice short open source license, like the MIT license or whatever, and read through it from top to bottom.
16:22 And then actually think about what that means and articulate it.
16:24 So some spoilers, if you haven't read it already.
16:27 It basically says, we disclaim all warranties, all guarantees of fitness for use.
16:31 What does that mean in human speak?
16:32 Basically, this might not work, and we're not even saying it does work, but you're agreeing that through your use of this, if it doesn't work, and if it blows up and causes you a huge mess, that's not our problem.
16:44 Like, we've said that's not our problem, and you've agreed that it's not our problem, right?
16:48 And that is not how most users of open source, and frankly, most maintainers of open source view it.
16:54 But if you can view things through that lens, both sides can have a much more productive relationship.
17:00 Because, again, so, again, another random, I don't mean to bang on about my blog posts, but, like, for me, it's often when I've thought about something for a while, that's my main output, right?
17:11 So my father-in-law is a professor of economics, right?
17:14 And we had a nice chat about, like, economics in open source and whatever, right?
17:19 And he was saying, which surprised me as a newbie who's never really studied in economics, is that economics is not always about money, right?
17:27 We generally talk about it from the realm of money.
17:29 It's about the, I can't remember what his exact words were saying, the use of constrained resources, right?
17:36 And in a capitalist economy, that's usually money.
17:39 But the interesting thing in open source is it's not money, right?
17:41 Like, people love talking about money in open source all the time.
17:44 As someone who's brought a lot of money into open source, partly through Homebrew, partly through, I was one of the four people that built GetUp sponsors, right?
17:50 Money is great, and it solves a lot of problems.
17:53 It also introduces some new problems, and it also doesn't fix all the problems you think it's going to, right?
17:57 And in the case of open source, money is not the constrained resource, right?
18:02 So say a project like Homebrew, I mentioned before, we make about $100,000 a year.
18:06 If you give an extra $100 to Homebrew, firstly, thank you very much, that's kind, that's going to help us run the project.
18:11 But that does not magically unlock X percent more maintainer time, because if you think about how it works, it's, I can't remember the mathematical term or whatever, but essentially, you need to hit a threshold at which someone can afford to take something currently in their life, probably that they're being paid to do, and say, I'm not going to do that.
18:29 I'm now going to do this open source stuff instead.
18:32 And that doesn't happen for a lot of projects a lot of the time.
18:35 So actually, the constrained resource is maintainer time.
18:39 And actually, if you dig before even that, like, because maintainers are doing it in their free time, it's like maintainer motivation, right?
18:46 So if you're one of those people, and there's one in Homebrew at least every day, who just drops some drive-by negativity on an open source project being like, this sucks, your message sucks, I don't like your response to this, thumbs down, thumbs down, thumbs down, whatever.
18:59 Like, I literally am not exaggerating when I say you are doing your bit to destroy open source, because you have just made it less likely that that maintainer wants to do any fucking open source today at all, because it just, it makes them feel rubbish when they receive that type of feedback and that type of input, right?
19:18 So that's basically the most important thing is like, again, it sounds very, it's tough to swallow.
19:23 But if you're an open source user, you are less important than the maintainers by a long way, right?
19:29 Homebrew, we estimate we've got about 10 million users, they've got 30 maintainers.
19:33 So it's like, so if you do those numbers, if you're a user, like, if you want to get something done, you need to invest disproportionate amounts more of your time in order to get your needs met than the maintainer does to meet your needs.
19:46 So a good example, going back to what you said before, if you're someone opening an issue, and it's really important to you that that gets resolved, right?
19:53 And you maybe don't have the skills or the time or whatever it may be that you think to fix that yourself and kind of make a contribution, the best thing you can do is open a really, really good bug report or an issue report that's like, here's, and if you're a project like Homebrew, like, we've done half the work for you because we have a mandatory issue template where we give you all the, we basically require you to enter all the information that we know that we need to do that.
20:19 Again, first step would be, if you think you know better than us on the information we need, you are wrong, just do what you're told, give us the information we need.
20:27 Don't pick your battle on the first issue you open.
20:30 But basically, if you can open an issue and you can say, look, every machine I've tried this on, if you run this command, this command, this command, this is what happens, this is what the output is, this is what I would expect the output to be, this is why it's surprising, this is why it's important.
20:43 And you can do that all in a nicely worded, respectful way, then that is, particularly with AI agents now, that is very, very easy for the maintainer to fix.
20:52 If you are vague, if you are lazy, if you are, like, disagreeable, if you are rude, any or all of these things make it dramatically less likely that anyone is going to be interested in spending any time trying to fix your problem.
21:03 And I think the biggest cause of open source burnout, frankly, is maintainers who bend over backwards to help people who are not willing to put in the effort, and in some cases are not willing to be kind, respectful, considerate of the maintainers and their time and the gift that they have given to open source through doing their work.
21:19 Yeah, when you, it's been so funny, because this conversation to me is, it doesn't surprise me at all, what does surprise me is, like, seeing these open issues or open PRs, where, almost like trolling, the way you speak about, like, kind of the thumbs down, or the all or nothing thinking, like, oh, this is terrible, we could do it in this way.
21:43 So, lack of gratitude, it's almost more of a human problem than it is a coding problem.
21:49 It is, but also, I think the thing with these types of human problems is, there's two ways of looking at it, right?
21:58 There's, like, the, I need to fix how millions of humans interact, or you can be like, I'm going to fix how I interact, right?
22:07 So, in my case, what that looks like on Homebrew, and the culture that I think I sort of somewhat started, but is very much the dominant culture there, and why I think we don't have people burning out, is if you are someone who opens a completely legitimate issue about an actual bug, and you are very rude about it, we will close your issue and often not even respond to what you're saying.
22:27 And if you are so unbelievably rude, you will get blocked, and you will never get unblocked, right?
22:32 And people might think, but that's a bug, you need to fix that, that's outrageous behavior, whatever.
22:36 And it's like, no, because that person is, I guess, the constrained resource I said before, maintainer, like, motivation to work on open source.
22:44 That person is doing significantly more damage than they are solving, right?
22:48 When you're borderline, my experience, and again, this actually works well in lots of areas of life, if you can calmly and politely explain to that person, like, hey, that's not cool, please don't do that, right?
23:01 If they then respond with, even, you know, some people grow up, they're young, they've never heard a good apology in their life, they're going to give a, I'm sorry you feel that way, blah, blah, blah, whatever.
23:10 But if they're even vaguely trying to actually apologize and be like, okay, I will do better next time, right?
23:18 Then you can sometimes fix those and get to a productive place, and that, you know, and maybe you don't block that person, whatever it may be.
23:25 Whenever that person doubles down, and they say, like, how dare you, like, or whatever, or they're like, you know, who are you to tell me how to submit this issue on your open source project?
23:35 We just block them, because literally never in my entire open source experience have I seen a relationship go from that to a productive one later on.
23:43 And also, again, as I mentioned before, there are lots and lots of users of Homebrew, right?
23:47 We can afford, of those at least millions of people, we can afford to block quite a few rude people along the way, because at the end of the day, again, with a project like Homebrew, an important principle we say to people as well, is to be a good maintainer for Homebrew, you must be a user of Homebrew, right?
24:02 Like, if you no longer use Homebrew, if you stop using it at work, whatever you're using, where you work somewhere where you use Nix, and you don't ever touch Homebrew anymore, like, no hard feelings, but you're not well placed to be a maintainer anymore.
24:14 Like, you're not going to have that spark, you're not going to have that connection to the user, because you're no longer a user.
24:18 And what that helps us do is say, okay, well, as long as we have 30 maintainers, we have at least 30 users, right?
24:25 We can afford to lose everyone else, and in reality, we're never going to do that.
24:30 We're never going to be so unbelievably outrageous that we lose everyone else.
24:33 But I think it is important for people to understand that, like, that's where we're at.
24:37 And the alternative model for a lot of projects is the maintainer just goes, like, nah, had enough, closed, archived, whatever.
24:45 I'm not going to deal with this person, this project, whatever, ever again, right?
24:48 It does happen, yeah.
24:51 And I actually think that's a good thing, personally.
24:53 Like, I don't think it's a good thing that the community makes that person feel that way.
24:58 But every time that someone quits, I'm like, good, healthy.
25:02 It's probably, you are probably well beyond the point in which this has become a positive thing for your life, and you should move on, right?
25:09 And if the community goes like, oh, but you've left me in the larch or my supply chain or whatever, and it's like, well, sorry, that's your problem, right?
25:16 And you should have thought about that before this person was at that point.
25:21 Yeah, it's a really interesting phenomenon because I don't know any other industries that operate with such reliance on, like, people they don't know who are giving free time to keep lots of things running.
25:37 I think if people really knew about this, people who, let's say, don't work directly writing the code or in the software, I don't think people will realize how many systems that's through the NHS banking systems are being upheld by open source software like this that is maintained for free.
25:55 And if it was to disappear, there would be a lot of trouble.
25:58 It's funny, because I don't know that I know as many industries like that.
26:02 But again, maybe something that helped me with open source is I used to be, I'm no longer, I used to be a fairly religious guy.
26:11 And I, you know, the church in the UK that I was involved with, various churches of the years, do a lot of voluntary work, right?
26:19 And they do stuff, you know, most of them would do things with, like, youth work, they do stuff, work with homeless people, they do work with, like, music that I was pretty involved in and stuff like that.
26:30 And you see in these environments, like, there's, it often is, if you squint enough, like, vaguely looks a bit like some bits of open source software, because you have, you know, like, say, like, a big, whatever it might be, like, a church service, or a homeless, like, soup kitchen, or whatever, you may have a very small number of people who are on a payroll to make that happen, right?
26:57 But most of the time, most of those things could just could not occur, were it not for a lot of volunteers, right?
27:04 And the closest equivalent I can think of with some of these things would be, like, if the majority of people that came along to a soup kitchen were very abusive to the volunteers in the soup kitchen, a lot of the time, then the volunteers in the soup kitchen are probably going to be like, nah.
27:21 But the irony is, right, is that I think, and my experience in those environments is we actually, like, often, not to get on a political soapbox, but often, like, homeless people or people with kind of substance abuse difficulties or whatever, are able to behave at a higher average standard in terms of the, how nice they are to the volunteers who are helping them out.
27:45 And despite the fact that most of those people's lives are in some of the hardest situations imaginable, but yet some of the highest paid tech workers in the world, arguably some of the most privileged people, like, in the entire 8 billion people we have on earth, are not able to meet the same sort of standard.
28:03 And that is the bit that continues to be truly wild to me.
28:08 It's just the way some people will behave, particularly the way some people will behave when they literally have a GitHub profile with their actual face, their actual name, it's attached to their actual employer, and they will say and do just outrageous things, right?
28:22 And it's sometimes not even outrageous things, sometimes just like that, just, like, drumbeat of just, like, unpleasant negativity that they wouldn't, I would hope that they would never do in person, right?
28:33 But, you know, who knows?
28:36 The soup kitchen analogy is actually really good, because you would have no qualms or criticism if the soup kitchen decided to shut up shop because of, like, the levels of abuse that they were receiving.
28:48 Do you think it's got worse over the years, like, you've done this for 17 years, have you noticed, like, kind of these keyboard warriors, has it, is it getting worse, has it been getting worse?
28:57 I don't think it's got, I think, to be honest, I think the big, and I worked at GitHub for 10 years, before I worked there, I applied for three times before I got a job there, right?
29:06 Like, I was and am still a fairly big fanboy of GitHub, right?
29:12 But, I think it's the one thing GitHub made much worse, unintentionally, in open source, is the accessibility of open source maintainers.
29:21 So, again, back in my KDE days, if you wanted to go and say, hey, KDE Delapro, you suck, right?
29:28 Like, you had to sign up for a mailing list, or sign up for a Bugzilla account, or whatever it may be.
29:33 And for each individual open source project, you have to follow a completely different flow, right?
29:37 You still got some people that did that back then, but then, again, similarly, a lot of them got banned very quickly and moved on.
29:45 And there also wasn't, you know, that was pre or at least very early social media.
29:51 So, you didn't have this thing where, like, a thread goes viral on social media or hacker news or whatever.
29:56 People were, like, jumping in for the lols and whatever, right?
30:00 And people, like, I mean, some people on GitHub, and I know because my name isn't a bunch of them, like, literally almost, like, curate lists of, like, ha-ha, open source drama, right?
30:08 Like, and I don't know, I think, I think more or less probably since GitHub got fairly mainstream in the kind of mid-2010s onwards, right?
30:19 It's, I don't know that it's got, yeah, it's not really got better or worse than that time.
30:24 It's just been this sort of steady background noise.
30:27 But, again, like, the unfortunate aspect of human psychology is even if one in 100,000 home new users are unpleasant in their interactions with you, like, that is enough to sometimes just, like, when I was younger, that can ruin your day, that can ruin your weekend, right?
30:43 Yeah, for sure, for sure.
30:45 And that, it's kind of like a double-edged sword, which is, like, the accessibility to these projects and to the maintainers is a good thing for people who want to get involved and help.
30:55 But it's also opening the door for people who, like you're saying, want to be critical or abusive, which kind of leads me to another double-edged sword in this area, which I've been thinking about, which is AI.
31:08 Because on the one hand, like you mentioned it a bit before, like, it's never been easier to contribute.
31:13 So, people can, without as much knowledge as they used to have or without knowledge of the exact syntax, they can start to really help open-source projects with, you know, using AI in the right way.
31:27 But then we're also seeing lots of people in open-source maintainers just having to sift through too many PRs.
31:35 They're just having to reject and reject and reject because they're just, you know, one-shotted by AI.
31:39 So, what's that experience been like?
31:42 So, I think it's been, I feel probably neutral to positive about it.
31:48 I think a lot of what AI has done, like, inside open-source and also inside technical organizations is it's changed the bottleneck, right?
31:58 The bottleneck for a lot of things used to be a human sitting down with a keyboard and writing the code.
32:02 And that's no longer the bottleneck.
32:04 And depending on what your other bottlenecks were or are, I think, is how good or bad you're having a time right now.
32:13 So, on homebrew and bar, I mean, in general, like, in everywhere, like, I have always been obsessive about, perhaps many would have said, excessive levels of automation.
32:22 So, I used to say to homebrew maintainers, if you leave the same review comment on three PRs, I want you to turn that into an automated check, right?
32:30 And just this idea of, like, you're going super, super hard on, like, I guess, you know, we're both Rubyists, right?
32:35 Homebrew has maybe 100 plus, at this point, custom Ruby cops that only apply to homebrew, right?
32:40 Oh, wow.
32:41 That's a lot.
32:42 Well, and the funny thing is, AI has made it dramatically easier to write more of those as well, which is great.
32:49 Because previously, I used to be, like, a bit of a hypocrite, where I was like, you should write a Rubicop for this.
32:54 But then whenever I sat down to write a Rubicop, I was like, oh, ASTs.
32:58 Like, this is so much easier to just do with regexes in a disgusting way.
33:02 But doing it the Rubicop AST way is the right way of doing it.
33:06 And now it's become considerably easier to do it the right way.
33:08 But the nice thing about that is, like, if you, so there's that, like, I guess, in AI speak, we would say deterministic guardrails.
33:16 Like, Homebrew was very good at having lots of deterministic guardrails well before, like, the current kind of AI wave took off.
33:24 And we continue to kind of lean into that even more.
33:27 So, like, it's been great from, like, a personal output perspective, where I mentioned earlier we have a fairly rigid issue template.
33:35 One of the benefits of that is most issues, most of the time, I would say now, like, I think, let me have a brief check live on the current count of, like, on Homebrew Brew, which is the, like, main Homebrew issue tracker.
33:47 Yeah.
33:48 So, right now, there are no open issues on Homebrew.
33:51 And that doesn't mean that there's no bugs.
33:52 But, like...
33:53 Nothing has been reported and hasn't been handled.
33:55 Nothing has been reported that hasn't been handled relatively recently.
33:59 And a big part of that is because more or less my default flow now is an issue comes in and I assign it to an agent.
34:06 And when I read the issue, if I'm like, oh, like, their proposed solution is not quite right, I add an extra sentence on the end that's basically like, and instead of doing this, do this.
34:15 Like, and I would say 50% of the time, I get a perfect solution out first time.
34:20 Right.
34:21 Perfect as in if a user as a first-time contributor came along and this was the diff in the PR that I reviewed, I would say, thanks, approved, merge.
34:30 And that would be it.
34:32 But, yeah, so, like, that's been great.
34:34 I think the kind of AI slot PR, it's interesting because it's a very variable spectrum because there's some people who come along and do first-time PRs now, which previously would have been like, this level of quality in a first-time PR is like a once every six months to a year thing.
34:48 And we're probably seeing this once a week now of just being like, these are really good.
34:53 Partly, that's all the guardrails we have.
34:55 Partly, that's all the, you know, we invest in our agents.md and in the repo and stuff like that.
34:59 But then there is the downside of people that come in and open PRs and they don't really understand what they're doing.
35:06 And I get the impression whether or not it's true that essentially every response that I'm getting is just, Claude, Mike has asked me this, tell me the answer, coffee, case, it's the issue.
35:17 And at that point, and again, like, this is when it comes back to the personal boundaries type thing.
35:21 At that point, I am more than happy to say, yeah, like, look, this is, it feels like I'm just talking to an LMP here.
35:29 If I'm going to be talking to an LMP, I'll talk to my own one on my own machine, and I can have the back and forth there.
35:35 And sometimes I'll just, people have essentially described what they're doing in the PR and the bug they're fixing.
35:40 And instead, I'll just copy, copy, paste, copy the bug that they're doing it, open my own agent, do that, open the PR, say to them in that PR, sorry, this was no longer a great use of either of our time.
35:51 I've opened my own version, which is better.
35:52 It's going to replace your version and you're not going to get credit for this this time.
35:55 I would imagine that would not fly for a wide variety of reasons on a lot of projects, but that's the workflow that I think actually makes a lot more sense, right?
36:02 And like that, that's, we have to do stuff like that so that the project can be sustainable.
36:07 And I think that's part of it.
36:09 So also we have automated bots where we have this issue template format, AI as well, to not fill in the issue template.
36:16 So we have a bot that if you don't fill it in, just automatically close it because we can't mandate the template being used and you open it through the API, which is something that basically only applies to it.
36:25 Yeah, yeah, yeah, yeah.
36:26 So yeah, so we basically have a bunch of stuff now, including some of the features that GitHub have provided.
36:31 So essentially just like reduce the velocity of slop input and auto-manage some of that.
36:35 But even then culturally, we had pre-AI the expectation that like, if you have an issue that it's just like, you've been very lazy, you've not put thought into this and you've not added the information, we're not going to say, oh, please, would you mind doing that?
36:47 We just close it.
36:48 And often we just don't even respond, right?
36:51 And if the person says, why did you do that?
36:53 Again, if it's patently obvious, again, even that might not get a response, right?
36:57 Because again, we don't actually owe people any of this stuff.
37:01 Yeah, yeah, you're not there to serve them.
37:03 I'm wondering, can you shed some light on this?
37:05 Because it's not something which I understand, but given what we've spoken about, like, what do people mean then when they say like, oh, AI is going to replace open source software?
37:14 Like, what do they even mean by that?
37:15 And is there any accuracy to that statement?
37:18 Yeah, so I think there's almost two, like, variables that may be talking about there, or two changes.
37:25 So one of them is, I guess, the bit that you mentioned or alluded to before, which is that the incoming slop wave slash mythos-powered security vulnerability wave to all of these projects is just going to make open source so unbelievably fun right now that all of the maintainers are going to leave and stop doing it, right?
37:46 But that's a problem.
37:47 That's not a solution.
37:48 Yeah, but again, I don't think, I think that's overstated.
37:53 Well, I don't think that's actually going to happen, right, to be clear.
37:57 I think it will happen with some projects and some maintainers.
38:00 And as I say, I think it's some of those cases that's maybe good, because I think it's just open source is changing.
38:07 As it changed when GitHub got introduced to a different way of working, we're working in a different way now.
38:12 You might not want to work that way.
38:13 And I have absolutely no issue with anyone that doesn't want to work that way.
38:15 And they should shut up shop and work differently.
38:18 Or if they don't want to accept AI contributions, like, personally, I would think that is a mistake.
38:23 But every project maintainer has every right to do that.
38:26 And I actively encourage those who don't want to wade through those PRs, don't do so.
38:31 I think the other part of it is, I think it's more interesting, and I think we see less evidence of, but it's this idea that, like, well, I'm using this NPM library.
38:42 I may be using 10% of the capabilities of it.
38:44 The maintainer hasn't merged any PRs or bug reports or issues in a while.
38:49 So I'm going to just get my AI to reimplement the 10% I need and vendor that in my project, and that can be code I maintain.
38:56 And then I don't need to worry about this, right?
38:57 And same with all the kind of open source supply chain stuff.
39:00 I'm just being like, well, like, I, rather than me having to, like, keep up with the pendable every day, week, month, whatever,
39:07 and all these critical vulnerabilities that are constantly rolling into my thousand dependencies that I have in my JavaScript project,
39:13 like, I'm just going to get most of those and throw them in the bin and re-implement myself internally.
39:19 And so I think that may well, in some ecosystems, reduce the use of some types of, like, NPM modules or open source projects or whatever.
39:29 I also don't think that's necessarily a bad thing.
39:31 But I guess the reduction would add a certain there is, like, are we saying that the Linux kernel is just going to be forked 8 billion times
39:39 and everyone is going to be in every version of the kernel?
39:42 Clearly they're not going to.
39:43 So I think if you zoom out, it's like, well, what does open source exist for?
39:49 Like, why do we care about this stuff?
39:51 And I guess, so something like Homebrew, it's like, okay, package manager on macOS, like, you know, many of your listeners may know what that is or means or whatever.
40:00 But it's like, the way I sometimes would describe it is it's an abstraction layer to install a bunch of different software
40:08 that has a bunch of different ways of being installed on your machine.
40:11 And we essentially provide a unified API to do that, right?
40:16 So it's like, is every company going to maintain their own version of that unified API?
40:22 Probably not, right?
40:23 And is there an advantage in us pooling knowledge and resources and interfaces such that if you're a macOS developer and you go from company one that uses Homebrew to company two that uses Homebrew,
40:34 and it works the same way in both places.
40:36 And if I want to install my SQL on my machine, it's going to be functionally identical from company A to company B.
40:42 Like, is that advantageous to the industry?
40:44 And it's like, well, yes.
40:46 But a lot of these things, I think it's a pendulum swinging moment, right?
40:49 Where, like, again, I remember when I entered the industry and it was still a decent number of companies,
40:55 particularly in places like the UK, particularly in bigger organizations,
40:58 were not trusting the source software for things.
41:00 But, like, everything we get needs to be bought from Microsoft or even libraries.
41:04 You would buy a library.
41:05 The vendor would deliver the binaries.
41:07 You're not allowed to look at the source.
41:09 And you get the binaries and the docs.
41:11 And then if there's an issue, you're just like, I'll send them an email and in a year they'll fix it, right?
41:18 And that sucked in lots of ways.
41:21 And we entered this open source world where, like, oh, we can all contribute and share and isn't that great?
41:25 And then, you know, like, I don't mean to pick on the NPM ecosystem,
41:29 but, like, it has made it easy with some of these things because I think they swung the furthest to the extreme
41:35 of, like, of tiny little modules that do every possible thing and shrinking everything to that,
41:42 to the smallest degree that could be trivially re-implemented by almost any engineer in any situation, right?
41:48 And we went all the way to that end.
41:50 And it's like, actually, that has its own share of problems such that some companies or people who, you know,
41:58 have been in the industry a wee while look back at the, like,
42:01 I pay a vendor for a binary and some docs with, they're like, that's, those days were better than the days where
42:09 every project has a thousand plus dependencies, right?
42:12 Like, and I think that's what it is.
42:14 I think AI, for good or ill, whether you like it, whether you hate it, whatever,
42:18 whether you want to use it or not, whether you think it's good for the world, destroying the world,
42:22 AI is just the latest in many, and this will not be the last either,
42:26 in many pendulum shifts that mean that things are swinging back, right?
42:30 While I'm on a little bit of a rant about that as well, but again, it's the,
42:34 I remember the days where people were saying, not, you know, maybe not open source, maybe pivoting,
42:39 but like being a, someone, I graduated from my CS degree in 2007, going to the industry,
42:44 working, wanted to work as a software engineer, and being told,
42:47 that's a really stupid thing to do in the UK, because within five years,
42:52 all of the UK software engineering jobs will have been outsourced to, like,
42:56 cheaper companies in East Africa or India or whatever, right?
42:59 And AI has just become, you know, I think we've accepted now that AI is not going to take everyone's jobs,
43:04 but in six, 12 months ago, it was the same thing.
43:06 It's like, why would you possibly qualify as a software engineer now?
43:08 The AI code agents are going to do it all for you.
43:10 And it's like, well, is that going to be true?
43:13 Probably not, in the same way that it was before.
43:15 Is it going to change everything in the same way that arguably outsourcing to other countries change things?
43:20 Yeah, probably it will, right?
43:21 But we'll adapt, we'll change, we'll do things better, we'll do some things worse, we'll move on, et cetera.
43:28 But before we go, I've got one last question, which I wanted to pick your brains on,
43:34 because as a father of four kids, my oldest being nine,
43:39 and begging me to stay up 2 a.m. is when the England-Mexico game was,
43:42 and I said, not a chance.
43:45 You've talked a bit about screen time as a parent yourself,
43:49 and you had quite an interesting take.
43:51 Can you give me a little bit more information about that?
43:54 Yeah, so my screen time take kind of comes from being a frustrated 90s nerd,
44:00 where my, again, back in the day before,
44:03 going to software seemed like a reasonable career choice,
44:07 and my parents basically being like,
44:09 you're wasting your life on this computer thing,
44:11 like, it's never going to amount to anything, whatever.
44:14 And also, like, I guess, in a rainy Scottish winter evening,
44:19 when they were like, go play outside instead of spending all your time on the computer,
44:23 at 6 p.m. in the evening, and it's like,
44:25 clearly I'm not going to do that,
44:26 so can I play computer games for another 30 minutes?
44:29 So I always wanted my kids to be, like, a bit more chill about it.
44:32 In fact, for those who have the benefit of video,
44:35 you can see in the background, I actually have my Steam Deck is now,
44:38 I bought a USB-C monitor now, so that my eldest child, who's, I guess, going to be nine in a month,
44:46 can play, like, real PC games with a keyboard and mouse, which he is absolutely delighted about.
44:52 But yeah, so, and then I went off, and again, much to people's surprise,
44:57 perhaps I married a physiotherapist, right, who has differing views from me on screen time and exercise, whatever.
45:02 So essentially, the middle ground that we get to is we try and almost think on, I guess, maybe two dimensions.
45:08 So one dimension is almost like, in a given day, what's the balance of screen time to other things, right?
45:13 So I think both of us as parents would rather our kids maybe had three hours of screen time in a day,
45:19 which is quite a lot, if that means they had six hours running around in a park,
45:24 or doing outdoor stuff, or whatever, when the weather's nice, and, like, exhausting themselves doing other things, right?
45:30 Like, that's kind of a nice balance, right?
45:32 And that might be better than two hours of screen time, but the rest of the time, they're just sat inside, staring at a wall, or whatever.
45:40 So that's the first dimension.
45:42 The other dimension is almost like, I think not all screen time is equal, right?
45:48 And this is where I get my apologies in advance, maybe a little bit preachy,
45:52 in that I think this section applies as much to the parents as it does to the children, I'm afraid.
45:58 In my mind, as a gamer, I'm somewhat biased here, but, like, I essentially have a hierarchy where I'm like,
46:05 okay, to what extent are you thinking and involved in whatever?
46:10 So for me, my personal screen time use, I would say, like, the highest on the spectrum of my screen time
46:15 is either, like, stuff that I find incredibly relaxing, playing computer games, where I'm engaging my brain, whatever,
46:22 or stuff where, like, I'm making money doing it, or I guess we've talked about homebrew.
46:26 Like, when I have fun screen time doing homebrew stuff, lots of other people get to benefit from that.
46:31 And then below that, I would say it's almost, like, passive, but yet still enjoyable entertainment,
46:36 like sitting on the sofa with my wife, watching our latest Netflix show.
46:40 We just finished The Diplomat, which was very good.
46:43 And stuff like that, right?
46:44 And then below that, I would put, like, doing a similar thing, but maybe on my phone, by myself,
46:50 in a corner, right?
46:51 Or particularly maybe short-term, short-form content that's been algorithmically recommended for me
46:57 that I don't particularly want to watch, but I've just been slurped into that, right?
47:02 And then, you know, you can work your way down on that hierarchy.
47:05 And essentially, we try and think about both what we're doing as parents,
47:09 but also what our kids are doing along those hierarchies.
47:12 So I would not give my kids for an exceptionally long time a phone that had TikTok on it
47:17 because fundamentally, I just think that's going to be bad for their development.
47:21 And they don't need it.
47:22 Like, if they want to do that when they're 18, they can do that when they're 18.
47:25 Maybe slightly younger.
47:26 That's fine.
47:27 Not when they're nine.
47:29 But stuff like them playing computer games or them doing creative stuff on an iPad or whatever,
47:35 like, I'm more willing and able to kind of entertain a bit more of that and encourage that.
47:40 Same with us sitting as a family.
47:42 Like, we have watched over the last year all nine of the main Star Wars films of various degrees of goodness.
47:49 Good going, yeah.
47:50 But yeah, but it's like, but all of those were like, we sat down as a group and what, well,
47:54 my wife chose not to partake.
47:56 But the three boys, me and my two sons, we sat down, we watched the Star Wars films.
48:00 It was a nice, bonding moment.
48:02 And yeah, like, that feels, like, more positive than spending the equivalent amount of time
48:07 individually looking at something on our phones.
48:10 You can create, like, I think people forget that as a family, you can create special memories
48:15 in different ways.
48:17 And one of those mediums can be through screen time.
48:21 Gaming is, some of my best memories have been from gaming as a kid, probably spending too
48:27 much time playing Call of Duty and play Lego.
48:30 But it was a good time to be alive.
48:32 Look, we've hit time, but thank you so much for your time on this podcast.
48:38 And also, I think it's fair to say your contributions towards Homebrew, I use it extremely often.
48:44 That's my package manager.
48:46 And so to speak to someone who is, you know, given their time to make things so easy for
48:50 everyone else, a lot of appreciation.
48:54 If people have listened to this episode, interested in yourself, want to get hold of you, perhaps
49:00 want to even contribute towards Homebrew.
49:02 What's the best way they could do that?
49:04 Well, so if you're interested in me and what I've been saying, you can go to my website,
49:07 which is mikemcquade.com.
49:10 And yeah, that's basically, I've like, the joys of AI, I've essentially built my own like
49:14 little Twitter clone that's like built into the website that cross posts elsewhere.
49:18 So if you see me on social media, and you reply to me, I probably won't see it.
49:22 But if you go to my website to my email, send me an email, I'll reply and listen, whatever.
49:26 If you're interested in Homebrew, if you go to the main Homebrew package manager page on
49:30 GitHub or our website, which we'll link you over there, which is homebrew slash brew on
49:35 GitHub, or the website for Homebrew is brew.sh.
49:39 And if you go to kind of contributing on there, then it will kind of explain to you like various
49:42 ways you can get involved and the best kind of ways of getting started.
49:45 But as I said, the best way of doing it is like, if you use Homebrew and you're like,
49:49 this should work differently, it'll be better or whatever, then give it a go, make it better.
49:53 And I'll probably review your work.
49:55 And hopefully I'll like it.
49:57 Just do it with a little bit of respect, people.
50:00 We'll drop some links, things that we've spoken about into the notes of the podcast.
50:04 You can find notes and a complete transcript for this episode at giantrobots.fm.
50:09 If you have questions or comments, you can email us at host at giantrobots.fm.
50:14 Don't forget that Thoughtbot we're here as consultants and we can help you with your technical
50:19 needs, technical challenges.
50:21 So if you need to reach out to us, please do.
50:23 This podcast is brought to you by Thoughtbot.
50:26 Thanks for listening and I'll catch you on the next one.