# homebrew/brew: a signpost README, an audit-first contribution path, and a container that refuses to pin

> The repository for the package manager everyone calls brew, written in Ruby and licensed BSD 2-clause. Its front page sends you to a website for instructions, its support flow starts with brew doctor, its first contribution is a lint fix, and its Linux image deliberately tracks whatever Ubuntu ships.

**Homebrew/brew** — 🍺 The Package Manager for Everywhere

- Repository: https://github.com/Homebrew/brew
- Website: https://brew.sh
- Stars: 49,775 · Forks: 11,367
- Language: Ruby
- License: BSD-2-Clause
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/homebrew-brew

## The README points at a website, because it is a signpost rather than a manual

The opening line of the front page is a redirect. It says to see the homepage at brew.sh for installation instructions, what Homebrew does, packages, brew bundle, and more, and the documentation section repeats the pattern by linking the installation page, the troubleshooting page, the contribution guide, and an FAQ, all hosted on docs.brew.sh. The manual itself is read with `man brew`. The repository does hold real substance, with a Library/ directory for the Ruby code, a bin/ directory, manpages/, completions/, and docs/, but the instructions to use any of it are not in the repository. The consequence is a small but real friction for anyone arriving from a search result: cloning this project does not tell you how to install it, and the README will not even try.

## Every support request is expected to begin with brew update and brew doctor

The help section is written as a procedure with a stated reason, and the reason is blunt. It says first to run `brew update` and then to run, and read, `brew doctor`, then to read the troubleshooting checklist, and it states in bold that not reading these will take far longer to help with the problem. Only after that does it point to GitHub Discussions or the new issue chooser, and even there the instruction is to follow and read the chooser rather than firing off a report. The consequence for a user is that the diagnostic step is not optional etiquette in this project, it is the entry condition, and a question arriving without doctor output has not met the project's stated terms. For a maintainer, that is the difference between a report that can be acted on and one that costs a round trip.

## The suggested first contribution is fixing an audit warning, not building a feature

The contribution section hands you a pipeline rather than a wishlist, and it starts by tapping the tap you want to work in:

```
brew tap --force homebrew/core
brew audit --strict ffmpeg
```

The steps after that are: run a strict audit on a package you already use, and if it comes back clean, run the strict audit across all packages and pick one to fix, then read the warnings and fix them until the strict audit for that package shows no results, and only then submit a pull request. The one place the process inverts is at the end, where it says that for a new feature or a bug fix you do not need to open an issue first, just open a pull request with your implementation. The consequence is a project with a low ceremonial floor for real work and a very high mechanical bar for anything touching a formula, since the audit output is the thing a reviewer will look at first.

## Package data and analytics live on a website, not in this repository

Everything about individual packages is hosted away from the code. Formulae, casks, dependencies, versions, and package metadata are found on formulae.brew.sh, alongside a page showing anonymised install, build, and operating system usage data, plus a separate page explaining how Homebrew uses anonymous analytics. The code for the packages themselves is not in this repository either, since the contribution section points at separate issue trackers for homebrew-core and homebrew-cask, two projects maintained alongside brew itself. The consequence is architectural and it reaches your scripts: if you are automating against Homebrew, the JSON interface behind that website is the contract you depend on, and this repository is the client of it rather than the store. A change to how a field is returned can break tooling without any commit here to point at.

## Two releases landed on the same afternoon, hours apart

The release history is a good illustration of how fast a package manager moves. Version 7.0.5 was published on 2026-09-21 at 14:32 and version 7.0.6 on the same day at 16:33, roughly two hours later, and version 7.0.7 followed on 2026-09-28, with the last push to main dated 2026-09-25. The consequence is mundane and worth stating anyway: if you installed during that window you may hold a build that was superseded the same afternoon, and a bug you report against it may already be fixed. The major version also belongs to Homebrew itself rather than to anything you install through it, so the number tells you about the tool's own generation and says nothing about the age of the packages in your prefix.

## The Linux image tracks whatever Ubuntu ships, and says so in a comment

The Dockerfile is candid about its trade-offs. It accepts a version argument defaulting to 24.04 and builds from an Ubuntu base, deletes the distribution's default user because that user conflicts with the linuxbrew user, and sets a deterministic first user id of 1000 with the stated reason that it helps the Docker build cache. Then there is the comment that matters most: the project does not want to manually pin versions and is happy to use whatever Ubuntu thinks is best, with a hadolint ignore added for the pinning warning so the choice is visible rather than accidental. Package installation is wrapped in a retry loop of five attempts with increasing sleeps, and the apt cache is mounted with sharing locked. The consequence is that the Linux build environment is deliberately not reproducible, so an audit fix validated today can fail next month because a base package moved underneath it.

## Volunteer run, named maintainers, and CI paid for by sponsors

The governance is unusually explicit for a project this size. It states that Homebrew is a non-profit run entirely by volunteers rather than employees, that funds go to software, hardware, and hosting around continuous integration, and that it is fiscally hosted by the Open Source Collective, with donations routed through GitHub Sponsors, Open Collective, or Patreon. Then it names the humans: Mike McQuaid as project leader, twelve lead maintainers, sixteen further maintainers, and Max Howell as the original creator. The infrastructure sponsors are listed too, with macOS continuous integration on MacStadium's Orka, password storage on 1Password for Teams, and DNS for the homepage with DNSimple. The consequence for a user is two-sided. You can see exactly who to reach, and you can also see that the testing infrastructure every formula merge depends on is donated rather than owned.

## Conclusion

Homebrew fits a developer on macOS or Linux who wants formulae and casks resolved from one command and who is willing to read brew doctor before asking for help. It does not fit someone who expects the repository to document itself, because the front page is a set of links, and it does not fit a build that needs a reproducible Linux environment, since the container tracks whatever Ubuntu ships. Before filing a question, run brew update and read brew doctor. Before adopting a formula, read the audit warnings rather than trusting that it installed cleanly.

## FAQ

### What is brew and Homebrew?

Homebrew describes itself as the package manager for everywhere, written in Ruby with its code under the BSD 2-clause Simplified License. The repository front page is a signpost that sends you to the homepage for installation instructions, packages, brew bundle, and more, and the manual is read with `man brew`.

### Does Homebrew still exist?

Yes. Releases 7.0.5 and 7.0.6 were both published on 2026-09-21, 7.0.7 followed on 2026-09-28, and the last push to main is dated 2026-09-25. The project describes itself as a non-profit run entirely by volunteers rather than employees.

### homebrew or brew

The repository does not discuss the naming question. The project is named Homebrew, the command is `brew`, and the documented way in is the manual page read with `man brew`, with installation instructions hosted on the homepage rather than in the repository.

### Is installing Homebrew illegal?

The repository makes no statement about legality. It does state that the code is under the BSD 2-clause Simplified License, that the documentation is under a Creative Commons Attribution license, and that Homebrew is a non-profit project run entirely by volunteers.

## Sources

- [Official documentation](https://brew.sh)
- [Official README](https://github.com/Homebrew/brew#readme)
- [Project repository](https://github.com/Homebrew/brew)
- [Release notes](https://github.com/Homebrew/brew/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/homebrew-brew