Homebrew: The Missing Package Manager

The Tweet That Broke Tech Twitter

This is episode eleven of What Did I Just Install.

On June tenth, twenty fifteen, a developer named Max Howell posted twenty-nine words on Twitter that would become the most shared commentary on technical hiring in the history of the software industry. He had just been rejected from a job at Google, and the words were blunt.

Google: ninety percent of our engineers use the software you wrote, Homebrew, but you can't invert a binary tree on a whiteboard, so fuck off.

The tweet was retweeted tens of thousands of times. It was quoted in blog posts, conference talks, university lectures on hiring practices, and thinkpieces about what Silicon Valley actually values. It became shorthand for a specific kind of absurdity, the idea that a person could build one of the most widely used developer tools on earth and still fail a job interview because the interview measured the wrong things. The phrase "invert a binary tree" entered the lexicon of tech culture as a punchline, a symbol of everything broken about whiteboard interviews.

But the tweet was just the surface. Underneath it was a story about a chemist who taught himself to code, a package manager named after a hobbyist tradition, a brewing metaphor that went deeper than anyone realized, and the question of what happens when a tool used by millions of developers every day is built by one person who never got paid for it.

The Pain Before Brew

To understand what Homebrew solved, you need to understand what it was like to install Unix tools on a Mac before twenty-oh-nine. macOS is Unix underneath, a certified Unix operating system since Leopard, but Apple shipped it without the ecosystem of command-line tools that Linux and BSD users took for granted. No gcc out of the box until Xcode. No wget. No git. No Python three. No ffmpeg. Nothing beyond the bare minimum that Apple decided to include.

If you wanted those tools, you had two choices, and both were terrible. The first was MacPorts, which had been around since two thousand two under the name DarwinPorts. MacPorts worked like the BSD ports system. It compiled everything from source, installed it all into its own directory tree at slash opt slash local, and maintained its own universe parallel to the rest of your system. It was powerful and thorough, but it was slow. Installing something complex like ffmpeg meant waiting for every single dependency to compile, sometimes for hours. And if a build failed halfway through, you were on your own, reading compiler errors and hunting for missing headers.

The second option was Fink, which had arrived in two thousand, modeled on Debian's apt-get system. Fink used precompiled binary packages where available, which was faster, but it had a smaller package collection and its own quirks. Neither tool used the libraries that Apple already shipped with macOS. If your system had a perfectly good version of OpenSSL installed by Apple, MacPorts would ignore it and compile its own. This led to bizarre situations where you had three copies of the same library on your machine, Apple's version, MacPorts' version, and one you had accidentally compiled yourself at some point and forgotten about.

There was a third option, which was to compile everything yourself. Download the source tarball from the project's website, run configure, make, make install, and pray. Experienced Unix administrators could do this in their sleep. But Mac developers who had come up through the Cocoa and Objective-C world, people who built iPhone apps and Mac software using Xcode, found the whole process alien. They wanted something that felt like the Mac. Something that just worked.

The Chemist Who Coded

Max Howell studied chemistry at university, not computer science. His degree was in a discipline that had nothing to do with compilers, algorithms, or data structures. This fact would become famous a decade later when Google rejected him for failing to invert a binary tree, a task that sits in the first semester of most computer science curricula. Howell did not have that first semester. He was self-taught, a programmer who learned by building things rather than by studying theory.

Before Homebrew, Howell's most visible work was in music software. He created the Audioscrobbler application for Mac, a tool that tracked what music you were listening to and submitted it to a service that would eventually merge with Last.fm. If you used Last.fm in its early years, the scrobbling feature that logged your listening history and built recommendations from it, there is a good chance Howell's code was involved. He was a Mac developer at heart, someone who cared about elegant interfaces and user experience, working in the Apple ecosystem before it was fashionable.

He was living in London when the frustration with MacPorts reached its breaking point. The specific moment is not well documented, but the pattern is familiar to anyone who has ever rage-quit a tool and decided to build a better one. On May twenty-first, two thousand nine, Howell made the first commit to a new project. He called it Homebrew.

The design philosophy was everything MacPorts was not. Where MacPorts compiled everything from scratch and ignored the operating system, Homebrew used what Apple already provided. If macOS shipped with a working version of Ruby, Homebrew used that Ruby. If macOS had OpenSSL, Homebrew linked against it instead of building its own. This was not just a convenience. It was a statement about how a package manager should relate to its host system. Homebrew was not trying to replace macOS. It was trying to complete it.

Homebrew installs the stuff you need that Apple did not.

The tagline on the website was simple and cutting. "The missing package manager for macOS." Not a package manager. The missing one. As if Apple had accidentally left a hole in the operating system and Howell had simply filled it in.

The Brewing Metaphor

The name Homebrew was not random. In computing history, "homebrew" carries a specific resonance. The Homebrew Computer Club, founded in nineteen seventy-five with meetings in Mountain View, California, was the hobbyist group where Steve Wozniak first demonstrated the Apple I. The club's philosophy was that computing should be accessible, personal, and built by enthusiasts rather than corporations. The members swapped circuit boards and shared designs in a spirit of communal tinkering. Choosing the name Homebrew for a package manager was a declaration of allegiance to that tradition, software built by enthusiasts, for enthusiasts, in the garage rather than the boardroom.

But Howell took the metaphor further than the name. He built an entire vocabulary around brewing. Packages are called formulae, the recipes that describe how to build software. The directory where packages are installed is called the Cellar. Each version of a package sits in a Keg. Precompiled binary packages are called Bottles, because they have already been brewed and are ready to pour. Third-party package repositories are called Taps, like the taps on a beer keg. And graphical applications distributed as disk images are managed through a companion system called Cask.

The metaphor is not just decoration. It is a design philosophy expressed through language. A formula is a recipe, something human-readable that you can inspect and modify. Homebrew's formulae were written in Ruby, and they were deliberately simple. A basic formula was ten lines of code. You could read it, understand what it did, and modify it if you needed to. This was a direct contrast to MacPorts, whose Portfiles were functional but opaque, and to the binary packages of Fink, which you could not inspect at all. Howell wanted a system where the user could see the recipe and, if necessary, change it. Homebrewing, after all, is about making your own.

The Third Maintainer

Three to four months after Howell's first commit, a developer in London named Mike McQuaid discovered Homebrew and started contributing. McQuaid was the third person to become a maintainer, after Howell and a developer named Adam Vandenberg. He knew Howell from working in the same city, and the project's small size and clear philosophy appealed to him.

What happened next is a pattern this series has seen before. The creator moves on, and someone else keeps the lights on. Howell had built Homebrew to solve his own problem, and he continued to work on it intensely for the first few years. But by twenty twelve and twenty thirteen, his attention was shifting. He moved from London to the United States. He got a job at Apple, working on Swift Package Manager, Apple's own attempt at a package manager for the Swift programming language. The irony was not lost on anyone. The person who had built "the missing package manager for macOS" was now employed by the company that had left it missing in the first place.

I was the third maintainer involved in Homebrew after Max and Adam, and since Max stepped down, I have been in an informal leadership role.

McQuaid's involvement grew as Howell's waned. On December thirteenth, twenty thirteen, the Homebrew repository migrated from Howell's personal GitHub account to its own project account, a symbolic moment of the project outgrowing its creator. In twenty sixteen, McQuaid was given the formal title of lead maintainer, and in twenty nineteen, he became the elected Project Leader through a governance process that the growing team of contributors had established.

McQuaid spent fifteen years maintaining Homebrew. He did it while working full-time at other companies, most notably a decade at GitHub. He was not paid by Homebrew. The project had no formal funding mechanism beyond a Kickstarter campaign in twenty thirteen that raised just under fifteen thousand British pounds, mostly to fund Homebrew's continuous integration infrastructure. McQuaid maintained one of the most widely used developer tools in existence as a side project, fitting it around his day job.

The numbers tell the story of what he was maintaining. By twenty twenty-six, Homebrew had grown to nearly a thousand total contributors, several dozen active maintainers, and a formula catalog that covered almost everything a developer could need. Homebrew was, at various points in its history, the most contributed-to open source project on GitHub. McQuaid was shepherding all of it.

The Interview

The Google rejection happened in twenty fifteen, six years after Howell created Homebrew and several years after he had stepped back from active maintenance. By that point, Homebrew was already the dominant package manager on macOS. Google's own internal surveys reportedly showed that ninety percent of their engineers who used Macs had Homebrew installed. Howell walked into a company where nearly everyone used his software, and the company told him no.

The specific question was inverting a binary tree. In computer science terms, this means taking a tree data structure and swapping every left child with every right child, recursively, all the way down. It is a standard interview question, the kind of problem that appears in textbooks and on LeetCode, and the solution is four lines of code. But knowing the solution requires having studied it, or having the kind of formal computer science background that drills tree traversals into muscle memory. Howell, the self-taught chemist, did not have that muscle memory.

The debate that erupted after his tweet was not really about binary trees. It was about what engineering interviews are supposed to measure. The defenders of whiteboard coding argued that algorithmic thinking is a fundamental skill, that any serious programmer should be able to reason about data structures, and that Google's process was designed to find engineers who could solve novel problems under pressure. The critics argued that Howell's entire career was evidence of his ability to solve novel problems, that Homebrew itself was a more meaningful demonstration of engineering skill than any whiteboard exercise could ever be, and that the interview process was selecting for people who were good at interviews rather than people who were good at building software.

Our interview process is designed to evaluate candidates on a variety of technical and non-technical dimensions. We do not comment on individual cases.

Neither side was entirely wrong. Algorithmic thinking matters. So does the ability to design, build, and maintain a complex system used by millions of people. The tragedy was not that Google asked a hard question. It was that Google had no way to weigh "built Homebrew" against "cannot invert a binary tree" and decide which one mattered more. The interview process was a machine that could only see one kind of competence, and it was blind to the other.

Howell struggled at Apple too. He has spoken publicly about experiencing depression during his time there, about caring deeply about Swift Package Manager but not knowing how to navigate the corporate environment to make it great. The man who built Homebrew in his own image, fast, opinionated, simple, found himself inside a company where decisions moved through committees and layers of management. He left Apple and eventually moved to founding his own projects.

The Versions

Homebrew's version history is a map of how macOS itself changed over seventeen years. The early releases were rapid and informal, patches and improvements flowing through GitHub pull requests at a pace that made Homebrew one of the most active repositories on the platform. The first formal major version, Homebrew one point oh, arrived on September twenty-first, twenty sixteen, seven years after the first commit. Before that, there were no version numbers. The project simply existed as a rolling release, a continuously updated collection of formulae.

Version two arrived on February second, twenty nineteen, and it brought the most significant expansion in Homebrew's history. Linuxbrew, a fork that had adapted Homebrew to run on Linux systems, was merged back into the main project. Homebrew was no longer just a macOS tool. It could now install packages on Linux and the Windows Subsystem for Linux, which meant that developers who worked across operating systems could use the same package manager everywhere. The "missing package manager for macOS" had quietly become a package manager for everything.

Version three, released February fifth, twenty twenty-one, added official support for Apple Silicon. When Apple switched from Intel processors to their own ARM-based chips, every piece of software in the ecosystem had to adapt. Homebrew's challenge was enormous. Thousands of formulae had to be tested and updated for the new architecture. Some packages needed entirely new build configurations. The transition was handled smoothly enough that most users barely noticed, which is the highest compliment you can pay infrastructure software.

Version four arrived on February sixteenth, twenty twenty-three, and it quietly changed something fundamental about how Homebrew worked. Instead of cloning an entire Git repository of formulae to your machine, Homebrew switched to downloading package information as a JSON API response. This made brew update dramatically faster, especially on slow connections, and reduced the disk space footprint. It was the kind of change that most users never noticed but that represented years of engineering work underneath.

The Dependency Tree of Everything

Homebrew is not just a package manager. It is the package manager that installs other package managers. When a new Mac developer sets up their machine, the first thing they install is Homebrew. Then they use Homebrew to install everything else. Brew install node. Brew install python three. Brew install git. Brew install ffmpeg. Brew install ruby. Each of those tools brings its own ecosystem of packages, npm for Node, pip for Python, gem for Ruby, but Homebrew is the layer underneath all of them, the foundation that makes the foundation possible.

This creates a dependency tree that is philosophically different from anything else in this series. When we talked about left-pad, the dependency was a single function, eleven lines of code. When we talked about ffmpeg, the dependency was a multimedia library embedded in billions of devices. Homebrew's dependency tree is not deep. It is wide. It is the entry point for everything. The first domino that makes all the other dominoes possible.

On this machine, the one building the episode you are listening to, Homebrew installed ffmpeg, which this podcast uses to assemble audio segments into MP3 files. Homebrew installed Python, which runs the text-to-speech pipeline. Homebrew installed Git, which tracks every change to every episode. Homebrew installed Node, which builds the web frontends for other projects. Homebrew did not write any of these tools. It just made them accessible. And that act of making things accessible, of removing the friction between "I need this tool" and "I have this tool," turned out to be one of the most valuable things a piece of software can do.

Tea, Trees, and the Road After

Howell did not disappear after Google and Apple. In twenty twenty-two, he launched a new project called tea, positioning it as a successor to Homebrew. Tea was ambitious in a way that Homebrew had never been. It was not just a package manager. It was a decentralized protocol for software distribution that used blockchain technology and a token-based system to address the problem that had haunted Howell's career, the fact that open source maintainers never get paid. The idea was that the dependency graph itself could be used to distribute funding, that if a package was depended upon by thousands of other packages, the maintainer should receive compensation proportional to that importance.

The reaction was mixed. The developer community had grown deeply skeptical of anything involving blockchain and tokens, and tea's web three framing alienated many of the people who most respected Howell's earlier work. Whether tea will succeed where traditional open source funding has failed remains an open question. But the motivation behind it, the belief that the people who build the tools everyone depends on should not have to do it for free, is the same frustration that has run through every episode of this series. Howell built something used by millions. He was never paid for it. He tried to get a job at one of the companies that benefited most from his work, and they rejected him because he could not invert a binary tree on a whiteboard. That trajectory, from unpaid creator to rejected applicant to entrepreneur trying to fix the system, is a story about how the software industry treats the people who build its foundation.

Meanwhile, McQuaid made his own move. After fifteen years of maintaining Homebrew as a side project, he left GitHub and co-founded Workbrew, a company focused on enterprise Homebrew management. The idea was to take the tool that every developer used informally and build a business around helping companies manage their Homebrew installations at scale, tracking what was installed, ensuring compliance, managing updates across thousands of machines. It was an attempt to answer the same question from the other direction. If the open source project cannot sustain itself on donations and volunteer labor, maybe a company built around it can fund the maintenance.

I'm the CTO and co-founder of Workbrew, and I'm the project leader of Homebrew. The project leader with Homebrew is an elected position.

In May twenty twenty-four, Howell posted a reflection on the fifteenth anniversary of Homebrew's first commit. Fifteen years since that first push to GitHub. He wrote about dedicating himself full-time and unpaid to the project, about how he did not think it would exist if he had not done that, and about the personal cost.

Fifteen years ago, I made the first commit to Homebrew, never imagining it would become one of the most widely used open source projects of all time. I dedicated myself full-time, unpaid, and often underappreciated, to brew. I do not think it would exist if I had not.

The sentence "I do not think it would exist if I had not" carries a weight that only someone who has maintained open source software can fully feel. It is not bragging. It is the quiet recognition that a project's survival often depends on one person deciding, against all economic logic, to keep showing up.

The Machine Under Your Machine

On your machine right now, if you are a developer on macOS, Homebrew is almost certainly installed. It is sitting in slash opt slash homebrew on Apple Silicon or slash usr slash local on Intel, a directory tree full of symlinks and cellar paths and formula metadata. You probably do not think about it. You type brew install, the thing appears, and you move on with your day. But that frictionless experience is the product of seventeen years of accumulated work, thousands of contributors, and the stubbornness of two people in particular, one who built it and one who kept it running.

The last episode ended with the line "brew install put ffmpeg on the machine." That was not a metaphor. That is literally what happened. On this machine, at some point in the past, someone typed brew install ffmpeg, and Homebrew resolved the dependencies, downloaded the bottles, linked the binaries, and made ffmpeg available at the command line. Every episode of this podcast since then has been assembled by that ffmpeg installation. The text-to-speech engine produces audio segments, and ffmpeg stitches them together into the MP3 playing in your ears right now. Homebrew did not build ffmpeg. Fabrice Bellard did that, as we covered three episodes ago. But Homebrew made it possible to get ffmpeg onto the machine with two words and no friction. And that act, the removal of friction, turns out to be what Homebrew has always been about.

Max Howell could not invert a binary tree. He could build a tool used by millions of developers on every continent. Google measured the wrong thing. But the rest of the industry measured correctly, with their fingers, every time they typed brew install and got exactly what they needed.

If you are on macOS, open a terminal and try brew info on any formula you have installed. Pick something familiar, like git or python or ffmpeg. You will see the version, the dependencies, the size, and where the bottle was poured from. Now try brew deps dash dash tree firefox, or any large package you have. That is the dependency tree, the brewing metaphor made visible. Every keg in the cellar, every bottle that was poured so that one formula could work. And if you want to know how your installation is doing, type brew doctor. Howell built a package manager that diagnoses itself. The chemist who coded thought of everything.

That was episode eleven.