Screaming in the Cloud - How Homebrew Became Mac's Package Manager with Mike McQuaid

Episode Date: January 27, 2026

Mike McQuaid, Project Leader of Homebrew, joins Corey Quinn to share how a package manager conceived in a London pub became essential for 10 million Mac users. Homebrew lets you install software with one command instead of downloading files and clicking through installers, maintained by just 30 people who each get $300 a month.Mike shares the origin story from a drunken conversation about package management, explains how Homebrew Bundle can set up a new Mac with one command, and why Homebrew refuses to package software with fake open source licenses like Terraform's new versions.Show Highlights:(01:44) Why Homebrew Works on Linux(04:02) The Curl Bash Security Problem(05:02) Homebrew Was Conceived in a London Pub(06:42) Apps That Auto-Update Four Times a Day(08:43) Brew Bundle(14:00) Why Homebrew Auto-Updates Itself(18:18) Homebrew Maintainers Get $300 a Month(22:19) The Brew Doctor Command(29:10) Why Homebrew Doesn't Package Fake Open Source(32:05) Open Source Is Not a Career(35:27) When Someone Blamed Homebrew for Breaking Their Business(37:39) Auto-Update Options for Homebrew(39:40) Where to Find MikeLinks:Website: https://mikemcquaid.comHomebrew: https://brew.shGitHub: https://github.com/homebrewSponsored by: duckbillhq.com

If you want to release a new version of your package or whatever, we, yes, we have lots of automate update tooling or whatever that might pick that up. But the process of like actually getting that out to users, one of our humans is always looking at that and saying, yes, this looks fine. Welcome to Screaming in the Cloud. I'm Corey Quinn. And today's guest is one of those he, or at least his work, needs no introduction to most of us. Mike McQuaid is the project leader for homebrew. If you have not been acquainted with homebrew, you either have been living under a rock for 15 years, or alternately, you probably don't touch

MacOS, which is like living under a rock for the last 15 years. Mike, thank you for joining me. Thanks for having me here, Corey. This episode is sponsored in part by my day job, Duck Bill. Do you have a horrifying AWS bill? That can mean a lot of things, predicting what it's going to be, determining what should be negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more, visit duckbillhq.com. Remember, you can't duck the duck bill bill, which my CEO reliably informs me

is absolutely not our slogan. And I feel like I just misstated already off to a great start, because I've always used Homebrew on a Mac, but apparently it supports Linux as well as a first-party target operating system. Am I misunderstanding something here? No, it's, yeah, it's been doing that for a wee while. A lot of people are surprised both that that happens, and then generally the next reaction is, why would you do such a thing? Like Linux has a lot of perfectly functional package managers. Why would you bring your... No, it doesn't. It has things like apt and yum. And now it's replaced by DNF.

There's always a thing like, it's like Thomas Jefferson once said that the Tree of Liberty must be refreshed with the blood of patriots. And it feels like generationally, we need to refresh package management with a new version to supplant the old one in Linux distros.

Every distribution I can think of has gone through this entire process and it shows no sign of stopping. But what's the Linux story for HomeBrew? So the Linux story for HomeBrew, I guess it started out with being a bunch of people in bioinformatics labs who are like, oh, I don't have root so I can't use the system package

manager. And if I sort of like fiddle with homebrew enough, then I can use it to install shit in my home directory. And then like, hey, presto, fast forward a while and a non-trivial number of people use it. And the kind of cross-platform nature is kind of appealing for some people because you can have the same package manager commands on Mac and Linux and CI and development, perhaps and whatever and all that good stuff. And then more recently, we've actually seen like there's a couple of Linux distros that do the whole like immutable route file system thing. And then they use HomeBrew and Flatpack as their kind of primary package manager, basically.

And so that's been interesting seeing those like Homebrew being mentioned on the front page of a Linux distro. That's a new development. Yeah. For me, it came back for a very simple starting point of, once upon a time back in the day, a Thursday, I believe, was the day, but that's neither here nor there. And I wanted to, I was trying to copy and paste a command off of Stack Overflow, which was a best practice, as me as for many of us, and WGet wasn't installed on a Mac. And, huh, what's the best way to get this installed? So first I went down the Primrose path for a couple of years of playing around with Mac ports, because I am an old BSD saw.

And I don't believe that Homebrew really existed back in those very early days, but it was just night. day once I first encountered it. And it had all the hallmarks of a terrible decision. Let's be honest here. Oh, I just copy and paste this curl bash equivalent, though we didn't call it back then, into my terminal. It'll just do all the magic things it needs to do and set it up from a security perspective. It was something of a nightmare. Oh, it'll just install the latest version of everything. So what you run today and the new developer runs next week are going to be not exactly the same thing, but it worked. And I started using it extensively. I started doing some of the packaging for a few things back in the day for HomeBrew.

I'm running my own tap now with a couple of things that have now gotten enough traction that I probably should try submitting them to core and see what happens. But everything I've ever really wanted what lives inside of HomeBrew. And when I redid a laptop for the first time in a few years, a month ago, suddenly all the stuff that I installed that was graphic utilities live within casks, which used to be its own separate thing and now seems to have more or less merged into mainline. What's the history there? Yeah, so casks were, again, you've probably clicked on if you haven't already been familiar with Homebrew before this podcast that we like our beer metaphors over here. This was partly

because Max, the creator of Homebrew, conceived it while under the influence after being in a pub in London whining about package management and having his friends tell him, presumably also under the influence, well, if you're so smart, why don't you make your own package manager? And it turns out Thank God. Usually those drunken, belligerent conversations turned into, and that's how I built a database engine. So at least this one's novel. Yeah, exactly, exactly. So casks were, again, you're seeing a bit of a running theme here, like also a kind of side offshoot of Homebrew where some people were like, okay, homebrew installs all your nice open source stuff.

But what if you could use it to just like download Google Chrome and put that on your machine or one password or any of these other things, right? Yeah, so basically, like, they were running their thing. It got a bit of traction. we noticed in the main project and we like brought those people over and merged the two projects essentially. So that's been one of the nice things with the Humber ecosystem is that over the years, essentially, when people do cool stuff that are like broadly in the ecosystem, we try and like bring them in to the fold and make it all official and part of our main thing. Which is a nice approach. I've also found what I was looking at, the submission requirements

recently, that if you have auto-updating nonsense, Claude is a good example of this, it doesn't really belong in HomebrewCore, that's what casks are for. I guess, how do you view doing an installation dance like that, where at any given moment, what is being installed in your system is not going to be what it was 10 minutes ago? Yeah, I mean, that's the fun of, I guess, Homebrew Package Management. You alluded to that earlier, right? We've always been, I guess, what you would call in Package Management, Nerdland, aka my life, a rolling release package manager. And what you mean by that is like we,

whenever we get the newest version of stuff, if it doesn't break Humberoo itself, we generally just voice that upon people. So in casks, as you say, there's some more extreme stuff where the cask itself can update, auto-update. So Humbru doesn't necessarily even know

the version of the cask that you have installed at this time. But that, we found that works a little bit better than, you know, a lot of tools like maybe ClaudeCode or Google Chrome. or whatever nowadays that end up shipping their own auto-update engine. And it's like... And there are four releases a day in some cases. Yeah, and we could try and fight that.

But again, like, I mean, Homebrew in many ways, like, keeps off to me in terms of, like, I'm exceptionally lazy, right? So it's like if there was some... So say like Debian, right? Debian is a beautiful, morally pure distro. And on a lot of this stuff, they're like, well, if there's like... There's the kindest way you could have found to put that. If they're like got an auto-up date, they're like, yeah, we'll patch.

out that auto-updator and we'll just keep patching it out forever or whatever. Whereas I'm just like, eh, that sounds like a lot of work. If that's what the software project is trying to do, let's try and find a place in our ecosystem that we can slot in and they can do things the way they want to do it. And we can do things the way we want to do it. And users can end up ultimately moderately happy. Yeah, I prefer being able to do it through cask just because that way I don't have to crawl across half the internet to find stuff that I care about. The only time I've run into trouble with it has been, oh, there's this thing that I want to install, forgot I got it from the Mac App Store, and that's where the license is tied to it. So, okay, now I have to

keep a separate exception list for that, but oh, well, too bad, so sad. If you didn't know about this already, I'm going to transform your life here, Corey, right? So they're... Hit me with it. Please. I'm about to redo this machine, so tell me more. Oh, yeah. Oh, yeah. It's coming. It's coming. Prepare yourself. So Homebrew has this thing called Homebrew bundle, which uses brew files, right? And it's loosely based off gem files in the Ruby ecosystem order. So what you can do in there is you can specify your taps, your formula, which are things that built for source supplied by HomeBrew, your casks, your Mac App Store apps, recently your GoCILIs, if you've got them, your Visual Studio code plug-in, someone was proposing

adding cargo, the Rust package manager support in there as well. So that file lets you, basically be like, okay, you can dump everything you have installed to that file and you can install everything on that file. And so you could have like a global wide thing. I keep mine in my dot files. And then I also have a little mini open source project, the most successful thing I've created by myself called Strap, which is basically like the idea when you get a new computer, you run this one script, installs Homebrew, it looks on your GitHub. If it finds your dot files repo, it pulls that down. If there's a brew files inside it, it installs from the brew file. So you basically have like one command you can just run to basically be like,

like install all my stuff and get my all the software on my computer released back to where it was before, right? So hopefully this is going to make your new build experience that bit more pleasurable than it currently is. Yes, and the counterpoint that I find here, because I've built a bunch of these things before. This machine has been around for a while. Let me just, for example, run this now. Brewlist pipe to WC-L. I have 365, which is a suspicious number of packages installed on this thing. So part of me, like a lot of that is stuff I needed for weird one-offs that I no longer need. I honestly, on my laptop, I have about, I know, 15 to 20% of that, where it's, I just, because I just recently did that one, and it'll eventually grow in time. But I don't necessarily

want to have all those things reinstalled. Part of the reason to do a fresh install is to get away from the legacy craft. I have something like four different ways of managing NVM on this system, which is kind of a problem. I want to start standardizing around MISONPri. which is the one that I've found that I like the most these days. For Python, it's strictly UV, system-wide, and so on and so forth. ASDF, get rid of it because its ergonomics are terrible. I can never remember which command parameter goes where, and they're positionally dependent, which is just wonderful, simply wonderful.

I have opinions, and I'm belligerent, and I refuse to learn new things. I am the worst engineer you've ever met. It's great, but I'm also a typical one. Yes, I wish I could say that that rant was not. representative of the typical homebre user, but you will fit in well with our community of people who do not like it when we change their shit. I guess on that, so while I'm evangelizing why brew files will change your life, right? So if you run brew bundle dump, which dumps all your things out, one thing at least of that list of 365 is that it will only output the things

that you have intentionally installed. So anything that was pulled in- Not its dependencies a lot of way. Exactly. Unless you also intentionally install the dependency, in which case that it will remember and know to do that as well. So the little workflow I have after that, like, it sounds like you have a, you know, a world of craziness to unpack, but maybe on this new build, if you're doing it from scratch, then what I do is I have my brew file. I keep that in my dot files directory, which is a GitHub repository and a locally checked out Git repo. And then what I do is I just installed my stuff and then every so often I run brew bundle dump, dash, just global. And then I get my brew file in my dot files repo is like being nicely replaced. And because

it's a give repo, I don't care that it's been replaced. And then I look through the diff. I do a little local review in my local get gooey of choice fork, which I would recommend. Very nice little get gooey. And then I'm basically like, which of these do I want to keep? Which do I want to delete? Right. So I stage it. I commit the stuff that I want to keep. And then I maybe get rid of the changes I don't want to keep. And then after that, I can then run brew bundle cleanup, which will then use that brew file. and then uninstall everything that is not present in that profile. So then I can get myself from a world of chaos into a world of order and serene package management column. I like this quite a bit.

Yeah, honestly, it's going through and like doing the dump on this. Okay, I've got a whole lot of lines to delete in this. Like, rust. When the hell am I going to need rust? Well, the next time I grab something opinionated off a GitHub. But until then, I can enjoy not having to build a conference talk as a prerequisite for writing code. You know, basic stuff in life. I've also seen homebrew itself over the years has changed significantly, where just even the process behind it. It auto updates now, which I think is great.

Your analytics, I think, have been handled in the most user-respectable way possible. The fact itself updates only intermittently, not every time you do stuff, that's phenomenal. It seems to have parallelized itself a lot better than it once did as far as downloads and installs go. Like, someone has put some thought into this. There's an entire, there clearly is some sort of DAG involved. Yes, there definitely is the occasional thought that happens, that results in a change. Several of the changes you've mentioned are things that people still besmirch my name across the internet for, for ramming home against the interests of the users. But the problem is with things like open source, right, is homebrew has we guesstimate about 10 million users from like analytics

analysis stuff where like we don't have, like we have opt in, sorry, opt out. analytics, not opt-in, again, another cause of contention. But you can sort of infer the vast majority of people opt out based on the download numbers from GitHub's packages versus the numbers we get for analytics. So that's our rough guesstimate. So for those 10 million people... It still feels low based upon the sheer number of developers in the world. Most of them use math. Maybe. Maybe that's maybe that is on the lower end. But the number of people who essentially service their requests for those people are 30 maintainers, right? So when you are dealing with that level of scale, A, all glory to the internet and open source for making that sort of scale even flipping possible, but also you end up having to make nasty little compromises sometimes, like say the auto-update thing, right?

Lots of people really hate that. But what it stopped was 95% of issues being, this thing is broken. Run brew update. Does it still happen? Oh, no, it's fixed now, right? And there's only so many times you can respond to that and not write an auto-updator before your brain just turns to pulp. And my brain was starting to turn to pulp.

And auto-update bugs are the worst because how do you fix them? Well, yeah, that's the other beauty. Yeah. It's when you break the auto-updator, which I have done once, that is a whole new world of pain as well, where it's like, but I did everything you said. I ran the updates. Yes, but the updator is broken. So you can't run the updator because the updator won't update the updates.

And neither will the auto update update the updators to run the updates. You have to run another update to update this. So now whatever. I'm going to help my mom with that. Her nothing was working in her browser anymore. Turned out it fell off the Google Chrome update path. Like four years beforehand. Yes.

Yes. And this is why I break out in hives anytime anyone submits a pull request, changing that auto-updator file. Because I'm just like, are you sure? Are you sure you really want to do this? Do you really want to roll the dice and be the person that breaks the auto-opdator? because I've been that person and it sucks. Yeah, but suddenly on the plus side, once you do that, everyone knows your name.

One way to become famous or infamous, I guess. Yes, it's, do you find that people tend to pin particular brew releases? I'm sorry, package releases inside of brew. Like, oh, always install this particular version of this package. Yes, sometimes. So we have like a pin command that lets you do that. But like, the usability around that is kind of like, bleh. The only time I've ever used it has been in highly prescriptive,

Here's how to install a dev environment in old school stuff before the advent of Docker. There's a bit of that. And also, like, what we recommend nowadays is, like, there's, we provide version packages for some stuff. So if that's available. So say, like, it used to just be, there was just Postgres, right? And then Postgres got a new major version update. And you wanted to set on an older version of Postgres. Sucks to be you, right? Like, and then we had a slightly more middle ground now where it's like, okay, now we have Postgres. I forget the version and scheme off the top. my head, but whatever it is, Postgres 18, Postgres at 18, Postgres at 17, Postgres at 16, right?

And you can choose to jump your way between those different packages, right? And for a lot of people, for a Just installing Postgres is the latest stable. It depends. I think Postgres is a special case because we're still dealing with some issues there. But in general, yeah, in situations where it's like, I need this exact version. I need Postgres not 18, not 18.1, and Postgres 1.18.1.3, because that was the best version ever as a particularly fine vintage that year. Then what we recommend in that situation is like there's a command called brew extract

which then pulls Postgres out of our repositories and then gives it in your own little GitHub repository for a very specific version and you have ultimate control over that and you can choose what to do and then you can live in happy stable land. So that's generally what we recommend.

It's a little bit more work but we do provide a bunch of helper commands and whatever. As you've made you notice, again, there's like a brew command to do just about everything, right? So like even within home brew itself, the way we run the project, like we give our maintainers who are remain active, 300 bucks a month if they are like regularly contributing to home brew, which probably contributes about as much money, probably less than your average like paper boy or girl gets when they're 12 years old going around the neighbourhood. I think that's the going rate for open source maintainer nowadays. So, yeah, not a lot of money, but like we have to have a way of figuring out, oh, if someone was on away for three months, like, do they earn that or not? So we have a command brew contributions, which looks at the contributions of the various maintainers in that timestamp, right?

So essentially, almost all of our tooling by default is public, right? And that little tool I use to figure out who gets the 300 bucks in a given month or quarter or whatever, right? Anyone can use that. And you can run that tool. And in fact, there was a bunch of brew. I yelled at just now saying your token needs the readorg scope to access this API. There you go. What a beautiful error message.

If I didn't say so much. It at least tells me I don't have access to a thing, which is great. A brew doctor spits out three pages of nonsense because I've had this machine for too long, which tells me that if ever I need to report a bug against homebrew, I've got some housekeeping to do first because everyone will blame this. Like on brewed files in certain places from all the various things I've used, apparently post-grisqueel 14 is now deprecated. Hazah. Some installed kegs have no formula, which that's novel. I don't know where those came from.

A bunch of casks are deprecated, et cetera, et cetera, et cetera. Like, this is what happens with five years of croft. Yep. Effectively, you've had your yearly health check and the doctor said, how the hell are you still alive, man? Your blood type is chunky, yes. Yeah, it's not going super well here. It's so great. It's time to wind up basically rebuilding things from scratch. But that's, that is the nature of the beast on some level. I've also found historical. that having a bunch of deprecated stuff or packages you didn't, you installed then removed in some some package managers can lead to security issues. Apparently, for a while on one of my test boxes that I use as a dev box, it used, it set up a post-presqueel user with a password post-rasquil,

then I uninstalled the package. The user hung out. So suddenly I had a problem there. Nice. Yes. Yeah. Yeah, I felt real smart after that one. I've also found that you folks are quick to update, where the day of a new macOS release, suddenly I'll get error messages that I'm not installed the latest version of Xcode. It's like, well, that's great. It's been out for 20 minutes. The mirrors themselves do not have it yet, but it's already telling me that, you need to update your stuff if you want to be supported. It seems to have backed off from that jumping the gun mentality's last few releases, so someone's paying attention. This episode is sponsored by my own company, Duck Bill. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them.

Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where Duck Bill comes in to help. Remember, you can't duck the Duck Bill Bill, which I am reliably informed by my business partner, is absolutely not our motto. To learn more, visit DuckbillHQ.com. We try to be like aggressively chill, right? So because we're a bleeding-age package manager, we tend to attract the users who have that. So generally there's like a little almost like internal homebrew bingo about like how soon after the next macOS release gets announced and until until Apple says the developer beta is coming until someone opens an issue on home brew saying this doesn't work yet. Right. I think we've literally had about 20 minutes after the keynote ends. Someone's like, yeah, why is this not working? It's like because we haven't downloaded it yet, you dummies. Like chill your boots. Like but yeah. So we tend to.

do a little bit of that ourselves where I guess we're maybe unlike some software where what we try and do is we're like we're going to warn you about anything that might be a problem right and like if you're not getting any warnings from home brew at all like you know that you have been a good little boy that day right and or have not properly installed home brew or not properly installed homebrew indeed but yeah so like our kind of like brew doctor command I feel like we were one of the first things to do that like what we're trying to do is provide it was a the first time I encountered it back then, most other things called it pre-flight. Yeah, exactly. So we just try and provide a lot of pointers for like, look, if something's broken and someone's not, particularly in the early days of Humber, it's like maybe no one's awake to help you, right? And you want to get this fixed in the next 12 hours. So here's some stuff you can try, right? I mean, I used to be a part of the CentOS project. This was back when I was free node network staff. IRC was the way that I encountered a lot of the stuff and got support for it. And there's one thing that I learned, and that is people are freaking terrible at asking for help in ways that make sense.

So having a doctor command that will identify all the issues with it, and it's almost, it's close cousin to a Diag spit out where it's like, okay, what version of Mac OS? Oh, wow, I don't know numbers went that low. What else is going on with this system that otherwise enough to tease out of people over a period of hours as they start trying to figure out how their system was put together? Yeah, it's funny. So like GitHub has, Homebrew is one of the first users of like the GitHub issue templates, right? Where you have like mandatory information you have to fill in. But part of the reason I think GitHub even has them is because when I was a GitHub employee, I whined about wanting those templates so incessantly that I feel eventually someone just gave up and was like, right, Mike, if it will make you shut up, we'll build these stupid issue templates and no one's going to use them and then turns out everyone uses them. But anyway, so like the terrific Gen AI use case too. That's exactly what I was going to say.

Yeah. Like, so we found, we found them great for that because so our, and again, our to issue template was basically based off. And I used to have like a text expounded shortcut, literally for coworkers, when people would basically ask me for help in a very unhelpful way. And I'd be like, okay, what did you do? What did you think was going to happen? What actually happened?

Tell me what I can run to see the same thing on my machine, right? And if you could do those four things, then like, hey, we've got a great bug report. And also, as you say, like for Jenner, AI, if you could say the same thing, like, a lot of the time, like, co-pilot will, like, one shot, though, if it's completely 100% reproducible and it's well explained in the issue, like co-pilot can go, okay, run this command, got this output, change some code, run this command until it gets the right output, and then, ta-da, here you go, there's a PR, and the code quality might be garbage, but, like, often it gets a decent amount of the way there

if it has a contemplative. The most valuable part of that is the stuff you never see, because I used to do that by hand. A friend ran Ask Me Better.com, which asked those exact questions. There was no real submit button on it. But by the time that you wrote that out and came up with a repro case, you realized you were the one that forgot a comma or something weird had happened. And, oh, I misread the documentation. Like, the best requests for help that I've ever written are the ones I never submitted anywhere because it's solved my problem going through that process. 100%.

And that's a big part of the goal as well. And ironically, the people that find those flows to be overly prescriptive are often the same people who, if they slow down the rents the flow, they might have avoided having that issue in the first place. What's the security posture on this stuff look like? I mean, I know that at this point, enough people use HomeBrew that if I can compromise the W-Get package, for example, suddenly everyone's going to run the code that I want them to run.

What are the safeguards on this? I know that Pi Pi, whoever they pronounce it, I get yelled at if I'd say the wrong one, but I can't remember which is which. They have an entire security team that works at this stuff. It's pee-p-y, right? That's what I'm going to go with. that I'm sure that Mike Fiedler, who runs that will not punch me in the mouth the next time you see me before. Yeah, so, like, we're lucky in Homebriland in that our trust model is very different to Pi Pi Pi, P, P, whatever we call it, MPM, Ruby Gems, etc.

Right. So those package managers fundamentally have a trust model of we will trust people to do some verification of the people who stuff they download, right? And we will not be a gatekeeper middleman, whatever, unless it's like gratuitous. obviously that this is malware or whatever, right? I'm sure some of those folks would say that's a gratuitous simplification and I'm being very meaning and unfair or whatever, but oh well, that's me. Whereas in homebrew, every single change that happens in homebrew, a human homebrew maintainer

has to verify that, reviews the code and says, this looks okay, right? So if you want to release a new version of your package or whatever, yes, we have lots of automate update tooling or whatever that might pick that up, but the process of like actually getting that out to users, one of our humans is always looking at that and saying, yes, this looks fine, right? And same deal with the way we kind of build packages and things like that. Like we operate our CI. Like we were pretty early to the party of having essentially binary packages built from users' pull requests on GitHub and then just deployed straight out to users, right? With, again, with human intervention. But like, as a result of that, we have built

everything with a trust model that essentially you can't trust anything ever, right? And all of our CI workflows essentially treat even the code they're running most of the time as like untrusted input, right? So we generate, you know, for example, when we generate a binary package, we then generate JSON that describes the binary package. And then later we read the JSON because you can't embed arbitrary executable code in the JSON like you can in the Ruby files. Yeah, exactly. Challenge. Challenge. did anyone. But yeah, so, like, that's what we try and do. So, like, our trust model, and we are lucky enough, careful enough, whatever it may be, to touch wood have not had any major

attacker-driven security vulnerabilities. I guess if you go through the Humbrechtel blog, you can see we've disclosed things in the past. I think our worst one was based on a Jenkins misconfiguration, which... Was it called Jenkins? Yeah, well, so that's one of the reasons why we don't use Jenkins anymore because Jenkins misconfiguration was rather easy to achieve, I would say. But yeah, like generally, I think we've had a fairly good track record on this stuff. And obviously, as I think Homebrew may have been the first project to create the curl-to-bash pattern, right? So people are going to hate us forever for that. But I think in terms of actually user experience security problems as opposed to just people in the security community

shouting at us and calling us morons security problems, I think we're doing all right. I do want to ask before we call this an episode about your approach to open source. I mean, the triggering event that's, oh, yeah, I should really talk to you about this, was a LinkedIn shitpost that I did somewhat recently about the experience I had when I did a brew install terraform, and it's like, great, this is an old version because the new versions are not open source license. SSPL is not open source or BUSL, wherever the hell they're using. and I thought that was a terrific position to take. Some people are whiny about it, and I honestly don't care about them.

Because why don't you do volunteer work for an IBM subsidiary is one of the dumbest things I can think of to ask you. Yeah, so, I mean, our view on this is, so what we say in Homebrew is we have Humbrough, which was our kind of original package manager, like open source stuff we did. And at some point, we're like, okay, we say we're only packaged open source stuff for you. What do we actually mean when we say that? The nicest definition we came across was the Debian free software guidelines, right?

And they are not, as it might sound like, if you're not someone deeply versed with open source or free software, whatever. Essentially, everything within their description is open source. And it's a nice, clear definition of things, right? And we have a body called the OSI, who we also look to for advice, who were essentially the body that came up with the term open source back in the day. And I have the controversial viewpoint that words mean things, and it's a good idea to make words continue to mean things, such as don't say literally when you don't mean literally, and I will die on that hill. Figuratively is the word you're grasping for. Exactly. So with open source, we have rules on this stuff.

And when various companies lately have decided to, I guess, hatchy corpse projects as an example of one, maybe Redis, maybe Elasticsearch, maybe MongoDB, when they as, as a lot of GoogleDB, when they, as, as a lot of research, when they, as, VC-backed businesses decide that their business model is not well suited by their current open source license that they have just happened to rely on to get a nervous amount of adoption of the last decade, right? And they decide that they're going to change that and re-license everyone's contributions over that period because they were foresighted enough to require everyone to sign over their copyright, which allows them to do that. Incidentally, Humbrough, various other projects do not do that. Then what that means is that they can do, as you described in that LinkedIn post, a rugpole, and everyone's left going,

well, wait a minute, is this open source anymore? And the companies, much to my chagrin, will say, yeah, oh, yes, yes, this is totally open. So we're just, it's just open source, but if you want to make any money, then you need to give us all of your money. But, I mean, that's completely open source, right? Like, it's fine. But again, as I say, when words mean things, it's like, well, in open source, you don't get to do that, right? And I had a lovely conversation. I will not volunteer for your for-profit enterprise because I won't let people volunteer for mine. When I contribute to open source, it is open source to which I am contributing. Honestly, sometimes to that project's detriment because I'm terrible at it. But, you know,

it's not for lack of caring and it's not for lack of philosophical purity. It's, there's a, there's a sense that there are things I will volunteer my time and energy for and there are things I will do with a hope of making money out of it. And I try not to cross those streams. Yep. And I think that's very wise, right? Like I was on a podcast recently with friend Justin Searles and it was kind of cross-posed to the change log in which I said like open sources not a career right like open sources not a business model open source is also not a career right and I think we have seen a bunch of people conflate these ideas that you need to pay all open source maintainers a market rate tomorrow otherwise it will not be sustainable and similarly with

companies a company should be able to just release open source software not charge anyone any money forever and then like when they got upset that that is not not a viable business model, they can change their license and point it in the big cloud vendors and say, like, wow, they're stealing our stuff. And it's like, well, they're stealing your stuff because you said it could be taken. That's what your license says. Back when there was a New York Times article about Amazon, strip mining open source, like that, that's not accurate to my mind. They are doing nothing wrong. You can talk about whether they should be contributing back, but that's one of those appealing to our better angels. That is not one of those if they have an

obligation to do so. Now, I mean, Amazon does not do philanthropy. Let's be honest with ourselves. They're Amazon. They don't know what that word means. But so, okay, the problem that these companies made is early on, and I have some sympathy for it, is in 2010 or so. Well, we wrote the code. Clearly, we'll be the best ones to run it as a service. That didn't pan out. Now you have people starting open source-based companies and they want all the benefits of open source without any of the drawbacks. Like, oh, should never have launched that project with an open-source license. He'd have a would have it if you hadn't. So what's the story? And the way I like to deal with this instead, right, is, again, blog post I wrote a long time ago. A lot of people don't like me for it,

but a bunch of open source maintainers do, so worth it, that I titled open source maintainers owe you nothing. And if you read any open source license, it essentially says, hey, look, if you use my open source and it breaks your computer on purpose, then, sorry, you've agreed in using it that you waive me of all responsibility for that. So tough luck, right? And to me, the way, if you say, you know, say Amazon, right, Amazon's strip money on my own source, they're using this off. Well, what you can do is just if anyone who is an Amazon employee ever submits an issue on your project, you can go close and say, I don't want to fix that. Your company has lots of resources. They can do what they want with their open source project.

I'm not going to help them, right? You can choose to not accept issues. You can choose to not accept pull requests. You can choose to not respond to anyone from Amazon on your issue track, ever again, if that's what you want to do. And you, as an open source maintainer, have the right to do whatever the hell you want. And this is the beauty of it, right? And I think this is the problem. It's a thankless job. I've got to take the other side of it,

where most of the stuff I write these days, I used to open source all of it because why wouldn't I? I'm sorry, but this way to wind up running a command simultaneously on 15 nodes at once in every AWS region, that's not a competitive differentiator. That's just something I want to exist so other people can use it.

These days, I'll write quick one-offs, and I'll keep it in a private repo rather than open-sourcing it just because I don't want to hear it from people. Yeah, yeah, because the level of entitlement is often crazy, And this is a yolo coded thing in half an hour or so. I just want it to work. Great. I know that you have other use cases for it. Go with God. Have fun. But I don't want to hear about it. I don't care. Vibe code it yourself. Yeah. And honestly, my code should mostly be told as a cautionary tale. The thing is, as well, is often the people are the most entitled about it. Ironically, are often the people who are the most reliant on your free gift for them to do their job. I remember one time we upgraded a version of FFMPEG or changed the codec or something in Humbru, right? And someone said, like, I'm running my entire business of this and you people have just broken my entire business like have you no shame and I was basically like sir have you no staging environment like you have learned a lesson today about relying on other people's software given freely if if you're literally running brew update

and brew upgrade and that hoses your entire company this is what we call a you problem sir and not a me problem I didn't tell you to do that you decided to do that and now all your stuff's broken like If you're running latest or any other bleeding edge package manager in production, it's just a matter of time. Yeah. And in some ways, again, this comes back to what you're saying about the, you know, well, we built it. We should be the best to run it in production. It's like, well, no, like you've demonstrated your ability of being very good at running a database open source project. You did not demonstrate your ability to provide a multi-region, multi-culture, like massively scalable cloud

provider, which is essentially what if you're offering a hosted database provider in 2025, that's what you're doing, right? And chances are, AWS is probably quite good at that. They probably have quite a lot of people who are quite good at that. And again, like, sorry, folks, this is capitalism. I don't feel bad that you, as a company, trying to make lots of money, pick to fight with another company who are also trying to make lots of money, and you didn't win. Like, you don't get more sympathy because your code happens to be open source, right? Oh, for me, there's a reason this entire company. for the last half hour has been about what we do on developer workstations. I have asked you

none of the normal questions. I would if you were building a package manager aimed at, you know, production environments because I have a whole different laundry list of this. The closest I run into this is, as I mentioned earlier, well, the next developer we hire is going to have slightly different versions of everything in their environment theoretically. I really do hope that the people are updating their packages on a consistent basis, which brings me to my last question for you here. have you ever given thought to having brew auto update on a schedule both itself as well as the packages that have been installed from it? Yeah, so there's actually, again, a nice little external command for this, which was briefly in the home brew ecosystem and then we decided it operated

better independently elsewhere. By it's not your problem. Sort of, yeah, by a lovely chap called Dom, who used to be a home brew retainer. And it's called Homebrew Auto Update, if you search for that. And yeah, you can basically have that as a cron job that basically every night, just in the background, will just bulk upgrade everything on your machine. Right. And if that's how you want to do it, then that's how you can do it, right? Again, another happy middle ground on there, which I quite liked is if you say using something like brew bundle, like I mentioned before, then you can have brew bundle by default will upgrade all your packages. So if you have a project, say with your co-workers at work, right, say you are relying on MySQL and. and Rust and JavaScript being installed in this like particular project, right?

You can have a brew file in your repo route that has those packages in them. And then if someone runs it, then it will upgrade everything. And then, okay, you might have someone else on the team who's in an inconsistent state. But then they can just run the same command and they will get to the same state. So the state is based on time rather than based on a lock file, but you can still get some degree of consistency there. And also what you could do, which is what I tend to do in this situation. If you want to be like a step ahead, say people are not running upgrade relatively often or you have an onboarding floor or whatever and you don't want it to break, you can set up a GitHub action job with a macOS runner that just runs that every night. And then when it fails, it opens an issue or send someone in email or whatever.

And then you know, oh, like something in Homebrough got upgraded and now we need to go fix that. Right. And you can deal with that when you choose to rather than just like being like, oh, some particular developer ran a particular thing at a particular time. No, like, come on, people. We have ways of solving these types of problems with reproducible environments, which you can do with GitHub actions. Tadda, problem solved. It's a fantastic tool. I want to thank you for spending as much time as you do on getting it to work.

If people want to learn more, where's the best place for them to go? More about Homebrew, you can go to brew.sh, our lovely domain. If you are interested in the code or contributing, then that will also take you to the Homebrew GitHub repo, which tells you all about getting involved. If people want to see more about me and my ramblings on open source and other things, then they can go to my website at Mike McQuade.com, which links out to all my other internet presences. And we will, of course, put links to all of this in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thank you for having me, Gary. I delight. Mike McQuaid, project leader at homebrew. I'm cloud economist Corey Quinn, and this is screaming in the cloud.

Do you even join this podcast? Please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast episode, please leave a five-star review on your podcast platform of choice, along with an entitled whiny comment that we'll never see because that platform wound up having their entire stuff go down because someone ran a brew install without any idea of pinning or the fact that this is not how one should run production as a responsible grown-up.