Package Management Learnings from Homebrew

31 January 2026

Homebrew 5.0.0 released in 2025. Walk through the major changes in 5.0.0, improving expectations based on other package managers and what they can learn from Homebrew's approach.

Presented at FOSDEM 2026.

Show transcript

0:00 I like to do people putting their hands in the air in the talks because it stops you
0:09 from falling asleep and it makes me more visibly aware that people are actually listening
0:15 to what I'm saying.
0:16 So put your hand in the air if you've ever used homebrew, okay, a reasonable number of
0:21 people.
0:22 Put your hand in the air if you ever contributed to homebrew, put your hand in the air if you
0:27 ever tried to contribute to homebrew and I closed your PR.
0:31 Sorry, sorry, yeah, so I'm, we've been, I've not been able to hear all the talks today.
0:41 I do follow, try as much as I can closely what's going on in package management world.
0:46 Shout out to Andrew's written a lot of very good comparative blog posts on this stuff this
0:50 year that I've enjoyed.
0:52 So I'm going to try and talk about today is like a bit more high level than I might say
0:55 with homebrew stuff about, okay, what have we been doing in homebrew now and why and
0:59 what can we maybe learn about it in other package managers.
1:02 So who am I?
1:03 Hello, I'm Mike McQuaid.
1:06 If you want to know about me now, my website is the best place.
1:09 It's all connected to social media and stuff.
1:11 I don't read anything on social media anymore.
1:13 So email me if you want me to actually see it or post on social media if you want to talk
1:16 shit about me behind my back and feel great about it.
1:19 My background, I guess, like how I've got into homebrew and stuff.
1:23 So I've worked in software for almost 20 years.
1:26 I've been working on homebrew for 17 years this year.
1:29 I'm the project leader, which is an elected sort of dictatorship sort of position thing.
1:35 So I'm a CTPO in my normal life, day job, whatever, and that sort of vaguely overlaps
1:40 with homebrew but not very directly.
1:42 So why should anyone care about homebrew, package managers, why I have to say?
1:49 I mean, who in here cares about package managers?
1:51 Okay, good.
1:52 I'm glad that someone does other than Andrew because otherwise he'll probably cry.
1:58 But I guess in my life, the thing that's great and terrible about homebrew is that it's somewhat
2:05 taken for granted.
2:06 Like a lot of package managers, it's just part of the infrastructure of how the internet works,
2:11 how I do my job, whatever, right?
2:13 So if you go and run, who's run Bruin still in the last week, say, okay, right?
2:18 Like you probably didn't really think very much about it, right?
2:22 Because you probably just ran something and then hopefully it worked.
2:25 But then when it doesn't work, then everyone gets upset.
2:29 Like most of the time, it only specific things are broken in specific ways for specific people.
2:35 But then when it's all broken for everyone, then everyone gets very concerned.
2:40 And the emotional reaction that people tend to have to when these tools break is heavy because
2:47 they're so reliant on these tools.
2:49 Like it's really important to them that it works.
2:52 And in some ways it's, if I can be a little bit philosophical, it scares people a little
2:57 bit when they are forced to actually think how many bits of the internet and tools that they
3:04 rely on by all these people at all these places all around the world that they are completely
3:09 unable to do their job unless all of these things connect together.
3:14 And often the people who are the most involved with open source are the people who are the
3:18 most forgiving when homebrew breaks.
3:20 And the people who are the most disconnected from open source are the people who are the
3:25 most angry and sometimes abusive when homebrew breaks.
3:28 It's a bit like your toilet, really, because when it's working, you probably don't spend a lot
3:35 of time deeply thinking about your toilet unless like me, you've recently been in Japan and
3:40 you're like, wow, their toilets are so much better here.
3:42 Why is my toilet like that?
3:44 But then when your toilet breaks, then we just get shit everywhere, right?
3:48 Like there's chaos.
3:50 No one knows what they're doing.
3:51 No one knows how to fix it.
3:52 No one really wants to stick their hands in there.
3:55 We have friends at the beginning of the talk.
3:57 We may be at the end.
4:00 So most people get very frustrated when their tools are slow.
4:03 Another one, bundler is slow.
4:05 Like everyone often complained about that for a good many years, right?
4:09 And then what gets done, people get frustrated.
4:12 So in, I feel like in many ecosystems, people get the same feedback about things being or
4:18 feeling slow.
4:19 They maybe don't even know why, but then sometimes the reason why it feels slow is because we get
4:23 new tools.
4:24 So cargo is often held up as an example of a package manager that like feels fast, right?
4:30 And I've not done huge amounts of rust stuff, so I'm not super familiar, but it's, you know,
4:35 that reputation for speed is something that's appreciated in the community.
4:39 It sort of founds the community's expectations of what these tools should be like, how they
4:44 should behave, how fast they should feel, how responsive they are.
4:47 In some ways, it kind of helps to buy into like, what does that language community care
4:52 about?
4:53 Like the rust community seems to care deeply about building lots of tools that are responsive
4:58 and fast, well-paralyzed and all these type of things.
5:01 You know, a lot of the tools that I, one of my favorite tools that's embedded just about
5:05 everywhere now is like RIP grep, which if you were like, how many people went down the path
5:11 of like, oh, AK and then the silver searcher and finding the perfect tool to search through
5:16 your code base increasingly quickly, right?
5:18 Yeah.
5:19 So if you went down that line, then you learned a few years ago, like a lot of these tools started
5:24 to be built in rust and there just became this little niche of people in the rust
5:28 ecosystem who really care deeply about just being like, I'm going to make the fastest version
5:32 of X or I'm going to make a really paralyzed version of some existing Unix tool that hasn't
5:36 really been updated in 20 or 30 years, right?
5:39 UV, obviously that's another example now, right?
5:42 Where that in the Python ecosystem is kind of reshaped expectations of what speed we should
5:48 be expecting from these tools.
5:49 What we can do and I think UV is an interesting example because I, again, I'm not super au fait,
5:55 so excuse me if I misspeak slightly on this, but my understanding is some of the reasons why
6:00 they've been able to be faster is because they've kind of dropped some support for legacy things,
6:05 which tools like PIP or whatever might still have to rely on, right?
6:08 And again, like, this is where things get a little bit more tricky and a bit more murky
6:13 for us as like package manager like developers.
6:16 It's like, okay, so what, to what extent do we prioritize speed or backwards compatibility
6:22 or following the leads of other tools or maybe we have multiple tools in the same ecosystem?
6:26 Who can say, right?
6:28 So Bundler, right?
6:29 Like, I feel like Bundler was a tool that 10 years ago I heard people complaining about how
6:34 slow it was all the time and then a lot of work went into it and then now it's a tool where,
6:38 you know, it's not the fastest thing in the world, but it's still like, it does not seem
6:42 to get that complaint levied against it nearly as often as it once did, right?
6:48 And I think Bundler is a nice example because they didn't throw out everything that they were
6:52 doing.
6:53 A lot of just time and effort went into it behind the scenes that meant that the tool ended
6:58 up just being fast.
6:59 You can add a few more things, then you'll have 10% that don't work, then 5% that don't
7:02 work.
7:03 And if you want to get 100% of packages working 100% all the time, you essentially have to
7:07 reimplement most of Homebrew and that's probably going to be a bit slower than you have right
7:11 now, right?
7:12 So I ask us all to be collectively both inspired but cautiously skeptical of some of these tools
7:19 that appear out of nowhere and say, "Hey, we've been able to do this 10x faster than anyone
7:23 else."
7:24 Because there's some stuff you can learn from that for sure.
7:26 Like, we have learned from that in Homebrew.
7:30 But there's also, it's very easy to make a prototype version of this which never quite
7:35 gets around to iterating into something that works reliably and can be used at scale.
7:40 Thank you.
7:41 Why do people do that?
7:43 In some ways, this reminds me, I don't know how many people ever saw the legendary Stack
7:51 Overflow answer that descends into madness about parsing HTML with regex.
7:55 Yeah.
7:56 It reminds me a bit of this, right?
7:58 Because it's like, you can parse HTML in a simple way with regex really quickly and easily.
8:03 And it's like, look how little code this took.
8:05 And it was really quick and efficient.
8:06 And like, I'm 90% of the way to solving this problem.
8:09 And then I just need to put a bit more time.
8:11 Oh, I'm almost there.
8:12 I'm almost there.
8:13 But then if you know essentially enough about the problem states, you know that like fundamentally,
8:17 you are trying to do something that is with most regex parses.
8:20 I know this pearl does some special things.
8:23 It's fundamentally impossible, right?
8:25 And it's a similar sort of vein here, right?
8:28 Where what they are trying to do is admirable, but they have taken a shortcut to do so that
8:34 makes the end result essentially fundamentally impossible.
8:37 So back to homebrew.
8:38 Like, so the big thing we did recently in the last year essentially was if you've used homebrew,
8:43 you've seen we do this kind of concurrent downloading stuff, right?
8:47 So in fact, the person who did much of the work, Marcus, is in the room with us right now.
8:52 Hats off to Marcus.
8:56 And we also have done some work on like a slimmer like internal API and stuff like that to try
9:01 and focus on this stuff with speed, right?
9:03 Ruby 4.0.1, like the time it takes to output hello world to a terminal is dramatically slower
9:09 than the time it takes back to do the same thing.
9:11 And okay, most people like someone literally with the homebrew performance stuff I posted
9:17 recently on social media, someone replied saying, in what world does homebrew's performance actually
9:22 matter to end users anyway?
9:23 Like, yes, this is a good point.
9:25 But we still get people whining when like their shell initialization takes 0.1 seconds longer
9:31 than it should have done or whatever, right?
9:33 And then porting stuff to bash makes things, you know, in our case, sometimes 100 times faster
9:38 than just by the time you spin up the Ruby interpreter, right?
9:40 So again, like it's a weird thing and it's very project specific and it's not general advice.
9:46 But again, for all of you working package managers, probably your three items are completely different.
9:52 And some naive person from the outside looking in will probably have ideas of why you're slow
9:56 and what needs to be fixed.
9:57 But you will know what these things are and you need to make sure you put these things in front of your team
10:01 and in front of contributors who might want to come in so that they actually know how they can improve this stuff in a meaningful fashion.
10:07 So as a result of that, like I think homebrew with the 5.0 release, like people are complaining about it less.
10:15 I think we've done a bit of a bundle of thing where homebrew is definitely not fast compared to its competitors,
10:19 but it certainly feels a bit faster than it was before.
10:22 And I think we have now room for understanding and improvement of how we can move forward.
10:28 Right.
10:29 So act two is let's think about like what we're doing in package manager land.
10:35 We talked about like user expectations, performance and things like that.
10:38 But I think another big part of software in general, right, like I've taken over as like a CTO relatively recently.
10:48 And one of my big things is like, how can I make things go faster?
10:51 And one way of making things go faster is performance and profiling and optimization.
10:55 And let's like do that.
10:57 Another way of making things go faster is thinking about what are we doing today?
11:01 And what are the things we can stop doing?
11:03 And if you can just do fewer things, you get this combinatorial explosion of once you have these different options and ways of building packages and their dependency trees and everything like that,
11:13 such that it became almost impossible to debug these issues in a meaningful way and support them and stuff like that.
11:18 Because again, we had limited CI infrastructure.
11:21 So we're not able to just go and say, okay, well, we're going to build everything in every combination every time for every dependency and figure out if that works.
11:28 So instead, we moved essentially to a model of like our binary packages where instead of going from Homebrew compiles a bunch of your machine,
11:35 it's Homebrew gets a tar bowl that's already been built somewhere else and extracts that, right?
11:39 So that was dramatically faster for users.
11:41 It was dramatically less error-prone for users.
11:43 But for power users, that resulted in us basically being like, hey, there's a bunch of stuff that you could do with Homebrew before that you now can't really do.
11:51 Or at least, to be more exact, if you want to do this, you need to go over there and do the work yourselves because we're not going to do that work for you.
11:58 Which, as far as a lot of open source users are concerned, is the same as saying this is now fundamentally impossible.
12:04 But the tricky thing with this is now we're in the situation where, because not everything's being built on individual user machines,
12:12 we need to figure out like, well, what are we going to support and what are we going to build and all that type of stuff.
12:17 So it started off with just like, okay, we build one package on one platform.
12:21 We pick a macOS version.
12:22 We build on x86-64.
12:24 Great.
12:25 Then eventually we add Linux support.
12:27 Then Apple came along with Apple Silicon.
12:30 And then we have to do ARM64 support.
12:32 And then we decided because we hate ourselves, we're going to do ARM64 support in Linux as well.
12:37 And then I'm sure at some point there'll be something else, right?
12:40 So like, yeah, exactly.
12:44 Risk will come.
12:45 I'm sure you can run homebrew on your toaster or whatever, right?
12:48 So if, hands up, any folks in here who support like software on multiple platforms or more platforms than they did 10 years ago, right?
12:56 It, it's a bit of a pain in the ass, right?
12:58 About what works for 90% of people most of the time, right?
13:01 And then that was their primary focus, right?
13:04 So in homebrew, we've tried to do the same thing, right?
13:07 We, we tried to focus on like, what do most of our users actually do?
13:11 And what that looks like is getting to a point where you realize, well, we're supporting a bit too much, right?
13:16 So we used to support, in theory at least, every macOS version.
13:20 And then a few years ago we decided we're going to support three.
13:22 We're going to support the current one and the two preceding ones, right?
13:25 This makes people upset sometimes because they're still using their old Mac and they feel like Apple's abandoned them and now we've abandoned them and this is really unfair.
13:33 But then even then, even with these three versions, what that looks like is, okay, well, does that mean we have to support all of this?
13:39 Or actually all of this?
13:40 Which just gets into madness, right?
13:42 Because every like line here, if you're going to support that, like we're saying we expect all of 10,000 packages that we claim that will work on these are going to work on these all the time.
13:54 And when it doesn't, it's a bug and we're going to fix it and it's going to break or whatever.
13:57 And then it's come back to the like, well, Humber is slow, right?
14:00 And maybe this isn't slow in terms of the behavior, but Humber is slow to fix bugs.
14:04 They're slow to merge our PRs because we have this matrix of issues that we have to deal with all of the time, right?
14:10 And what that means is you end up having to slim it down, right?
14:13 So we say, okay, well, we're not going to support everything all the time.
14:16 So we now don't build binary packages for the newest versions of macOS because we're like, well, A, we don't need to necessarily hyper optimize for that.
14:23 B, we probably get reasonable matrix coverage from the otherwise and C, like Apple are dropping this, right?
14:30 So on the 9th of September, sorry, on September 2026, we're going to stop building binary packages for Intel altogether, right?
14:38 On macOS, still on Linux because that's the majority architecture there.
14:42 But it's like, well, why are we doing this?
14:44 Could we indefinitely build this?
14:46 Sure we could, but it's going to make the project slower.
14:48 And we're at a point where Apple will have announced their plans to get off this.
14:53 So again, multi-billion dollar corporation, 30 volunteers, right, who receive a small stipend.
15:00 But we should not be holding ourselves to a higher standard than multi-billion dollar corporations, right?
15:05 On this particular, we have to fight harder and harder against that in order to have something that works for our users.
15:09 And eventually we get to a point where we're like, well, this is a security feature anyway.
15:12 No, no, we're not interested in doing this anymore, right?
15:16 So we, we used to just go, okay, we have these features and we turn them off.
15:19 And then now we have like with a major or minor release, we deprecate, then we disable, then we delete that code, right?
15:25 And again, that, if you don't already do something like this in your project and you have like a clear cadence, please, it's, it's so satisfying going and having all that code that causes your pain in the ass.
15:35 And knowing putting little markers and then be like in six months, I can just delete all of this mess and not have to think about this ever again.
15:44 Okay. Yes.
15:45 It breaks backwards compatibility, but then if only we like one day, I think someone will invent something.
15:51 Let's hypothetically call it a version control system where if they wanted an old version of some code, they could in fact go back in time.
15:59 I, it's a crazy idea, but I think one day it might pay off, but you know, people, again, it's this thing, it's entitlement.
16:07 We don't have to deal with that and we shouldn't have to deal with that, right?
16:10 Rust is a nice, good example of this, right?
16:13 Where they just state, okay, here's our platform support.
16:16 Here's what we have.
16:17 We have tier one, tier one targets can be thought of as guaranteed to work.
16:21 And in the spirit of open source, we almost directly stole this.
16:24 And we now have our own support tiers in homebrew where we say, here we have our tier one platforms.
16:29 These are what we expect to work.
16:31 Tier two is like, maybe this is going to work.
16:33 Tier three, it's probably going to be broken.
16:35 And then to homebrew sucking, we want you to know like, hey, we told you to do it this way.
16:43 You are doing it a different way.
16:46 Someone said you are sucking.
16:49 For those at the back, I will neither confirm nor deny that.
16:53 But yeah, but it's important, right?
16:55 If you can just write this stuff down, you will find people are a lot more likely to accept a thing which you put in a document or a section on your website.
17:03 Even if you repeat yourself verbatim in issue comments all day long, they will argue with you until the sun goes home.
17:09 But if you say, here's our support document, you can submit a PR with a proposal of why this should be changed.
17:14 They will never do that and they will stop arguing with you.
17:16 So, there we go.
17:18 You are as welcome, asshole.
17:20 Relatedly, we're going to enter the-- I thought I added disclaimer here, but I think it's maybe gone.
17:26 But no, in fact, no, it's coming.
17:28 Right, let's skip over that for a sec.
17:30 Right, so act three, sustainability stuff, right?
17:34 So what do we think is the most important thing in open source sustainability, right?
17:41 Money?
17:42 People, people.
17:43 Put your hand up if you think it's money.
17:47 The hecklers in the front are ruining this delightful setup.
17:51 Ironically, the hecklers in the front have given HomeRue quite a lot of money to do that.
17:55 HomeRue did without any money for many years and it worked fine.
18:02 Code?
18:03 Let's just fix all-- but we can fix human problems with code, right?
18:06 We just need to write enough.
18:07 No?
18:08 No?
18:09 No?
18:10 Okay, yeah, okay.
18:11 Like, yeah, we don't like-- yeah.
18:12 Humans, okay.
18:13 The humans, we are what matter, right?
18:16 Like, if you are a maintainer or an open source project, it doesn't matter how much money you
18:20 have.
18:21 It doesn't matter how much code you have.
18:22 It doesn't matter how many users you have.
18:23 If you decide and you're the sole maintainer that you're not going to work on this anymore,
18:27 this project is effectively dead, right?
18:29 Someone can fork in it and they can take it on and lead from where you left off.
18:33 Sometimes people do that.
18:35 A lot of the time they do not, right?
18:36 So, what this means is we need to take care of the humans, right?
18:40 If you're in a project where you've got multiple maintainers, take care of each other.
18:44 If it's just you, take care of yourself.
18:46 I apologize in advance.
18:47 There's a lot of self-promotion coming because I've written a bunch about this stuff.
18:51 It's a topic I care an awful lot about and I'm not going to reiterate all my own blog posts,
18:56 but I am just going to put them on the screen.
18:57 So, you can go and look them up if you're really that bored.
19:01 Right.
19:02 So, the first one.
19:03 I wrote this thing a while ago.
19:04 Ironically, before AI stuff, robot pedantry human empathy.
19:08 So, this idea of like what we should try and do in our projects is automate as much as we possibly
19:13 can, but also not automate the stuff that humans are actually good at.
19:17 Like, I remember I wrote this party in response to seeing projects that were like automating their
19:21 messages of being like, you have made a new PR.
19:24 Good job.
19:25 You are valued as a human.
19:27 And it's like, well, that doesn't really mean a lot to people.
19:31 Let's have the robots do as much as we can.
19:43 Get them to do, again, pre-AI.
19:45 This is me mainly talking about CI when I'm talking about this.
19:47 I love an AI.
19:48 I'm not going to get into AI today.
19:50 And that's, as humans, right, we can tell people like, good job.
19:54 Thank you.
19:55 You kicked ass.
19:56 I'm looking forward to seeing another PR from you because you did such a good job in this
19:59 stuff.
20:00 That really makes a difference.
20:01 There are people who contribute to open source for a long time just because of nice things
20:06 one or two people did, right?
20:07 There's a guy here at this conference most years, Cornelius Schumacher.
20:11 He was my mentor on Google Summer of Code 2006 when I worked in KDE.
20:15 I can say there's absolutely no way I would have done any work on homebrew were it not for him
20:19 being a really good Google Summer of Code mentor, right?
20:21 There's so many people throughout this entire conference, entire industry, who have stories
20:25 like that where this one person made a difference and put me on a trajectory, right?
20:29 That person could be you by just being nice, saying nice things, encouraging people, right?
20:35 And I know we have to deal with a lot of toxicity and it's hard.
20:38 You can get a thick skin.
20:40 I have a very thick skin.
20:41 But trying to free yourself out for those moments where you can connect with someone else
20:45 and be like, good job, well done.
20:47 It makes a big difference, right?
20:49 Next thing, contributor funnel, right?
20:52 All very brief TLDR of this.
20:55 Think about you have a nice funnel on your project, right?
20:58 A bit like a sales funnel of any of you know what that is.
21:00 But basically just this idea of like the people who use your project,
21:03 some small proportion of them will end up contributing to your project.
21:07 And then some small proportion of them will contribute enough that you want to make them maintainers, right?
21:11 But like if you can get that funnel to be as effective as transitioning between each stage,
21:17 that's going to be really good.
21:18 So one of the things Homebrew did really early on was some of the expectation that like,
21:21 this is not a project run by us for you.
21:24 This is a project run by all of us together, right?
21:27 Homebrew had no way of doing automatic version bumps or anything like that when it first created.
21:31 Max, the creator, was just like, right, I'm not going to appoint maintainers for every package.
21:35 I'm just going to say, if you notice this is outdated, submit a pull request to fix it, right?
21:39 That did a really good job of getting Homebrew a really, really decent number of contributors for the number of users we had.
21:45 And we have a tiny number of maintainers, relatively, we have like 30.
21:48 But still, that's way better than it was like 10 years ago.
21:51 Open source economics, again, just restating the stuff about like money, right?
21:56 Like money is not really what matters, right?
21:59 Money helps with some problems.
22:01 If you want to come to my RubyGems talk later today, you'll hear me talk about how money creates some other problems.
22:07 But what we want to use is the money to help the humans, right?
22:15 So we can help the humans do the right things.
22:17 Because ultimately, I think the scarcest resource in open source is maintainer, not even maintainer time, maintainer motivation, right?
22:24 And if you have a project where the environment and the users and the support structure and whatever makes you go, this fucking sucks, I don't want to do this anymore, then that project will die very soon.
22:35 Cool.
22:36 So, how do you do that?
22:39 Say no to things.
22:41 Say no to most things, most of the time, right?
22:43 Like chances are, unless you hear a feature request a bunch of times or you strongly disagree, you can say no.
22:49 That's fine.
22:50 You're allowed to do that.
22:51 Because ultimately, you owe no one anything.
22:54 Read the licenses of your software.
22:56 It says pretty much, and I'm not a lawyer, so please don't do this.
22:59 If I fuck up your shit on purpose, you still can't sue me because you agreed to the license.
23:04 Again, I'm not a lawyer.
23:05 Do not do this.
23:08 So, what do we talk about today?
23:11 Default to fast, right?
23:12 Like performance, people care about it, particularly when other tools are faster than yours.
23:17 It's not a bad idea to think about performance, even if you're just thinking about performance from the scope of what you do with support, right?
23:24 Having a support reality that you can publish, and you can use that to set expectations.
23:28 And then finally, optimize for the maintainers, because they are the people who keep your project alive.
23:32 So, one change is enough, right?
23:36 Just think about today, the projects you work on, what's something you could do to help one of these three things.
23:41 Make something faster, maybe clarify, even if it's one sentence in your readme, what you support and what you don't.
23:46 Or set a boundary for yourself or other maintainers for how you can better support yourself as a human.
23:52 Hands up, who's going to be one of these three things in the next month?
23:57 Some people put up their hand while saying no, which is confusing.
24:02 If you have questions, I don't know if we've got time for any now.
24:05 We don't.
24:06 But send me an email.
24:07 Go on my website.
24:08 You can find how to contact me.
24:09 And thank you very much for coming.
24:10 Thank you.
24:11 Thank you.
24:12 Thank you.

Mike McQuaid

Package Management Learnings from Homebrew