← Software Engineering Daily
Software Engineering Daily
Homebrew and macOS Package Management with Mike McQuaid
01:05:46
Homebrew is a widely used package manager that simplifies the installation of open-source software on macOS. It was created in response to the growing demand for a lightweight, developer-friendly tool suited to an increasingly Mac-centric development e...
Loading summary
Transcript59 lines
- [00:00]
A
Homebrew is a widely used package manager that simplifies the installation of open Source software on macOS. It was created in response to the growing demand for a lightweight, developer friendly tool suited to an increasingly Mac centric development ecosystem. Today, Homebrew is a near essential part of the macOS software development toolkit. Mike McQuade joined the project early on and collaborated closely with its creator Max Howells. He joins the podcast with Kevin Ball to discuss Homebrew's Origins architecture, its emphasis on automation and cicd, long term sustainability, controversial trade offs and much more. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website K Ball LLC.
- [01:16]
B
Mike, welcome to the show.
- [01:18]
C
Hey, thanks for having me Kevin.
- [01:19]
B
Yeah, excited to get to talk to you. Let's maybe start with a little bit about you. Can you talk about your background and then how you got into Homebrew and where we're going to go today?
- [01:29]
C
Yeah, sure. So I feel like in tech I've kind of had two lives, right? So there's my maybe a little bit like being a really rubbish superhero, right Where I guess my commercial job related life. You know, I'm a guy from Scotland, I interested in computers, did the computer science degree thing, got the tech job thing, have been doing that since 2007. Just you know, like getting jobs, changing jobs, paying the bills, having fun, all that stuff. But then there's my open source life which is generally what's of more interest to people with Homebrew and all that type of background. So my love of open source I guess probably started while I was at university. Like I came to university, I heard about, you know, when I was in high school people talking about installing Linux on the machine the same way that you might talk about, you know, taking illicit drugs or whatever. It was this kind of risky, dangerous sort of somewhat admirable thing. So yeah, so I got to university like a bit of a kind of Windows power user, had not done meaningful programming really beyond just trying to get games working on my computer and peer pressure happened pretty quickly and I was like okay, I need to get on the install Linux on my desktop bandwagon, right? So got Linux on my desktop machine, got like a little home server of an old computer running my parents house. So I could like send data back and forth and all this type of stuff and. Yeah, and obviously, you know, desktop Linux, one of the nice things about it, I mean probably even now, it's certainly back in, you know, 2003, four when I was first dabbling with it, is like open source is front and center, right. And you very quickly realize like, oh, this is like a community of people building a thing. And as much as I feel like I'm a consumer and I'm using this thing, if I file a bug, there's a very real chance that the guy or girl who wrote that is the person who responds to my tickets. So I guess that kind of growing awareness, I started helping out with things and helping out on IRC channels and bug trackers and forums and all this type of stuff and then forking stuff myself, modifying it little bit, publishing up the changes in case anyone cared. But yeah, but I guess for me the, the main thing was probably like I did Google summer code back in 2000, would it be 2007 for the KDE like desktop environment still around and yeah, and I basically sort of fell in love with the open source community through that really like from spending a three month project just writing lots of code, seeing very high degrees of trust and mentorship and help and whatever. And then I just went on from that, being a huge proponent of it in my work life. And then I guess the two streams probably crossed again. In 2009 I was in London working for a stock called Mendeley. Across the other side of London, in front of a friend was a guy called Max Howell who is also working in London at a wee stock called Last fm. That probably brings back memories for a certain number of people. And yeah, so he had been tasked with doing various bits and pieces and building desktop applications. And I believe the official story is like he was in the pub one night complaining about all the package managers being terrible and someone said to him, well, if you hate them all so much, why don't you make your own one? And he left the pub, went down, wrote a sort of outline of what homebrew should be, started building it and then I got involved. I can't remember what it was like four or five months later. Kind of heard about this thing. I'd sort of tried to build something vaguely similar to myself. And yeah, that was I guess 16 years ago, like in September that I've been working on this thing and yeah, and that's my open source story, I guess.
- [05:19]
B
That's awesome. Yeah, I feel like a lot of Us have that experience with open source of like, this stuff is all crap. Wait, with this stuff though, I can actually do it myself and make it my version.
- [05:28]
C
Yep, totally.
- [05:30]
B
So I feel like in today's age, especially with Max having become, at least in the US and much of Europe, the sort of de facto development environment for many, many developers, a huge number of our listeners are probably Homebrew users, but I don't know how many of them have actually looked below the hood at how it works or why it became the de facto norm. Why is this one not terrible? The way that all the package managers that Max was complaining about are. So how would you describe, like, what are the core, like, choices or approaches that have made Homebrew so successful?
- [06:04]
C
Yeah, before we get to that, I just noticed this is again, I've been working on homebrew for 16 years. It's the first time I've ever thought of this. I think because you were saying in that sentence and you're talking about Max the Apple computers and Max the creator of Homebrew. And it's only just twig. I'm like, oh, yeah, that's a fun little coincidence.
- [06:21]
B
That is a fun one. Yeah.
- [06:23]
C
But anyway, so how Homebrew works. So I think one of the things I found in my career in general is I'm. I'm a maintainer, I'm not a creator. I'm someone who is very good at taking something that someone else has made and riffing off it and evolving it and growing it and blah, blah, blah. But I am rubbish at coming up with new ideas myself. So a lot of the brilliance of Homebrew, I think, goes back to Max's original design and I think the less interesting parts of the design first. But people might not know this, so let's tell them anyway. So Homebrew is, and was from day one written in Ruby primarily. So at the time Ruby and Rails was starting to take off, Ruby was becoming a popular language in 2009, and nowadays it's the same. There's still a bunch of code that probably goes right back to the first few commits. And if you sort of squint a little, you can see that the DSLs and stuff that are being used in Homebrew today are still much the same as back then. So I think that brings you to the first part of Homebrew that I think was initially brilliant, which is like something Ruby's very good at is building these DSLs. Domain specific languages, I guess we would call them, where. Because Ruby code can be at Least made to look very much like just normal English, right? And because Ruby is a very low syntax heavy language, you can build these things that look a little bit more like you're just declaring. You know, it almost looks a little bit like YAML without as much indentation and stuff sometimes where you can just look like you're declaring data, but you're actually calling functions inside a class and things like that. And as a result of that, Homebrew started off with these things called formula. So the formula is basically like a definition of how a package is built. Originally, Homebrew started off being a from source package manager. So everything is built on your machine. Nowadays, basically everything is built by someone else, usually homebrew somewhere else elsewhere. But that kind of initial formula description was very, very easy to read and write and contribute to. So I think that was a key thing to begin with. If you've ever worked with other package managers, particularly back in that era, and had to package something in apt, GET or RPM or whatever, it was a nightmare, frankly. It was horrendous how many steps it would take and how many things you'd have to do to pass all the lints and test all this stuff on your local machine. Whereas the Ruby formula made it very easy to read and understand what was going on and design and contribute and that's the next thing. I think that was the really smart choice. I was speaking with a CEO recently who said something along the lines of all the best engineers are lazy and often engineers that he might have a problem with are the ones who are being insufficiently lazy, not working hard enough. But there was a certain amount of that from the outset with Max, where he said, hey, this package manager is going to be successful. We're probably going to have like five, six, 10,000 packages. I don't want to maintain 10,000 packages, right? Like, I also don't want to go down the route of, you know, something like Debian or whatever, where I have to find, you know, a thousand people who are willing to maintain 10,000 packages. So this was around the era that GitHub was starting to take off. So he basically was like, right, we're going to design the package manager. So it's a GitHub based workflow and Homebrew actually predated pull requests even on GitHub. So the original flow, I mean, the first few commits I had would be, I would be on IRC and I would DM Max with like a commit in my fork and he would be like, yep, that looks good. He would Then cherry pick that from my fork and then push that to the Homebrew repo, right? And then over time we ended up pull requests and reviews and all this type of good stuff. But yeah, I think that model from the outset of designing it to be both very, very easy to contribute, but also designing community contribution and community maintenance as being a core part of the overall flow of Homebrew is I think what resulted in it being as successful as it's been.
- [10:40]
B
That's fascinating. And I think for open source in general the packages that sustain themselves seem to be those that manage to build that community early. So thinking about that from the beginning is great. Another thing that I think makes Homebrew different from at least the package managers that went before in Mac land and also a lot of the Linux package managers is it's pretty much all user space, right?
- [11:06]
C
Yeah, yeah. So that's one of the nice things about macOS and one of the reasons I'm still a fairly, you know, die hard Mac fan today is back in the Linux package manager days when I was working with that, I mean the Linux package managers, you know, I would still say to this day that I don't think apt get is better than Homebrew in every way but I think overall it is a more powerful package manager. It has a lot more stuff, a lot more sorted than Homebrew does. But there was a slight weirdness to me always where essentially some random utility that I'm pulling off someone's GitHub, right that I essentially, if it breaks it has no consequence to me like and my LIBC or like kernel are essentially managed in exactly the same way as far as the package manager is concerned, right? And one of the nice things about macOS or I mean even nowadays again if you sort of look at it from a funny perspective, things like WSL or, or like there's Linux distros that are doing this now as well. You have a kind of immutable file system like a modern macOS does and Homebrew and Linux is taking off on those as well is this idea that like as you say, you have this user space package manager, right which is living in a non protected part of the file system. You don't need to run sudo to run it and stuff like that once it's installed and then basically you sort of limit the damage that that can do to your system. And nowadays I think partly because of maybe Homebrew becoming more popular like the, you know, the macOS based system is like super locked down and you can get access and modify things if you want to, but you're going to have to boot your Mac in a special mode and blah, blah, blah. And that basically just means that developers on Macs now don't have to fiddle with things in User Bin. User Bin is up to Apple, like Opt Homebrew Bin is up to Homebrew and you can just remove Opt Homebrew Bin and every, at least like desktop application on your system should just continue to work fine as is. You know, all your programming projects may explode, but, you know, that's. It has less of a degree of concern that you're actually going to like, brick your system or whatever, which was at least theoretically possible in the bad old days.
- [13:37]
B
Yeah, well, and it makes, for example, staying up to date with Apple's upgrades a lot less painful as well. I feel like it used to be I would, and I still have some of these instincts, but I would resist forever upgrading to the newer oss because I knew my whole dev environment would break and I'd have to go and rebuild everything. And I feel like that problem has more or less gone away.
- [13:59]
C
Yeah. So that I'm glad to hear your perception is that problem is mostly going away. That. I mean, to be fair, Apple are better on some of the stuff than they used to be. But it's still. It's definitely an area of pain that projects like Homebrew mainly feel. But in some ways, like if Homebrew can do one thing well, it's providing a abstraction layer over all of this stuff so that we have to care and worry about and fix this stuff and you don't. Right. So, yeah, like that's, that's very much a, A goal of our package manager is to.
- [14:33]
B
I wouldn't say it's completely painless at.
- [14:35]
C
This point, but it's.
- [14:36]
B
I mean, it used to be days and now it's like, oh, I've got a couple hours of cleaning things up.
- [14:42]
C
Yeah, for sure.
- [14:43]
B
Let's maybe actually then peel back that abstraction layer a little bit because, you know, I, as a user, I just know the APIs you provide. But what are actually the key pieces that go into making a package manager work?
- [14:56]
C
Yeah. So I think Homebrew is a bit of a special snowflake of a package manager in lots of ways. I guess I've mentioned some of them already. Some of the package managers that have come after have really leaned into the same sort of model of community contribution and stuff like that. Some haven't. I think one of the things we do that Often surprises people is we have, I guess our stats and best estimates or whatever are like 5, 10 million kind of relatively active users of HomeBroup, which is a scary amount of people. And then in terms of maintainers, we have like 30 people, right? And probably on a day to day basis, probably, you know, 10 to 15 of them are active. And it's, you know, you tend to have this parallel function of. Even within those maintainers there's some people who do a really disproportionate amount of the work. And in the total history of all the ruined ever, I think there's been probably less than 60 people, maybe even less than 50 people. So obviously that's good scaling, right? Like how you can get a relatively small number of people to provide that amount of service. Some of that is the contributors I mentioned before, like getting third parties to go and help and submit changes probably got like, yeah, I mean Definitely over 10,000 contributors. I don't think we're anywhere near to 100,000. But you know, in the five figures there, but still there's like, you know, there's scaling effects and you're like, how can you make that happen for 20,000 packages which are getting probably, you know, 10, 20, 100 updates a day across that. So something we have done certainly at least from the very early days of me being involved with Homebrew is going back to what we said before about laziness. Like I'm an exceptional lazy person. I like the people I work with to be lazy and I really encourage that. Right. So one of my positions for a long time, which is kind of funny, now we've got AI because it's encourage you to think about that in a different way. Still was almost like, I guess I wrote a blog post about this called Robot Pedantry, Human empathy. Because at the time I felt like I was seeing people were almost being like, oh, I'm going to write a bot to thank first time contributors to a project or whatever. And my observation was that if people have a bot doing it, it doesn't mean anything. They don't really feel valued and considered by a bot. Right. But on the flip side, people are very tolerant of bots being. I don't know if you've ever had one of those pull request reviews in a work environment, whatever, that are brutal. Yeah, well not even brutal, I would say excessively pedantic where say you're using semicolons in JavaScript the way that they don't like and you did it 20 times and they go through and on every single occurrence they're like, use semiconductors. And like, when, when a human does that, you hate that person, right? Whereas when a, what I would call a robot or like a CI job or a linter or whatever does it, you're like, that is actively helpful. And if you didn't tell me all of the occurrences, you would not be a useful tool. Right? So something I try to encourage in myself and in others in Humber for the early days was being like, okay, anytime you are regularly making the same comment on say 3 pull requests, figure out a way to turn that into an automated check that can run that can make the CI red so that the user has that indication that there is a problem here. And I guess there's to adopt horrible tech industry jargon, like shifting things left as well, right? So also that idea of like, okay, ideally we move from a human comment to being a CI comment, like on a pull request or whatever, but then ideally, still we move from a CI comment to a local development environment comment. So again, we have a bunch of automated checks. So the most common linter in Rubyland is a tool called Rubocop. So we now have it configured so that if you open Homebrew in like a VS code, you'll get prompted to install the Rubocol plugin. And if you install that, then when you're writing Homebrew code, we will pop up straight in your editor and tell you this is against Essentially the description of this formula is not in the format we like, you have started with A or an, and we don't like you to start with A or an because it doesn't look nice in our output or whatever, right? So then you can have a user who's working on this for the first time who gets that input straight away, right? And if you've enabled auto formatting in your editor, then some of those rubikops have autocorrection. So you could start your description with an A or an. And I can't remember whether this one does auto correction or not, but we'll assume it does. For this anecdote, you could type that in and you press save. And if you've got format and save enabled, then you'll just see that text just disappear, right? So obviously that contribution experience is delightful. When all the stars align and all that stuff happens, and instead of a human being like, don't do this, don't do this, don't do this, your editor is automatically making your code the way we need it to look. So it passes CI and Even if it does make it to CI again, we have a pretty time zone distributed team now, so we probably have decent follow the sun coverage. But before we had that, there was something really delightful about seeing someone open a pull request. See, our linter spits out 10 warnings. They read them all, they action them all, they improve everything. And then you wake up in the morning and you're like, oh, there was 20 things I would have said on the first version of this pull request. Instead, our CI tooling and the robots or whatever said all this, the person's got it ready and now I can just merge it straight away and then everyone has a better experience and that's how the projects can scale dramatically better in that way. And I also, while I'm on my soapbox, my personal experience is a lot of companies could do with moving a lot more in that direction than they think as well because generally humans don't like doing that stuff. And generally pretty much every software company in the world, if you're like, I can give you a way to move faster without negatively impacting your quality. Most people in most companies, most developers would say yes, please. And that's how you get there. You get there by very heavy but reliable automation.
- [21:04]
A
Have you tried building a text to SQL Chatbot? If your AI agents don't understand your data, its definitions, queries and lineage, they're forced to guess. And bad guesses mean risky assumptions. That's where SelectStar comes in. SelectStar automatically builds an always up to date knowledge graph of your data, capturing metadata like lineage, usage and example queries. So whether you're training an AI model or deploying an agent, your AI can answer with facts, not assumptions. Stop the wrong SQL queries before they happen. Learn more@SelectStar.com.
- [21:43]
B
There's a mindset shift there that takes a while to sink in. And I find I'm climbing that whole mental climb again now with these AI coding tools because there's things they're good at, there's things they're not good at, but a thing they are very good at is writing tools so you can use them to automate your check that you are going to do. And it's mind boggling how much faster you can go as you accumulate those.
- [22:06]
C
I'm in the same space right now where I would say I'm a like AI, I don't know, user and mild optimist. But it's like figuring out the places in which these tools are very well suited and very badly suited, right? Because you know, it's like the that all the expression used to be of. I can't remember where I first heard this, but your average not tech person would be like, I hate computers because they never do what I tell them to. And then the tech person response is no, you hate them because they do exactly what you tell them to when that's not what you mean. Right. And I think it's interesting because I feel like a lot of the time some of the modern LLM tools are getting better at inferring what you meant rather than what you told them to do. But then on the flip side, the responses are now non deterministic, so you can't. You know that those examples before with the CI and the linting or whatever, I'm sure I could describe in prose and feed that into ChatGPT and have that somehow run in my CI pipelines. But the problem is if you rerun that on the same code three times, you're going to get like, you don't get the same response every time without some sort of deterministic like code layer living underneath or on top that is making sure that that stuff works as it does. So yeah, I still feel like that's a big point of growth that we're still figuring out is like figuring out how do we make these two tools play together in the nicest possible fashion.
- [23:34]
B
The automated validations that you're doing are actually great for that because if you can put this non deterministic thing in a loop with deterministic validation for correctness, your quality gets so much higher.
- [23:47]
C
Yeah, yeah, I've definitely felt that when I've been doing stuff, I'm yet to really go hard on agentic stuff. Like particularly agentic not in a window in the foreground sort of approaches. It's on my to do list to play around with that in the next few weeks. But even on that, I definitely find in tools like cursors, agent mode or whatever, if you can say, here's how you run the test, here's how you link the code, here's how you type check the code. So homebrew nowadays uses sorbet, which is like a type checker built by stripe kind of type checker runtime type system runs exceptionally fast to kind of check the entire code base, then. Yeah, like the more of those guardrails you have then the better these tools do because they're able to validate their own behavior without you having to say like, oh no, that should be an integer being passed to this method, not a number one in quotes or whatever.
- [24:45]
B
So let's come back a little bit to the pieces that make homebrew work. So we talked about kind of the automations for contribution and the key sort of piece of formula which are building DSLs. What's the engine inside of homebrew? Presumably you have some sort of dependency resolution or things like that going on. And like, what are the. Like I don't know the software architecture of a package map manager.
- [25:07]
C
Yeah, so I mean I don't know that I know the software architecture of package manager either, but I can speak to Yahombru basically where you touch upon dependency resolution. That's the most common thing of value in some ways that a package manager is providing. So if you don't use or have never really thought about a package manager before, essentially the two key things you might say that they are doing for you is one, it's just a way of essentially specifying here's a bit of software I want this installed. You figure out however that gets installed and the way of indicating you want two pieces of software installed should be the same, even if the underlying build mechanism, distribution mechanism, whatever, is radically different between those two things. So it's that abstraction layer generally as well as that there's some sort of version based behavior as well. This is something where homebrews got a lot of flack over the years and we're better than we used to. But again to let's differentiate between different types of package managers for a moment. Right. So you have I guess what you might call, I guess you were saying user space earlier, some might say like system package managers. Right, which would be Homebrew would be sort of an example, but definitely something like APT get on Debian or Ubuntu, something like Yum or whatever on Fedora. I think that's been. Or DNF maybe now I can't remember. It's been a while emerge on Gen 2, Pac man on Arch, etc So those are responsible generally for installing everything that might be on a system or not. And like again you can debate whether homebrew is one of those or not. But what homebrew is definitely not, which people are often more familiar with is a language package manager. So say something like NPM or Cargo in Rustland or PIP in Python Land or GEM or Bundler in Ruby Land, etc etc. These package managers where everything you install through that thing will be written at least primarily in that language. They may also have C extensions or whatever, depending on the language. But essentially you're installing libraries mainly for the writing software yourself. In that language, right? So one of the big differences between the language package managers and the system package managers is the language package managers generally have this model of like, okay, well, we basically can let anyone sort of publish anything. And ultimately the people who are in control of uploading a new version and deciding whether people get upgrades or not are the publishers of that package. And generally the authors and the creators and the repo owners on GitHub. Whereas with system package managers generally, there's a bit of a like, okay, because of the dependencies, which we mentioned earlier, you need to verify that it is okay for everyone to get a new version of a thing, right? So if I decide I'm gonna. I have some library that a thousand packages in Homebrew depend on, I release my version two and I say, okay, Homebrew, we're ready for version two of the package, right? Like, if I'm in entire control of that happening, then again, depending on the package manager, like, that might be okay. It might be that they can just upload version two and then everything sticks on version one until we manually, like, change it and it says it goes to version 2. So homebrew was designed from the early days to be, again, more package manager terminology, I'm afraid, what you call a rolling release package manager. So things like Ubuntu or Debian, you might be familiar that they have. Every so often they've got, you know, I can't remember what an Ubuntu one is, but it's, you know, like Poetic Pelican or, you know, it's always like a, you know, two letters the same, or Debian Buster or whatever, right? So they generally, the way they do that is they say, okay, we're going to like, branch off a while before we essentially get all the packages. So they're like, vaguely stable together. And then we have a point where we say, okay, we've released this new thing. We basically are only going to do security updates and bug fixes until, you know, there's ways of you working around that. But by default, that's how we're going to do things. Then you have a rolling release package manager, which is what Homebrew is, which is essentially you get the newest version of everything all the time. So if you just type Brew Install, you know, some package name, say MySQL right? In Homebrew at least. Let's simplify things. And look at Homebrew 10 years ago to start with. Like, if you Type Brew install MySQL you will always get the newest version of MySQL right. And if yesterday, whoever it is that owns MySQL nowadays, Oracle dropped a new major version and we're on MySQL 10 and it has no backwards compatibility with MySQL 8, tough luck, all your shit's broken. But Homebrew is internally consistent, so it's fine. We evolved from there to being like, okay, well then we're going to at least have CI where we're going to test and make sure that everything works within Homebrew's ecosystem at least. So you're not breaking any other packages in Homebrew. That's one of the fun artifacts of our CI, is that when that happens with something like OpenSSL, which has thousands of dependencies, what that looks like is a CI job that will take two to three days to run of continuously churning away for like 40 hours. We've had various CI providers and hosting providers who assume that that's a typo. We say that, hey, your timeouts are triggering too long. They're kicking in after, I think, like one time. It's like we're kicking off to 48 hours and they're like, oh, do you mean like 48 minutes? No, 48 hours, yeah. Surely it's not taking longer than 40. No, yeah. This job takes up to 72 hours to run, so that's been a little bit of a surprise. And again, that's part of the reason why people, when they might critique Homebrew and Homebrew's model, it's like, yeah, like this. It's hard to do this stuff at this sort of scale. Right. And then more recently, Homebrew has done a bit more around versioning. So now you can install MySQL at 5.7. Right. And that means that you will sit on that version forever. Right. But because of Homebrew's original architecture, the way we do that is we maintain a separate MySQL at 5.7 package and we have to maintain that indefinitely. And if there's something that has to happen to all the MySQL versions for a new macOS version, we have to essentially port it between all of those. Right. So there's a little bit of overhead there, which is why we don't do this for every single package all the time.
- [31:39]
B
Yeah.
- [31:42]
D
Capital One's tech team isn't just talking about multi agentic AI. They already deployed one. It's called Chat Concierge. And a simplifying car shopping using self reflection and layered reasoning with live API checks. It doesn't just help buyers find a car they love. It helps schedule a test drive, get pre approved for financing and estimate trade in value. Advanced, intuitive and deployed. That's how they stack. That's technology. At Capital One.
- [32:08]
A
You'Re a professional software engineer. Vibes won't cut it. Augment Code is the only AI assistant built for real engineering teams. It ingests your entire repo, millions of lines, tens of thousands of files. So every suggestion lands in context and keeps you in flow where other tools stall. Augment code sprints. Unlike Vibe coding tools, Augment code is built for shipping to production and you don't have to switch tooling. Keep using VSCode, JetBrains, Android Studio or even Vim. Don't hire an AI for vibes. Get the agent that knows you and your code base best. Start your free trial@AugmentCode.com.
- [32:48]
B
So that is interesting. So what CI CD provider are you using today?
- [32:53]
C
So nowadays we use GitHub Actions but we have our own self hosted runners for doing a lot of the hard work basically. So particularly on like macOS. Like essentially we need the newest version of Mac OS pretty much as you know like a month, two months before Apple release the new version because we want to be able to test things and verify things or whatever and we are yet to find a we would ideally use an entirely hosted solution. We are yet to ever find an entirely hosted solution who can do things as fast as we need them to be done, but also provide like you know, 72 hour timeouts on things. So our self hosted runners used to be again like a little bit of fun open source lore used to be physical Mac minis that were originally installed in a data center by me taking them down in a suitcase from Scotland on a train which ended up going in the car of someone whose podcast I listened to who let me stay in his house and then put them in the data center of his ISP and then later I took another train and then moved them up back to Scotland and blah blah blah. So yeah, so there's a bunch of fun and games that happens with this. Before this stuff was available for by cloud providers, but nowadays there's a company called Mac Stadium who we worked with for a long time now probably coming up to 10 years who provide like hosted Macs for us to use and they've got like a nice sort of kubernetes like abstraction layer that lets us kind of spin up and spin down VMs of the various Mac OS versions we need to run. So yeah, so that's basically what powers are like CI, like the, the actual. Where the code is being run and built side of things. But yeah, but then the, the main, almost like centralized server now is all on Gap Actions.
- [34:47]
B
Who funds that? Do they donate those resources?
- [34:52]
C
So originally Mac Stadium donated all of the resources and then Apple helped. When we were in the Apple Silicon transition, that's the first time, I guess Apple like gave us something which was nice. So they got us access basically to a bunch of free Apple Silicon hardware. And then eventually essentially we, well, and this is to be very clear, this is completely fair enough of Mac Stadium. But essentially we kept on being like, we need more, bigger, faster, etc. And they were like, yeah, like, I think you can pay for some stuff now, right? So we have basically we pay Mac Stadium but we receive a very heavy discount. And you can see if you're interested in Homebrew's finances and financial situation. I guess that's another fun little thing where all our finances now are on, I think called Open Collective, which is essentially, if you imagine that you, if you imagine your like personal banking app, right, and you can go and see all the transactions and oh, you know, 223, on this day you spent this amount with this vendor or whatever. It's essentially that. But like the ledger is public. Like you, anyone can go like Kevin, you can go and see how much money like Kumbru received and spent and from whom in the last year. And you can also see we do a small maintainer stipend of like, whatever is like $300 a month for people who are still active on the project. So you can see who got that stipend and when and how much and when it was paid out and all that type of stuff. And obviously like, you know, this sounds like a privacy accident waiting to happen, but Open Collect have been very good about making sure everything that should be private remains private and whatever. But yeah, it's quite cool. It's a quite cool open source way of doing funding where rather than having very strict rules on how money can be spent, essentially you have like this open ledger approach. So yeah, that's essentially how that's funded. You could literally go and see how much did we spend with Max Stadium last month and all that type of stuff on our Open Collective, if you were so interested.
- [36:55]
B
Yeah, that's actually kind of wild. I'm, I'm looking at it, just glancing at it here. That's very cool to have that level of transparency and to have, you know, for, for a registry, you know, you, you need a lot of resources. And so having that visible and having people able to see like, hey, this is what it costs to make your life just work like this.
- [37:16]
C
Yeah, I mean, we're lucky as well, I guess. I would be remiss if I didn't mention, like, we get a lot of free resources from a bunch of companies as well. So DNS simple1 password formally digitalocean in the past, like, we basically have a lot of vendors who've given us a lot of free stuff, which is very nice and is obviously, I don't know how much of that reaches across the Atlantic to where you are, Kevin, but certainly Scotsmen such as myself are stereotypically very cheap and very careful with our money. So my preferred price for any vendor arrangement is always free. And that is what I've always attempted to negotiate. So, yeah, we're very lucky to have that. And I guess the biggest one, a former employer of mine, and it's been easier to be a bit more sycophantic about them before I work there and after I work there, because I've been on Homebrew on both ends is GitHub has contributed a huge amount to Homebrew in terms of why they've both given us a bunch of money. But also when you download any of Homebrew's binary packages nowadays, that's all on GitHub packages kind of infrastructure, which is primarily a Docker registry, which is why it might be a little bit confusing as to how we are using that for our stuff. But yeah, but basically we had a situation, I can't remember how long ago it was, five years ago maybe, where our previous hosting provider Bintray, with about 90 days notice were like, yeah, we can't host your stuff anymore, sorry. So we had to find a new provider and migrate everything over there and whatever. So that was very good of GitHub to be willing to do that. And I remember at the time seeing essentially when the switchover happened, like seeing all of the internal graphs of usage and being like, yeah, like this is, I'm sure, a lot. GitHub Actors has had a lot more usage over time. But like, you know, at the time it was like 50, 75% of the usage of the entire system was people using homebrew. So if we couldn't do that without a big funder like GitHub, and I feel like we're all so used to GitHub at this point that we kind of expect it's just infrastructure.
- [39:17]
B
We expect it to just work. Right, Exactly.
- [39:19]
C
And we expect it to all be all. Just work all the time and be free to everyone, certainly everyone doing open source. So yeah, like I think a lot of my former co workers have and have and do work very hard to make all this stuff work. So yeah, particularly shout out to GitHub.
- [39:35]
B
There's. Yeah, for sure. Let's maybe actually talk about. So you've mentioned a couple of big changes that have happened over the years. So one was migrating to GitHub packages. I don't know if there's more to that story that's worth diving into, but some of the other ones. Actually one I'm curious around is you mentioned originally all of the building happened on developer machines. Right. You install and it builds for you right there. And nowadays very little is happening on development machines. What drove that transition and were there any like interesting technical challenges to make it a reality?
- [40:11]
C
Yeah, yeah. So let me get to that in one second. First, I'll say on the GitHub packages migration, I think it's quite interesting for people of a certain ilk, if that does interest you. Then I did a talk at, I think it was the Staff plus conference in London like two or three years ago. And you can go and find out on their webpage if you go on my website, mike mcquade.com under the Talk section. I think there's a link over there or whatever. But you know, that's basically the. If you're interested In a dedicated 30 minute discussion of why that was an interesting technical thing to work on, you might find that interesting in terms of the source migration. Yeah, like that. I sort of spearhead that the most. Right. So it's pretty much the only concept in Homebrew that I have created myself. Which is why if you hate the naming, then that's my fault. I'm sorry. So we call it, keeping with the beer metaphor and Homebrew we call our binary packages bottles, which are then poured onto the file system. Right. So I created bottles originally as just a way to speed up a select number of packages. Right. So I've been talking to Max and there was, I guess qt, the kind of cross platform programming framework that both Max and I worked on with the past. We were both using it when I was at Mendeley and he was at last fm. So we had quite a lot of experience with that. It was an early package in Homebrew that got like reasonable levels of uptake and the build times were just, well, were and still are kind of bonkers. Like it would take multiple. It would take often close to over an hour on kind of really standard Mac hardware at the time. So there was a element of like, this is not a great user experience for someone to type Brew, install QT and then have to wait an hour before they get what they want. There was also the aspect of just like, errors, right? So you could sometimes get to a point where when you were compiling stuff, particularly back in the day when it was easier to play around with your macOS based system where QT would build for, you know, say it was going to take an hour, 59 minutes and 59 seconds and then have an error and be like, oops, something went wrong. And then essentially you lose all of your progress and state and you file a bug report, right? And we would notice that these bug reports were sometimes like, well, very often when building things from source, the number of bugs that were just like, this user has done something weird with their machine, right? And we were able to defensively improve some of that. But it became pretty apparent that like, essentially when you build a bottle, rather than like say something like qt, you're running a compiler and linker to do various things of various libraries and move things around and install things and blah, blah, blah, blah. And when that was all happening on the user's machine when it was building from source, everybody would say there's just so many things that can go wrong. Essentially you're running probably over the course of that build system, probably in excess of like a million, maybe 10 million, maybe even like a billion separate shell commands, any of which failing for a particular reason will take down the whole thing, basically, right? So whereas this kind of bottle architecture we moved to was essentially, again, I'm not a particularly smart guy, so I believe in the simplest solution to any problem. So essentially the bottles are just a tarpaul, right? It's basically just we build that, we run all those commands. Originally, the first few bottles were like, literally I just build it on my personal machine, on my MacBook. And then we have. We run Brew bottle. Cute. It spits out a tarball. We upload the tarball, we provide the checksums for the tarball so that, you know, it hasn't been tampered with. And then people download that Tarball and it saves them an hour, right? So that started off being like just on, you know, and I guess I say the commands from before, essentially you go from a million commands to being essentially download Tarble, extract tarble. And the ways in which that could go wrong were dramatically fewer and it dramatically reduced our Support burden. And going back to we said way earlier, again, a big motivation in Homebrew has been some of the changes which I pushed through that have been very unpopular in the package manager have basically happened because I'm like, without this, this project will die. We do not have the resources to deal with the amount of incoming support requests we have for supporting this power user feature, which maybe lots of people love, but like generates a really spectacular number of support requests. So we are going to do it this new way, which is a way that we were actually able to support. So that was another motivation of this stuff is it's just like, because fewer things can go wrong, fewer people submit issues and we're able to maintain the package manager better at the cost in some cases of some flexibility for our users.
- [45:01]
B
Yeah, well, and it highlights, right, all engineering is about trade offs. This is a trade off that you absolutely had to make in order to support the number or the sort of scale that you're at. Do you do those binaries, are they statically linked or can they reference libraries on the system? Or like how do you, how do you navigate like dealing with library code or other system dependencies?
- [45:24]
C
Yeah, so most of the time they're dynamically linked. So we will link to stuff provided by Apple, we will link to stuff that's provided ourselves and other packages, bottles, libraries, et cetera, which is where things get a little bit more complex because if you upgrade a library and then you have to rebuild everything and that's how you get your 72 hour CI jobs. But yeah, so that's essentially these cascading chains of dependencies where you have to ensure all the linking between all of them is consistent and stable and all that good stuff.
- [45:55]
B
And you sort of alluded to another change which was this removing optional compile flags or kind of reducing the sort of set of options available.
- [46:03]
C
Yeah, so that's probably my, I would say most impactful in terms of making Homebrew long term scalable and maintainable, but definitely the most overwhelming negative feedback I've ever received for any bit of work I've ever done and was probably the first thing that built me a much thicker skin in open source. In fact, speaking with thicker skinned open source, like just as a funny anecdote, again like. So right now I have a person who was banned from the Homebrew issue tracker last week who is now on his third new email account that he signed up with just to send me a piece of emails. And I'm having this fun back and forth of he has now had two GitHub accounts banned and I'm just going through not replying to any of his emails and one by one taking the time to make sure that every new email he signs up with gets banned for this email provider. So it's, you know, like only with maybe 16 years open source could this become a fun pastime of like recognizing every time he's going to try and log into some new email provider or GitHub account or whatever. Like seeing that it's banned and me taking the satisfaction in that despite not seeing like him actually seeing any response from me. As an aside, like. So that example you mentioned with the options again, this was a. I think that became the natural end of the road with the. So as I mentioned, we started off doing the binary packages just for a few select packages and then we got to a point where we were like, okay, basically everything is going to be better with these binary packages. But the problem is if we provide options we don't really have, we have never built and like all these things in open source. If someone had come along and built this, I, I would have been delighted, but no one did. We don't really have a way to kind of have this optional behavior with our binary packages. And what happens is when you provide these compile options, then those people are just falling back to building from source. We go back to this world in which everything is again, very complex. Lots of things can go wrong, we get lots of issues filed. But also when you have again, this is obvious to anyone who's done a decent amount of even probably high school level maths, but if you have one option in a formula, then you have one thing that can. Then you essentially have a. That can be on or off. That's two combinations. Right?
- [48:26]
B
You get the combinatoric explosion.
- [48:29]
C
Exactly. You've spotted it. Yeah. So you have two, you have that, you have three, you have. So we would have. Many of our popular formulas would have 5, 10 different options and there's just a, from our perspective felt obviously not literally, but a perceivably near infinite number of things that could go wrong. And just we ended up constantly having this whack a mole. Right. And some of the kind of power users said, well, you know, you could have just said that people shouldn't file issues and you know, like, you didn't need to take away our toys just because some people were misbehaving with them. And it's like unfortunately again, with the scale of something like Homebrew, you only need 0.1% of users to be regularly doing the wrong thing before you just have this absolute deluge of noise. And what happens is, again, it's funny because there's a lot of talk for a while about problems in open source and funding and sustainability and scalability and all this type of stuff. I think a lot of that's overblown. But one of the things I do think is if you want to talk about sustainability in open source, the scarcest resource available in open source is the time of a maintainer, right? Money is good when it can give you more time for existing maintainers. Often it cannot, but in this case you can say, okay, we'll just close these issues, don't respond to them. But it's like. But every time a maintainer, and often with the way GitHub's notifications or whatever work, it's not just one maintainer reading that, it's 1 or 5 or 10 or 20, right? Like say even one person reads this, you know, if we're getting 75, 90% of our issues are just this noise, then that is all time that that maintainer. I guess in many cases it was often me, cannot fix your bug, I cannot release your feature, I cannot release a critical security vulnerability update because I'm spending all my time triaging just all of this noise, which essentially the only way to make it go away, because we would tell people again, like, don't file these issues, please. People keep filing them. The only way to make it go away is to take your toys away and say, sorry, this kind of option behavior, it does not work for us to be able to maintain a scalable package manager with these around. And yeah, to this day I still meet people who are very disappointed in this choice, but I think if they were aware that there was a time when it looked like we either do this or literally the package manager will die and everyone will quit, then they would maybe realize that like, well, that was preferable to the other outcome.
- [51:01]
B
I mean, I spent a couple years, about a couple years as a primary maintainer for a big open source package. I was paid to do it. Right? It was a job. And it still is so exhausting to deal with the noise. And yeah, that is hard. So how. This is one example of a way that you've made maintaining homebrew a little bit more sustainable. How do you think about creating a sustainable environment for your team of maintainers?
- [51:29]
C
Yeah, I mean, that's. I guess that somewhat alludes back to the. The thing I said earlier. Well, two things, I guess. So One is the most valuable primary resource is maintainer time. And to me, what that looks like is, I mean, in a funny way, you could say maybe even maintainer time is an output and the input is maintainer motivation. Right. So what that looks like is most of our maintainers, right. As I've mentioned, people receive a small stipend of like $300 a month. I mean, some of my maintainers are maintaining, are like, you know, merging 300 pull requests in a week. Right. So the dollar buy time, like compensation.
- [52:14]
B
You don't do this to make money.
- [52:15]
C
Exactly. It's not a money driven thing. Right. Even I guess me working on it for 16 years, like the vast majority of this time I have never been paid anything to do any of my work on homebrew and the. And there's never been a time when I've had more than maybe a couple of months where my primary paid responsibility has been doing anything related to homebrew directly. So like, as a result, you need to just be like, how can this stay interesting and fun and healthy and whatever. And what that looks like again, something which I've got a bit of flack for, but I very much stand behind is homebrew has to be a safe space for the people who are working on it. And that doesn't mean, you know, we can't have challenging conversations and it doesn't mean we can't disagree and whatever. But what it does mean is if someone is being abusive nowadays, it used to be I would give them, you know, two strikes, three strikes, whatever. Nowadays my general policy with on open source and somewhat in life is if you are being a very unpleasant, mean person, even if it's completely unintentional, like I have found, if you receive one notification saying, hey, this is not okay, your behavior is not being appropriate, that you can judge how well that will go from the person's reaction to that. Like someone who even tries and gives a horrible apology about like, I'm sorry you felt that way, blah, blah, blah. Like you can still tell that like they're trying. They've maybe never heard a good apology, they maybe never given a good apology. But you know what? They're trying and they're trying to adjust their behavior like those people, I will give them a bunch of chances. But when someone is called out on their behavior in that way and their response is to double down or get incredibly defensive or say, well, no, actually you're the problem. Like you, you go read your code of conduct, you're bullying me or being mean or whatever it may be, right? Like that never ends well. And if you read through people getting blocked on homebrew, sometimes people get blocked on homebrew for what seems like almost nothing. But the reason why they get blocked is because a we've had a conversation privately as maintainers about this and what's going on. Sometimes there's a bunch of stuff where someone only says one borderline thing in public, but they've sent a bunch of private emails to a bunch of people which are significantly worse. But often it's just like, I've been doing this for 16 years and frankly I can just tell when this is not going to end well. So the quicker we can just shut this down, the better, right? And I think that's what it looks like. Another, I guess maybe more recent addition is for the last maybe six years bar a couple years break with COVID we try and have most of the maintainers meet in person once a year, right? And if you looked at people's contribution graphs on GitHub, there is an explosion of activity when that happens because again, people like to re energize and you meet people. And also like when I promised I was going to review someone's PR and I see them in person and they're over drink, they're like, oh, did you review that pr? I'm like, oh, I'm really sorry, I'm going to go review it right now, or whatever, right? And that's helpful and it's energetic and it's something I felt like I learned back in the day from KDE of like going to their conferences when it was like hundreds of maintainers back in like whatever it was 2007, 2008, and just seeing like, oh yeah, you need to build something I'm not very good at personally, but you need to build a community. We talked about the community of contributors. There's also a community of maintainers. And that needs to be a small group of people who remain actually regularly using and contributing and maintaining homebrew who feel like they're a bit of a team and they have some sort of sense of collective identity together. And I think that helps a lot. And it also helps with, as I mentioned before, with kind of people being abusive is like, I just go into, even before I had kids, I go into protective dad mode and I'm like, you know what? You can say a lot of shit to me. But the bar, what I'm going to tolerate for my team of people who are spending their evenings and weekends trying to build you Shit that you get to use for free. My bar of the amount of abuse I'm going to let you give them is not very high. And if that means that Homebrew has lost some valued contributors over the years who we just needed to tolerate that every few months they were going to go and be very rude or ruin someone's day, so be it. Fine. We can be less. That's the one area of almost like productivity decrease I will happily accept is like, if it, if we can have a twice as fast homebrew where everyone has to deal with assholes all the time, or we can have a half as fast homebrew, then we can have a half as fast homebrew. That's a nicer place to deal with. I'm aware of saying that, you know, if you Google Mike mcquaid asshole, there is a. It's a not minority position that I myself am an asshole, but I do this from a position of trying to make it a better friendly place for people.
- [57:08]
B
So, yes, I think I have no stake in this and I'm not in the community, but I wish more parts of the tech ecosystem had that type of zero tolerance for asshole.
- [57:18]
C
Yeah, I just, I don't know, like, again, not naming names or employers or whatever, but I definitely, I'm sure you're the same character. And where there's been people who've had problematic behaviors at previous companies I've worked for where the signs were there in the first week. Right. And, and I, I have said that like before when I was like, so long as I have any influence. Right. If you push the boundaries, I know you're coming really close to the line in your first week where you should be in a good happy place, you should be trying to impress your coworkers. We should be trying to impress you. If that's the first thing you do when you enter a company. Not a good fit. Right. As far as I'm concerned. Because at the end of the day, you know, and again, that's the other maybe difference with Homebrew compared to some other projects is that like, we are, you know, we have a lot of perks that you don't get at work in that no one can really tell anyone what to do. I can tell people I'm not going to let this PR be merged as is. But I can't say you have to go off and write this code by tomorrow or else, you know, like, no one gets to do that. That's nice. And you don't, you know, so you don't really have bosses bossing you around to the same extent. But the flip side of that is like, you know, I, I want us to have the level of interaction that would be considered standard in a workplace. And that means that, you know, just being abusive and like flaming people and whatever and like losing your temper, like that's, you know, these things happen. But like, essentially you're, how much slack you're going to get cut is proportional to how much time and effort and energy you've put into the project. If the first interaction we've ever had with you is very negative and angry and whatever, then no, not interested in continuing that. And this has unfortunately happened with Humber in the past. If you're a prolific contributor who's been very involved, maybe a maintainer for a long period of time, and over time those rates of problematic behavior rise and rise and rise and rise and rise. Eventually we're going to have a conversation where it's like, either you need to fix this or we need to part ways. And much as like in a job situation, you can sometimes have those people who, they used to be great, but either they changed or in happier ways, the culture changed, right? And we all change to be people who are not going to tolerate that anymore. And I guess if there's a last note on that, if you're a maintainer listening to this, I would encourage you to read like one of my most cited posts as far as I could tell that I'm the proudest about is a post I wrote a few years ago called open source maintainers owe you nothing, which is basically, if you look through the licenses of open source software, then that's what it says. Essentially it says we do this without warranties or disclaimers or promises of damage. And how much of this is legally enforceable is debatable. But literally most open source licenses say if a maintainer was to push out a change that deliberately destroyed all the files on your machine, like in agreeing to the open source license and using that, you are agreeing that you can't hold them responsible in any way for doing that, right? I think most people would agree that's when it crosses the line is being like, ah, maybe you're legally okay, but that would at the very least make you a bit of a dick. But the thing that I think is so crucial about that way of thinking is it's like if you're a maintainer, you do not have to do anything that people don't want you to do, right? And if your project maintaining it is not fun or interesting for you anymore, and you're just being guilted into doing things, then you can stop. And that's okay. And not only is it okay, you probably should do that. Right. And you need to find a way to have your responsibilities on that open source project be something that actually you find interesting and engaging. And as you mentioned before, Kevin, like, sometimes the way you can do that is like, I take a job where I get paid to do this and sometimes I don't like it, but then I look at my bank balance and I'm like, okay, this is fine because it's worth what exactly.
- [61:09]
B
Yeah. If you're getting paid for to do a job, there will be parts of it you don't like that you still should do. If you're not getting paid, which most open source maintainers are not, like, you darn well better enjoy it.
- [61:21]
C
Yeah. And even on you not getting paid, like, I guess I would extend that to say you're getting paid like a reasonable market rate. Right. Like someone who's getting $10 a month of GitHub sponsors also does not owe anyone anything, really.
- [61:34]
B
Correct. Yeah, for sure.
- [61:36]
C
I think this is the thing. And to me, this is again back to open source sustainability, where I think like the. Without sounding too, I don't know, like cliche or whatever. Like, I think a lot of sustainability comes from within and it's about figuring out like, what is sustainable for me as a human and what can I do and what is, you know, since I become a husband and father and whatever, like, what can I do on Homebrew that is not going to negatively impact my family. Right. And that is again, all of the stuff that kind of goes into running an open source project that people don't really think about because you don't necessarily have anyone who's going to be saying to you, hey, like, you know, like it's 11 o' clock on a Friday evening, like, you need to be up early tomorrow. There's a problem with homebrew. You're staying up late dealing with this right now. Maybe you just need to let it slide. Maybe you just need to let people suffer until tomorrow morning because actually you need to get a good night's sleep because you're going to be grumpy with your family or whatever have you done. And in most good workplaces that I've been in, your boss or your co workers would be the people nudging you in that way. Whereas in open source, again, historically there's not been as much of that. And something, again, I hope for Homebrew sake. And we do see a bit of that is when people are saying like, oh, you know, I need to stop till this is fixed. And people are like, I got this or this can wait, right? Like, you need to look after you. And like, that's the stuff that keeps people around and happy and, you know, keeps human maintainable as well as the software 100%.
- [63:12]
B
All right, well, we're coming close to the end of our time here. Is there anything we haven't talked about yet that you think would be important to touch on or leave people with?
- [63:20]
C
I don't think so. Especially, I guess just to maybe extend even more of what I was saying before. Like, you know, I guess I found in work in the industry for whatever it's been like 18 years and open source for, you know, 16 with homebrew and a few more. Like a lot of this stuff that I maybe dismissed when I was younger about the human interpersonal stuff and squishy feelings and therapists and boundaries and all of these like, you know, oh, cheesy grown up words or if you're Scottish, like, cheesy American words. It's, it's all really important at the end of the day. And like, this is what stuff is built on the back of. And like something I, I really admire when I am looking at, you know, the LinkedIn or resume or CV or whatever you want to call it of a person who's applying for a job or I'm going to work with or whatever is like, you know, we've got this industry expectation that like, you know, you don't want to be at too many jobs for like a year or less, right? But I really love when I see people who've done one thing for a decade or more, right? And I guess like almost like a challenge I would put to anyone listening to this is like, what would it take for you to be happy in your job or your industry or your open source project or, you know, maybe to be even deeper still, like your marriage or your house or your friendship or whatever. What would it take for that to be still in a really good place in 10 years, right? And think about what you can do to get there. Because, you know, I used to say to myself, like, oh, you know, I've got 10 years of home premium, I'm going to quit. But then I'm like, well, you know, maybe I've got 20 or 30 or whatever. I don't really know because it remains sustainable for me to do and it remains hopefully at least beneficial for others to kind of receive the kind of work I'm doing. And I think. I think the world is much better when people can focus on that. And often, you know, to quote every flight attendant or whatever, like, putting on your own life mask first, like, helps us all be able to do more better stuff together than it does when we're mothering ourselves and then we burn out in two years or whatever.