Mike McQuaid of Homebrew on Sustainably Working on OSS Projects

15 April 2022

Interviewed by SustainOSS

Mike McQuaid shares on the history of Homebrew, his involvement in open source, boundary setting, and what software sustainability means for him.

Show transcript

0:00 Hello and welcome to Sustain, the podcast where we talk about software sustainability
0:15 for the long haul. Who are we? Where did we come from? Where are we going? It is just
0:20 me today. I am Richard Littauer. Hello, everyone.
0:24 And our guest today, my guest today is the illustrious Mike McQuaid. Mike is calling
0:31 from his home in Edinburgh. I'm calling from my apartment in Edinburgh that I'm staying
0:36 in right now. So this is kind of weird. We could have met in the same room. Mike, how
0:40 are you doing in general? Are you okay meeting like over a mile distance like this?
0:45 Yeah. Yeah, I'm good. It also feels weird, but then it occurred to me, I don't think I've
0:48 ever actually done a podcast in person. So in a funny way, that would be more strange
0:53 disturbing. It would be very weird. Yeah. Yeah. Well, hopefully one day that will happen
1:00 again. Now that COVID appears to be less of an issue and freak out as it was two years
1:05 ago, we are getting better at it, although it is still around. It's still a problem. But
1:09 this is not the COVID podcast. This is the podcast where we focus on open source sustainability.
1:13 So Mike, you've been around in the space for a long time. Right now, you are a principal
1:20 engineer at GitHub. You are the homebrew project leader.
1:23 Maybe you can set me some context. What is homebrew just to start?
1:27 So homebrew is a package manager for originally macOS and now for Linux as well. So its original
1:37 goal was just a means to be able to install open source software on your Mac. I think the
1:42 original tagline was the missing package manager for macOS because various people talk about
1:47 how compared to Linux, say, at least for a Unix system, macOS does not really ship with a proper
1:53 package manager. So yeah, and it's evolved over time, as I mentioned, to do things such as supporting
1:58 Linux and supporting installing binary packages like Chrome and various other bells and whistles
2:04 and as the ECOS system has got wider and the user base has grown.
2:08 So to be clear, this isn't a package manager for a particular language like NPM. This is much rather a package manager where in on your
2:16 terminal in OS X, you can just download programs very easy. You don't have to worry about dependencies or which thing you're getting. It just gets the ones you want.
2:24 Indeed. And we're a somewhat weird package manager in that we sit somewhere between the two. So normally people would classify, as you say, like language package managers, NPM and PIP, whatever it may be. And then system package managers like AppGet or Pac-Man or whatever it may be. And we're kind of pretending to be a system package manager, but we don't actually affect the system.
2:49 We're all in our own little bubble. And that has pros and cons. The pros being for us as maintainers at least is there's only so badly we can break your system compared to on a Linux package manager where you can stop it booting. We can't stop your machine from booting. Thank goodness. But then on the flip side, we still are responsible for a lot of the stuff on the system. And we still have to, when Apple rolled their happy updates every year, have to fix and work away around all the breakage rather than be able to control that tightly ourselves.
3:19 It sounds like a massive amount of work. Now, what you've been saying also has a couple of things hidden inside of it. You mentioned that you didn't know the original tagline. I think it was the packet manager for OSX, like you said, or something. I don't remember it either. But you don't remember because you didn't create Homebrew in the beginning, although you are the lead maintainer, one of the lead maintainers now. Can you tell me a bit about how that happened?
3:40 Yeah. So it was originally created by Max Howell. So he was an engineer working at, I think, Last.fm in London at the time. And I think he was whining about package managers in the pub, I believe. And someone told him, if you know so much, why don't you go create a package manager?
3:59 Yeah. So he did. And because he was a lover of beer, it has a kind of beer sort of theme around the package manager, hence Homebrew.
4:09 Yeah. And I think Max had been working on it for maybe six, nine months or something. When I first discovered this, we had sort of mutual friends in common. We were both in this sort of London tag scene at the time. And I had been writing a thing for Mac ports to sort of try and hack it into doing what Homebrew does, i.e. like not building all the system dependencies.
4:30 So I just wrote sort of shims that pretended like some dependencies were installed on Mac ports. And yeah. And then Homebrew came along and that seemed like a better fit for what I was doing. So yeah, I've worked on it ever since, since I guess 2009, I think.
4:45 And then Max was involved with the project for a few years, left the project a bit later on, still in sort of sporadic private conversation with Max and stuff like that. He's still been involved in the kind of package manager space of the years. He was involved with the creation of the Swift package manager and now is doing some Web3 thing called T that I don't fully understand, but that's his latest package manager thing that he's working on.
5:11 Really loves brewing things. I have had several conversations. I had one this week and back with someone who's like, why is there money going to a single homebrew? Are we paying brewers or something? Yeah. So I like the name. I think it's great. Thank you for giving us that context.
5:25 Now you are the homebrew project leader at GitHub, which strikes me as weird because GitHub, as we all know, is primarily a web app. It's where you push stuff and it's a big repository of software.
5:41 Why do they need an OS X related package manager? And how did that happen?
5:46 Yeah. So that's interesting because people always tend to assume the two roles are more entwined than they actually are. So we were chatting internally about some GitHub open source stuff recently.
5:58 I mentioned that there's only been two of the eight years in which I've been at GitHub where any part of my job has involved writing stuff for homebrew. So those sort of live in separate, but somewhat overlapping domains in that homebrew is a very heavy user of GitHub.
6:17 It was perhaps one of the first kind of GitHub native open source projects that really leaned into the kind of GitHub contribution model before GitHub was as big a thing for open source as it is today.
6:28 And on the flip side, GitHub has always been a fairly, not universally, but a fairly kind of Mac centric development environment place.
6:37 So there was sort of some alignment between the two, but it's, yeah, my job at GitHub is not, and has never been essentially, you know, maintaining homebrew while I'm there or making homebrew work great for GitHub or whatever.
6:50 Like there's a few times that there's some overlap there and a few times that I'll spend work time on homebrew stuff or whatever.
6:57 But yeah, just they're somewhat separate rules.
7:00 Okay. That's really interesting. I guess a question I would have to follow up on that is, did you have to convince your higher ups to let you work on homebrew as open source during company time?
7:10 Or do you just sort of do that just in the interest of what you're already doing?
7:13 Or is there some way that you can help maybe other developers think about how to pitch?
7:17 I already knew this open source work is relevant to the company. Here's how you can sustain me and also help the company's interest.
7:23 I think that's really interesting because it's something where in the last few years with coronavirus, people have probably more able to relate.
7:32 But so one of the other things in my kind of career that has sort of somewhat mirrored my open source work is I've been involved with some sort of open source since university, basically.
7:42 But with homebrew, almost, I think pretty much the whole time I've worked on homebrew, I've also worked remotely.
7:49 I've not worked in an office since 2009. Again, I think the same year that I started working on homebrew.
7:56 And particularly the last probably nine or 10 years, I've been working for US-based companies from Edinburgh.
8:02 And if you know anything about time zones, then you'd know that those time zones are not the same.
8:06 And as a result of, I guess, distributed time zones and remote working, I have not had a relationship with someone who can come and look at my screen and see what I'm working on or judge my productivity by how many hours in the day my posterior is sat on a particular chair for a pretty long time.
8:27 So as a result, it's kind of been sort of at my discretion to spend my time how I think is appropriate.
8:33 And yeah, as a result, I have basically the entire time I've been at both those companies spent some proportion of my work time on homebrew.
8:41 If that sum became 100% and I was meant to be doing other projects, then that would become a problem.
8:47 And equally, if that became 0% for me for long periods of a time, because I felt any pressure to do so, that would probably also be a problem for me personally.
8:56 And it would be when I would start looking for other jobs.
8:59 But yeah, there has been short windows of time in which that has been like 100%.
9:03 So I guess relatively recently, like homebrew's binary packages, basically our pre-compiled packages, so you don't need to build them on your own machine, were hosted by Bintray.
9:12 And Bintray, with relatively short notice, said that they were shutting down, which would have stopped all our binary package twisting.
9:18 I proud of some feelers to various companies, including GitHub, about a potential solution there.
9:24 And it just so happened that kind of the GitHub packages team were like, yeah, you could do this on GitHub packages.
9:30 So that involves me spending a reasonable amount of time and work time to migrate homebrew over, partly from the perspective of we use homebrew internally, this would be good for us to use homebrew internally.
9:40 But also, like, we use GitHub packages, and we're trying to have more adoption of this.
9:45 And if you genuinely think it's a good fit for homebrew, and you want to use that, then that would be good for us as well.
9:52 And we can sort of, you know, work internally on some modifications to make that look as nice as it can.
9:58 But again, the funny blurred lines here is that, again, there's sometimes misunderstandings on both sides of the aisle where some people on homebrew's side may think and have, in fact, accused me of in the past of, well, you only think we should use GitHub packages because you're employed by GitHub, and they're telling you to think that.
10:14 And equally on the GitHub side of, like, well, homebrew needs to do this, and I could tell you this because I work at this department in GitHub, and neither of those fly terribly well.
10:23 It's strange having a split brain like that, but I do try and fairly firmly separate what I think is best for homebrew and what I think is best for GitHub, and try and balance those two things.
10:35 And again, if I ever had a situation at work where I felt that I was being forced by GitHub or any other employer to do what was not right for homebrew, then I would probably leave that job.
10:45 Interesting.
10:46 I think the main takeaway I'm taking away from this is it's not always clean cut where open source and work relate, and sometimes one just needs to choose what the priorities are.
10:58 Now, it sounds to me like you're particularly good at making those sorts of judgments in your head, which is excellent.
11:03 I am particularly bad at them, probably just because that's who I am as a person, but also just something I've realized over time.
11:09 I tend to focus myopically on one thing and forget everything else, and I wake up and my house is on fire.
11:14 So it's good that your house hasn't burned down.
11:17 I would like to talk about how you do that effectively through boundary setting, which is one of the things you have on your blog.
11:23 But before we get to that, I think there's a bigger question, which is more important, which is homebrew sustainability and what your role is at homebrew.
11:31 Because if you were to dedicate all of your time to it, it would suck up all the time available.
11:35 That's how open source projects work.
11:37 But you've decided not to do that and to have another career that just pays you the normal money that you need to survive.
11:43 So what I'm curious is how you've taken homebrew from being a project where you sort of joined in with Max and you figured out how it would work to a project where you could actually dive in and out with an understanding that it wouldn't suck up everything.
11:56 So can you help me explain about homebrew's sustainability journey in that sense?
12:01 So I think there's two sides to the sustainability conversation, and I'm glad that you sort of touched upon either both of them, if not slightly more emphasized what I consider to be the more important side.
12:14 So I guess there's, in any open source project, too many conversations I've seen about sustainability focus on money.
12:20 And ultimately, money can sometimes be turned into time from humans, but not always, and not always the right time from the right humans.
12:32 And I think homebrew's financial improvements, which I've been involved with as well, have been very useful.
12:38 And it would be hard for us to run the project exactly as we do today if all our funding dropped up.
12:44 But I think you're right to focus on almost like the people side of things.
12:47 So let's start with that.
12:48 So yeah, when I started working on homebrew, I think there was me and Max and one other maintainer or so.
12:55 And like the kind of number of maintainers has sort of fluctuated, but slowly grown over the years where it's went from single digits, probably two, three, four years in, probably gone to double digits and sort of maintained sort of low to medium double digits.
13:11 And yeah, I see that kind of almost like funnel of people as being an important part of our sustainability.
13:20 So it feels to me like just a fact of life that in open source, some people are going to get involved, maybe very intentionally for a short period of time and then wander off.
13:32 Either their life segment has changed, or in some cases, they just, they had a particular problem they really cared about and they fixed that problem and then they move on.
13:39 But also you have the people who've been around the project a little bit longer may well understand certain things about the project that newer, more enthusiastic and more time rich people may not.
13:51 So we've tried to kind of balance that by, we try and have always tried to look out for almost like who would be a good maintainer, like who is kind of providing more value to the project than they're kind of withdrawing.
14:04 And not withdrawing in terms of usage, but withdrawing in terms of they don't need loads of handholding and they're able to work independently or maybe even like help others and give them a bit of handholding.
14:15 So generally those people are good candidates for maintainers.
14:17 And then we also look at pipelines, like we've had a fair few maintainers come in through programs like Google Summer of Code and Outreachy and major league hacking and stuff like that.
14:27 And yeah, and then we also try, I guess the other side of that is, I just did it yesterday.
14:32 I have effectively a yearly task to look at our list of maintainers, look at who has commit access to wall and re-ask, even though it can be a little bit awkward, who still needs commit access to the project.
14:43 Because a project like us, like anyone with commit access is security risk is too strong, but if they are not using that kind of access, then that needs to be kind of reconsidered.
14:53 So, yeah, I think just kind of nurturing that group of people and trying to kind of grow that kind of community within a community over those years has been helpful.
15:05 And then I guess I've seen myself move in a kind of mentorship of contributors to kind of more nowadays kind of mentoring other maintainers and trying to help our maintainers get better at what they do.
15:19 Because one of the advantages I have, I guess, with what I said before, with the kind of split brain stuff, is that I've learned a hell of a lot about how to make Homebrew better from working at GitHub.
15:28 And things, concepts like feature flagging, for example, were alien to me before I'd worked at GitHub.
15:34 I maybe read about them, but I hadn't really seen their value.
15:37 And then that's something now that we can do, you make use of in Homebrew.
15:41 And I've almost been able to sort of filter that out to other people as well.
15:45 Feature flagging, I will look that up.
15:47 I like the way you're framing this less is about, well, this is how we went out and then we got money from this person.
15:53 And much more, no, it's all about the people involved and all about the mentorship.
15:56 And you're right about this prolifically on your blog.
15:59 Well, maybe not prolifically, but very adequately.
16:01 So in a sense that you don't put out new articles every single day.
16:06 There are people who do that.
16:07 So the mentorship diamond is something you talk about, how to start mentoring.
16:10 You also famously, for me, because I reference it all the time, mostly on this podcast,
16:16 wrote a thing called Stop Mentoring First-Time Contributors, where you basically said,
16:20 first-time contributors may not stick around.
16:22 And wasting your time on them is actually wasting your time, right?
16:26 Because if you don't know they're going to stick around, spending all that time, it's just going to end up with burnout.
16:30 Open source feels like an endless support war.
16:33 How do you win that war?
16:34 You set boundaries and say, this is where I'm going to advance my time and so on.
16:37 Or you could not use a martial metaphor.
16:39 I guess one of the questions I have for you, now that I have you here on the line and your actual attention,
16:44 is how do you hold those conversations with people by, say, removing keys?
16:49 Like, who needs access?
16:50 And how do you talk to people about whether or not they're maybe a good candidate to be a mentor or so on?
16:55 Like, how do you emotionally hold time with all the different contributors on the project to be able to say,
17:02 this person is here, this person is here, here's what I see for you and so on?
17:05 Because I imagine your view of where someone is will not always align with their view of what someone is.
17:11 I mean, I think commit access is the first one where I think it's normally relatively easy and clear cut,
17:18 because it's, you know, I just look at the kind of contribution graph metrics,
17:21 the private repo contributor metrics for the last year,
17:25 and then that shows me who is committed and who hasn't.
17:28 And if you haven't committed to any repos ever in the last year,
17:30 like, even if you feel like you should have commit access,
17:33 I think, I guess, if I'm being more self-analytical,
17:37 I think you could answer the question of how do you hold time for that
17:40 and handle the kind of major emotional side of this stuff.
17:42 Maybe not as well as I could.
17:44 I'm a fairly terse individual, at least in written form.
17:48 People, including at work, definitely tend to like me more when they have met me in person
17:53 and they understand that apparently I'm quite a grumpy prose writer.
17:57 My GitHub avatar for a long time looked quite grumpy,
18:00 which probably contributed a little bit to that.
18:02 But yeah, so I probably don't dedicate as much time and energy as I could slash should maybe
18:09 with trying to kind of manage the emotional side of that.
18:13 Like, I just sent out some messages yesterday,
18:14 like, people know that the commit access was going to get cut off.
18:17 And yeah, I was basically just like, thanks for your work on Homebrew.
18:20 You have used in the last year, cutting it off.
18:22 We can add it back in the future if we need to.
18:24 And that was that, really.
18:25 And I think, I guess, to touch on what you've said before about boundaries,
18:28 which I think in some ways, perhaps that's why.
18:31 Because I know that I do not have infinite time or emotional energy or whatever.
18:37 And it would be nice for people if I could spend a lot more time like individually hand
18:44 curating those conversations.
18:46 But I don't have time.
18:47 And it has to happen.
18:48 And ultimately, I think it's more important to the project that people who have commit access
18:56 are the ones who need to have it than it is that I maybe don't do that as often or at all.
19:02 But maybe some people feel better and happier until one of their tokens gets leaked and Homebrew gets hacked.
19:09 Fair.
19:10 I think you may be giving yourself not as much credit.
19:12 You did say, thank you for your time.
19:13 That's something I haven't always gotten friends.
19:15 I've been removed from organizations on GitHub just because someone's like,
19:18 it's not working anymore.
19:19 All I get is an email notification saying, you're no longer a member of this organization,
19:23 which, frankly, hurt a lot.
19:25 Several times it's happened because it's like, I really valued being part of that organization.
19:29 Now it's gone.
19:30 Oh, no, I'm sad.
19:31 It's okay to be sad.
19:32 But that's just something I felt.
19:33 So the fact that you said thanks is already a step in the right direction.
19:36 Overcommunicate.
19:37 Here's what's going on.
19:38 I think that works pretty well.
19:39 As far as being terse, you're actually not very terse.
19:42 You have a blog post up that says saying no is important.
19:45 And saying no, actually, I think has an unnecessary word there.
19:49 There's a famous story of a Spartan general who wrote back to the city of Sparta saying the
19:55 city was taken.
19:56 And they gave him a fine, a literal fine in drachmas for being two troleks.
20:02 He should have just said taken.
20:04 So in this case, you could have just said no.
20:07 What's interesting to me about this, though, besides the random brief reference, good job,
20:11 Richard, is you mentioned Brene Brown's podcast and one of her books talking about the BRAVING
20:16 acronym.
20:17 Would you mind giving me a brief summary of how that applies to your work on open source?
20:22 I would say that I'm an expert on Brene Brown's material because particularly the book that
20:28 this is from, I have not read yet, at least.
20:31 But yeah, so she talks about the elements of kind of trust, which have that acronym BRAVING,
20:36 which stand for boundaries, reliability, accountability, vault, integrity, non-judgment,
20:42 and generosity.
20:43 So the ones, I could go through all of them, but I'm not going to because it's not that type
20:49 of podcast.
20:50 And she would say infinitely better than I would.
20:52 But the ones that kind of jerk out to me are like boundaries, reliability, and integrity.
20:57 So for me, when I look at people who are not very good at saying no, and this applies everywhere
21:05 from kind of personal level and personal friendships to inside a company, to inside an open source
21:11 project, they are people who often cannot maintain boundaries adequately.
21:17 So as a result, their reliability, integrity suffer because what happens is if you say yes
21:26 to everything all the time, you cannot do everything all the time.
21:29 So eventually that yes turns into a last minute no.
21:33 So I've at work kind of described it often as like front loading the disappointment.
21:40 So I try and take this at work on open source in my personal life, whatever, is that people
21:45 can sometimes find me somewhat, I don't know, brusque or whatever, because they will ask me
21:50 to do a thing or read a thing or be somewhere at a certain time.
21:55 And what's generally considered to be socially acceptable is to say yes, or maybe and not do
22:01 it.
22:02 And they are very surprised to hear me say, no, sorry, I'm not going to do this.
22:06 And I could provide more details about why I'm not going to.
22:09 And I think in open source, this is so important.
22:12 I think boundaries are the most important part of open source sustainability because at the
22:16 end of the day, again, there's a lot of talk about money or mentorship or the number of people
22:21 But at the end of the day, to me, in open source, you should be only working on stuff that you
22:28 want to be working on.
22:29 And the minute it feels like it's overall, at least not a pleasant thing for you to be
22:37 doing anymore, and it is making your life worse, you should get out as soon as possible.
22:42 And part of not getting to that point in my experience is maintaining boundaries.
22:49 So one of the personal rules I have for myself is I don't fix bugs for people who are being
22:55 rude or unkind.
22:56 There's been times where people have submitted an issue on homebrew and it's a legitimate
23:00 issue.
23:01 And normally I would fix that, but they have reported that issue in such an abrasive or
23:07 rude manner.
23:08 I don't want to reward that behavior.
23:10 And sure, if 10 other people come in and say, hey, we're affected by this too, please fix
23:14 this or whatever, I'm not going to step in and refuse to fix that.
23:16 But if there's only a single person who has reported that, I don't want to reward bad behavior.
23:22 And for me, I need working on open source to be a pleasant experience because it is fundamentally
23:28 optional to me.
23:29 So if I start going and dealing with these people and dealing with kind of verbal abuse, just
23:34 because I think that's what's right for the project, I've enabled that verbal abuse.
23:38 And I've allowed that into my life.
23:40 Whereas if I just step away and reject that, in some cases, I'll just step away and another
23:45 maintainer can get involved and they can fix that if they want.
23:47 If it's kind of borderline rather than clearly egregious behavior.
23:51 And yeah, and for me, that's made it a lot better.
23:54 And even on stuff that I particularly as the project has grown, stuff that I just don't
23:58 really want to do.
23:59 Like there's some issues that come up or some particular types of work in the project.
24:03 And I'm like, someone else is going to do this.
24:05 I don't want to.
24:06 So I'm not going to.
24:07 And I feel like in a healthy open source project, most things will get done.
24:12 Like there will be some balance of people's time availability and their skills and willingness
24:17 to do things that things will get done.
24:19 And if there's things that consistently no one wants to do and can't get done, then you
24:24 probably as a project need to find a way to make that not a thing that your project has
24:28 And if that means killing features or closing issues on GitHub or having like the mailing list
24:34 be something that the maintainers aren't on, so be it.
24:37 What I really like about this conversation is that I feel like it's revelatory, largely
24:43 because I grew up in a house without boundaries.
24:44 So it's really interesting to hear someone else say very clearly, I have boundaries.
24:48 And it's helping me recast some of the experiences I've had with open source maintainers where
24:51 I've experienced them as kind of emotionless automatons.
24:55 And if I rethink that as, no, they're just maybe particularly good at setting boundaries around
25:01 what they will and will not do.
25:02 It's much easier for me to see them as full humans and to see the process as being part
25:07 of actually a sustainable workflow.
25:08 So I'm actually really excited about that.
25:10 And thank you.
25:11 One thing that's interesting is what came to mind while you were talking.
25:15 Bruce Lee's quote, which is, you put water into a cup, it will become the cup.
25:19 You put water into glass, it will become the glass.
25:21 But water can flow or it can crash.
25:23 Be water, my friend.
25:24 It doesn't seem like your boundaries have a lot of room for grace or forgiveness, which
25:30 I would equate with flowing.
25:31 I think hard boundaries often crash.
25:34 They hurt.
25:35 So I'm just curious where the room is in your open source workflow for grace.
25:41 For me, it's interesting.
25:44 So I'm sort of somewhat post-Christianity nowadays, but I was a fairly religious chap for a few
25:51 And yeah, for me, I can't remember whether it was forgiveness or grace or something like
25:57 that, but it's one of those ones where I remember hearing some minister talk about...
26:01 Empathy also works in the modern, secular part.
26:04 You don't have to go with grace.
26:05 No, but I mean, I think it was a particular word that in the Greek was kind of translated
26:10 as being something, a sign that someone turns around that does a 180 and walks in the direction.
26:18 And to me, like that's where empathy, forgiveness, grace, whatever you want to call it, exists
26:23 with open source.
26:24 And I've seen plenty of people who behaved inappropriately in open source projects, including my own.
26:30 And as long as it's not been hilariously egregious, which I put in the realm of like jumping straight to
26:38 legal threats or, you know, assault against people's protected characteristics verbally or
26:43 otherwise, or whatever it may be.
26:45 As long as it's just kind of borderline, ah, you're being a bit of a unpleasant person here.
26:51 Generally, what I've found leaves things open for grace and is also a really nice heuristic is
27:00 those people in those situations, if you give them a bit of a nudge and say like,
27:04 that's not cool, don't do that, please.
27:06 Then the toxic people explode.
27:10 They say, how dare you?
27:12 This is outrageous.
27:13 They tend to double down on insults or refuse to apologize, or if they do apologize, it's
27:18 in the, I'm sorry that you are such an idiot that you felt that way type apologies.
27:25 Whereas a lot of the time, a lot of people, and I would say most people do that and they're
27:29 like, you know what?
27:30 I was a bit of a jerk there.
27:32 I was angry.
27:33 You might not get the best apology in the world, but you do genuinely see a change of
27:38 behavior from those types of people in those types of situations.
27:40 And that for me is where like that sort of balances with boundaries in that I don't tend
27:47 to almost like put you immediately into a kind of bad actor bucket.
27:50 But yeah, I do tend to kind of try and have that little nudge to be like, let's find out
27:56 when you've done something bad or inappropriate or whatever, can you have enough
28:02 introspection to go and say, yeah, sorry, that's my problem.
28:07 And for me, as soon as someone says sorry in that way, like I'm straight back to kind
28:11 of love bombing and I'm happy to say, thank you.
28:14 I didn't handle this interaction as well as I could have done, whatever it may be.
28:18 But when that question doubles down, I guess I used to spend a lot of time either just having
28:23 a lot of back and forth to those people or trying to reform them or whatever it may be.
28:26 But I guess over time, I've just found, you know what, those people don't change.
28:30 People who want to kind of get in a fight about whether their behavior was appropriate or not.
28:35 Again, kind of inside and outside open source.
28:38 If me saying, hey, sorry, what you said there wasn't very nice and you were hurtful to my
28:44 feelings or someone else's feelings, if the default response of that person is not sorry or I can do
28:51 better or whatever it may be, generally they're not a person that I want to work with super closely.
28:56 And I think one of the biggest learning experiences for me with my years at open source has been
29:02 those boundaries should be set at the same level, whether that person is a newbie user who's come
29:11 to your project, maybe with some entitlement issues, who's never interacted with the open source
29:15 maintainer before, or if that person is a prolific open source maintainer themselves.
29:18 I don't care anymore.
29:20 If someone on the Homebrew project themselves are being abusive to users or maintainers or whatever
29:27 it may be, then they need to adjust their behavior or they need to find another project.
29:32 And in some cases for us as a project, there's been times where I've asked people to consider
29:37 I've genuinely asked myself that this could kill the project.
29:40 I'm really concerned how we're going to be able to survive this person leaving.
29:44 But every time that's happened, almost flowers blooming from ash or something like that,
29:51 you see a bunch of people who were kind of basically had merged into the background
29:56 because of that person's behavior, who then reemerge and are like, hey, you know what?
30:00 Now that this person's gone and they're going to stop treating me like crap, then I'm happy
30:05 to kind of get more involved in this project again.
30:07 And people step up and they get involved and the project survives.
30:10 And in my opinion, even more importantly than the project surviving, the project becomes more
30:16 of a place where people know that you have to treat each other with a certain amount of
30:19 kindness and respect.
30:20 And if you can't do that, you're not welcome here because yeah, people don't want to work
30:24 an open source if they're going to get abused from anyone.
30:26 It doesn't matter what their position is or qualifications or whatever.
30:29 So there's a quote here, the crisis that we are in the midst of the day, whether ecological,
30:34 political, or societal, I'm going to add, or open source, except for the fact that we
30:37 treat the earth and one another as less than sacred.
30:40 This is from John Philip Newell's Sacred Earth, Sacred Soul, Celtic wisdom for reawaiting
30:45 to our souls, to what our souls know.
30:47 I went to a talk on this like last week in Edinburgh.
30:49 I'm bringing you up now because hilariously, this is turning into the Richard Littauer slash
30:53 Mike McQuaid spirituality hour.
30:55 So thank you all for listening.
30:56 I really liked that.
30:58 That was awesome.
30:59 I think to stop us going down the well all the way into how to treat each other and ourselves
31:04 with sacredness.
31:05 Let's step back a bit.
31:06 So you were also on the GitHub sponsors team.
31:09 And you mentioned earlier that money is not the only thing in open source.
31:14 So I'm curious, how did it happen then that you got involved with GitHub sponsors, which
31:18 seems to me a way of recognizing the sacred and divine and human in every single open source
31:23 maintainer by paying them for their efforts?
31:25 I guess I'll start with a caveat that sadly shouldn't be necessary, probably is that like,
31:30 I'm not one who normally believes in saying my views are my views and not the views of my
31:34 employer, but I would say on GitHub sponsors and stuff, this is definitely the case.
31:39 I work on sponsors anymore and I'm not part of that team anymore.
31:44 Just for no negative reasons, just moving around the organization as I do.
31:48 And yeah, and I think they're doing great work.
31:50 I think GitHub sponsors is and has been a really valuable contribution to the open source ecosystem
31:57 because it provides a way, at least for open source maintainers on GitHub, which is a really
32:02 significant proportion of them, a really easy way to start accepting money.
32:07 And we tried to make it pretty easy and as pain-free as possible.
32:11 And I was the initial kind of team of like four engineers and an engineering manager and a designer
32:19 and product manager.
32:20 I was the most involved with open source of those folks.
32:24 So I felt like I was sort of advocating for the interests of maintainers often.
32:28 And yeah, we've tried to provide that model where people can receive funds in different ways and
32:34 use it in different ways to support that.
32:35 Like if you want, as Homebrew does, if you want all your money to kind of go to your central
32:40 project and maintainers don't really receive the bulk of the sponsorship, at least not directly,
32:45 then you can do that.
32:47 If you want to have a project where individual maintainers are where you're pointing your funds,
32:52 you can do that.
32:53 If you want to do kind of quid pro quo tiers and stuff like that, you can do that.
32:58 If you want to just do, again, like Homebrew does, kind of like, give us this money and
33:02 trust that we'll do the right thing with it.
33:04 And you're not really getting anything directly in return for that.
33:08 Then that's an option as well.
33:09 What I really like about GitHub sponsors and why I'm proud to have worked on it is it's,
33:14 it feels like it's bringing some money into the ecosystem that wasn't there before.
33:18 And through making it easy for both individuals to accept that money, but also for companies
33:26 to kind of give that money as well.
33:28 I think it's had, it's not been like a zero sum game.
33:31 Like I don't feel like we kind of partner with Open Collective who are one of our fiscal
33:35 So you could get paid through GitHub sponsors, which goes into your Open Collective and stuff
33:40 like that.
33:41 And I really don't feel that like we're taking money away from, that was previously
33:45 going through Open Collective or Patreon or whatever it may be.
33:49 Like it does feel like there's some kind of new money in the system.
33:52 And from that perspective, I think it's really good.
33:54 And I'm kind of happy with it and pleased to have worked on it.
33:58 I guess to touch upon your kind of original point, I definitely don't think that's the
34:03 be all and end all.
34:04 I think projects like Homebrew that I've been involved with a lot of the kind of efforts
34:09 over the years to kind of get this money and think about what we spend the money on and
34:13 Figuring out what you spend the money on is itself a non-trivial problem because I'm lucky
34:19 enough to work for a company that pays me well.
34:21 And Homebrew does not think, at least I haven't checked recently, but I'm pretty sure Homebrew
34:27 does not, if we were to handle taxes and our expenses or whatever, have enough to, for example,
34:33 pay me to work on it full time.
34:34 So we might be able to pay some other people to work on it full time.
34:38 But if the goal was, while me and all the maintainers are going to go and quit our jobs
34:43 and work on Homebrew, we don't have nearly enough money for that.
34:46 So there's that interesting kind of trade-off of like, well, we've got too much to spend
34:51 on stickers, but not enough to spend on people full time.
34:55 And certainly not enough to feel comfortable saying to people, hey, you can just quit your
34:59 job and we'll pay you and we'll do all your health insurance for you and everything like
35:02 that if they're in the States.
35:03 So yeah, so it's been an interesting kind of discovery process of thinking like, well,
35:08 what do we spend our money on and how and on who?
35:11 And we're still in a kind of experimental stage there.
35:14 And that's where I think Gelb Sponsors has been great for enabling that, but it's not the
35:19 Gelb Sponsors or Open Collective or any method of making money is not just the answer
35:24 to sustainability. Because if you have a project with more than one person who is wanting to
35:29 work for market rate salaries and is in a relatively prosperous country, it's really hard to make
35:36 enough money to pay that person to work on it full time. And the people who are doing that
35:40 are doing a lot of work to maintain that funnel. And that's not work that everyone wants to do.
35:49 And that's not work that everyone is great at. And it has trade-offs. And I think it's good to see
35:55 that stuff grow. But at the same time, I'm glad to see the community has not jumped to the conclusion
36:02 that Github is, sorry, Github Sponsors is all or nothing, that it either is the solution to open
36:07 source sustainability, nor is it a problem for open source sustainability.
36:11 So when it works for Open Collective,
36:13 I totally get where you're coming from and how that's working. Although not working for Open
36:16 Source Collective, which is slightly different. I really got to figure out where I work.
36:19 You've also written more about this again on your blog about open source economics and about the
36:23 fact that money isn't everything. You have to figure out where your time is allocated and then how you're
36:26 going to spend the money you have. I'm glad you mentioned the sticker problem. You have enough for stickers,
36:30 then what? What's next? Homeroot doesn't have enough money to employ you unless you're willing to work
36:34 for $15,000 a year, which I'm pretty sure you're not because that doesn't work in our modern Western
36:39 economies and where we're both calling from. Github Sponsors emphasizes individual action towards
36:46 individual projects. It doesn't emphasize a systemic wide approach to figuring out how do we,
36:51 as a collective tech world, pay for open source maintainers collectively. Even the Open Collective has
36:58 it right there in the title. It's still individual companies, people at those companies or individual
37:03 people spreading the wealth among them. So I'm curious what you think about the next step of
37:07 sustainability might be in terms of actually helping open source maintainers from a non-individualistic
37:11 approach. Yeah, I think that's really interesting. I mean, we've been touching upon that a little bit
37:16 at Github so we can recommend on the page that sort of allows you to discover new sponsors. We can use your
37:24 dependency graph, I think, to sort of point to like things you depend on that are responsible and stuff
37:29 like that. But as soon as you start to get into the data-driven side, you realize that like my
37:34 dependency graph, it's very easy to point out NPM modules or Ruby gems, whatever. How does GitHub detect
37:39 that I use Linux or on my, you know, you could maybe detect Kubernetes or various other things.
37:47 There's basically a lot of parts of the open source stack that are kind of undetectable. So how do you
37:54 decide what that stuff gets and how do you stop all the money going to the projects that are more
38:00 easily detectable and less? And all I can say is that I know people in GitHub are working and thinking
38:06 about how best to address this. But at the same time, I don't think this is a thing for GitHub to
38:11 solely fix. And I also personally, and this is very much on the personal level outside of Homebrew or
38:18 even GitHub, I think there's something a little bit sad about some of the current narrative that almost
38:23 like an unpaid open source maintainer is an exploited open source maintainer. Because I think we need to be
38:28 careful about having an ecosystem that is not perfect, flawed in lots of ways, and saying what we need for
38:37 this is to just pay everyone X amount of money and then the solutions will go away. Because I guess I remember
38:43 the kind of bad old days where in big companies, it was pretty hard to use open source and internally, like
38:51 even to just consume an open source project and use that, even when the licenses were all completely
38:56 okay and very liberal and whatever, that was difficult because companies were very skittish about
39:01 this and we got over that. And I worry if we get into a world where if you are a large company who
39:08 uses an open source project and you don't allocate large amounts of financial resources to that open
39:15 source project, you are somehow exploitative. But we end up in a world where we start to discourage
39:21 those companies from using open source anymore. And then we end up in a world where we start to
39:25 fragment the ecosystem between places that are okay for you to use them without paying and places that
39:30 are not. And we, again, pre-open source software, we've had a pretty good way for a pretty long time of
39:36 letting people pay for software. And I guess to me, the sustainability side is not how do we pay every
39:47 open source maintainer an upper end salary for what they're doing? Because I'm also not necessarily
39:54 convinced that open source maintainers will all be allocated efficiently in that process.
40:01 Ironically, considering that the same folks who tend to consider open source maintainers to be
40:06 exploited are often critical of capitalism and free markets, I think it's interesting that their proposed
40:14 solution relies very heavily on capitalism, free markets to effectively just, well, if we just pay
40:20 everyone enough, then all the problems go away. And I guess I debate that, I guess, again, more not to get
40:28 into our sort of philosophical, spiritual bent again, but I debate how many of these problems can be solved
40:34 by just throwing money at them, as opposed to finding ways that people are able to set boundaries more effectively.
40:40 For example, this blog post that kind of go around that suggests that all open source maintainers should
40:45 have a way for companies to easily pay them their time. But in my case, I don't want to do that. I like my
40:51 life. There are companies who come to me sometimes and say, "Hey, we'll pay you X if you can come and do
40:57 this on homebrew for us." And I'm like, "Well, I have two small children. I have hobbies. I have a job. I like those
41:04 things and the marginal value of you giving me a bit more money to do a bit more stuff." That doesn't
41:11 work for me. And I can understand the frustration on the commercial side at the same time that it may
41:18 well be that that applies to every homebrew maintainer and that there is no one they can pay to do this
41:22 thing that they want to do. And maybe they just need to do that themselves or hire someone to make that their job
41:28 or whatever the means may be. But I'm personally reluctant to have the idea of all open source
41:33 maintainers, all open source projects need to somehow become consultants and provide this
41:38 like two-way transfer of money and resources and time and knowledge and whatever.
41:43 Mike, I feel like I'm listening to the Scottish fisherman equivalent, you know,
41:47 the old man sitting at the table playing cards and American says you should go out and fish more
41:51 and then get a fleet of ships and keep doing it. Then like, well, then what? Then you can retire
41:55 and play cards like what we're doing at now. Why would you bother? That was very
41:58 condensed version because we are running out of time, which is very, very unfortunate.
42:02 This has been a massive pleasure for me. Thank you so much for coming on. There's a couple of
42:07 things left before we do wrap up. Obviously, we didn't get to all the good stuff because there's
42:12 so much more we could always talk about. We got to a lot of good stuff, though. Where can people
42:16 find you on the web to hear more about what you have to say and think when you have the time
42:21 and ability to do so? So my website, mikemcquade.com has various sort of
42:28 articles I've written and I post my new thinkings there and talks and stuff like that. There's like
42:34 a mailing list if you're interested in getting these things. And I'm sort of very sporadically
42:40 on Twitter. I try and only talk about open source on Twitter. So that's mikemcquade as well. And then,
42:46 I guess you can find me on GitHub or just in Edinburgh and at Fosden and hopefully increasing
42:51 numbers of meatspace things in the future, because I like seeing people in person now that I can.
42:59 Yeah. Well, darn, lost opportunity, but hopefully not in the future. So excellent. Thank you so much for that.
43:03 Now's the point where we get to give back to other people. So Spotlight is about highlighting projects
43:08 for places or open source packages, which have really made our lives easier, which we think just
43:13 need a little bit more love. My spotlight today is based in Edinburgh. It's the Forest Cafe. I was a huge
43:21 reporter of the Forest Cafe when I used to go there when I was a student here, which is one of the reasons
43:25 why I'm here again. I used to live in this city. It's really, really nice. Forest Cafe is a art and social
43:31 space. It's basically a nonprofit. And it's just really great to be able to go somewhere and actually
43:36 exist outside of economies of cash, which is why I thought of it for today's Spotlight. For me,
43:40 this was a home where I could go and trade services for things, hang out, I could work in the kitchen,
43:46 I could get really nice beans on toast, and it's just made me feel like a better person. So the Forest
43:51 Cafe is great and they have since moved from where they were, but they are still around to go check them
43:55 out if you are in Edinburgh. Mike, what is your Spotlight today? I think my spotlight for the day is
44:01 a software project. I will be very surprised if no one has mentioned this before, but it's called
44:06 RIPGREP. It is a search tool that is written in Rust. If you have done a global search in VS Code,
44:14 you have also used this because it was embedded. So I've been on a long running quest to find tools
44:19 that are good at searching for things in my terminal. I started with GREP, I then found ACK,
44:24 then I found, I think it was the SilverSearcher, and then I have evolved into RIPGREP, which seemed to
44:30 be the fastest and or nicest UI. Yeah, it's basically just very good at finding things
44:36 quickly from the terminal or in VS Code and it's written in Rust and it seems very fast and it's
44:42 very lovely and the maintainer seems like a cool dude too. Excellent. As a long-time user
44:48 of the SilverSearcher or AG, I will probably now look into RIPGREP. So thank you so much for that
44:53 suggestion. Mike, thank you so much. It has been a real pleasure. Listeners, I hope you enjoyed this
44:59 podcast. I hope you enjoyed hearing what we had to say. If you have any comments of any sort for me or
45:04 for Mike, feel free to send them to either Mike or podcast@sustainoss.org where I will get all the
45:10 comments and fold them into the next show and so forth. If you have any suggestions for people who
45:15 should be on the show, please suggest them there. You can also rate us on Apple Podcasts or Spotify,
45:20 and you can join us on Twitter @sustainoss or you can go on our discourse, which is
45:25 discourse.sustainoss.org to drop links and have further conversations about software sustainability.
45:30 We're always looking to have more nuanced conversations. So if you feel like we should
45:35 have gotten somewhere, but we didn't, I in particular want to hear from you. Mike, thank you so much.
45:40 It's been a real pleasure and best of luck with everything. Thanks, Richard. Enjoy.