Homebrew: The Package Manager for macOS and Linux

The problem Homebrew solves on macOS and Linux

macOS ships with a limited set of built-in command-line tools, and installing additional software from source means resolving dependencies by hand, managing permissions, and rebuilding when system updates interfere. Homebrew fills that gap with a consistent command-line interface for discovering, installing, updating, and removing packages. The same tooling works on Linux, where it coexists with the distribution's native package manager rather than replacing it.

The project was originally created by Max Howell and is now governed by a Project Leader and a team of Lead Maintainers elected under the Homebrew Governance policy. Mike McQuaid currently holds the Project Leader role. Homebrew is a non-profit project run entirely by volunteers. Fiscal sponsorship is provided by the Open Source Collective, with infrastructure costs covered by donations and corporate sponsors including GitHub and SAP. CI infrastructure for macOS runs on MacStadium hardware.

Browsing the full catalog, checking dependencies, and viewing anonymized install statistics is available at formulae.brew.sh. The analytics endpoint at formulae.brew.sh/analytics shows aggregated install counts by package and operating system version, collected with a UUID rather than user identity. The collection is enabled by default and the policy is documented at docs.brew.sh/Analytics.

Formulae, casks, and the formulae.brew.sh catalog

Homebrew divides its catalog into two kinds of entries. Formulae are Ruby scripts that describe how to download, build, and install command-line tools. When you install a formula, Homebrew first checks for a pre-built binary called a bottle, which avoids a local compile step for most packages. If no bottle exists, or if the local system configuration differs from the bottle's build environment, Homebrew builds from source using the formula's instructions.

Casks extend the model to GUI applications. A cask definition specifies a download URL, a checksum, and an artifact stanza that tells Homebrew where to place the application bundle. Unlike formulae, casks do not build anything: they fetch, verify, and install the pre-built application. The distinction matters for auditing: formulae can be checked for correctness with the brew audit command, while casks are audited primarily for download URL integrity and metadata accuracy.

Both formulae and casks are browsable at formulae.brew.sh, which also exposes dependency graphs, available versions, and package metadata. The README directs contributors and users to formulae.brew.sh rather than manually inspecting the underlying tap repositories.

Post-install verification and first commands

The Homebrew project does not include the installation script in its README. The README directs readers to brew.sh for the current installation command, which varies by platform. After running the installer, two verification commands are worth running immediately.

The first fetches the latest formulae and cask definitions, then checks for common problems:

brew update
brew doctor

`brew update` pulls the latest formula definitions from Homebrew's taps. `brew doctor` scans the local installation for stale symlinks, permission issues, missing dependencies, and other conditions that would cause later installs to fail. It prints a report with suggested fixes. The troubleshooting documentation at docs.brew.sh covers the most frequent problems in detail.

With a clean doctor output, installing a package is straightforward. Homebrew resolves dependencies, downloads bottles or source as needed, and links the installed binary into PATH. The complete reference for all flags and subcommands is available in the man page:

man brew

The README also mentions brew bundle as a mechanism for managing sets of packages, with more documentation available at brew.sh. The brew bundle subcommand is not described in the README beyond that reference.

Where Homebrew falls short

Homebrew is a poor fit for workflows that require reproducible, version-locked environments. Each formula pins to a version at install time, but running brew upgrade later pulls the latest formula definition, which may change the installed version. There is no built-in mechanism to lock an entire environment to a specific set of package versions across multiple machines, which matters for CI pipelines or shared developer setups where consistency is required.

The project is run entirely by volunteers, so response times on bug reports and pull requests vary. Response times for security issues are documented in the security policy at github.com/Homebrew/.github/blob/HEAD/SECURITY.md, but general contribution reviews are subject to volunteer availability.

Anonymous analytics are enabled by default. Users who prefer not to send install data must explicitly opt out. The data includes install counts per package and operating system version but does not record user identity.

Finally, the README does not document the inline installation command. New users must visit brew.sh to find the current installer, which is an extra step compared to package managers that include the bootstrap command in the README itself.

Homebrew versus MacPorts

MacPorts is the main alternative to Homebrew on macOS. MacPorts is an older package management system that requires `sudo` for all operations because it installs packages into `/opt/local`, a system-owned directory. Homebrew, by contrast, installs into user-writable locations by default on Apple Silicon Macs, removing the need for elevated permissions during normal use.

This design difference makes Homebrew simpler to set up for personal development machines, while MacPorts is sometimes preferred by administrators who want stricter control over system paths or who are running packages not yet available in Homebrew's catalog. Both managers maintain large catalogs covering the most common developer tools. When a package is absent from one catalog, checking the other before building from source is a reasonable next step.

On Linux, Homebrew coexists with the distribution's native package manager rather than replacing it. The README acknowledges that the Homebrew catalog may overlap with native repositories, and the two can be used side by side.

Contributing formulae and running package audits

Developers who want to improve existing packages can follow the contribution path described in the README. The first step for working on formulae is tapping the core repository:

brew tap --force homebrew/core

Or for casks:

brew tap --force homebrew/cask

With the tap installed, a strict audit on a specific package shows which quality standards it does not yet meet:

brew audit --strict ffmpeg

Running `brew audit --strict` without a package name audits the entire tapped catalog. When no warnings remain for the target package, the workflow calls for submitting a pull request following the instructions at docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request. The README recommends starting with an existing package rather than adding a new one, since existing packages already have a review history that makes it easier to see what the project expects.

Governance, maintenance record, and licensing

Homebrew publishes releases on a regular schedule. The most recent releases at time of writing were 7.0.5 on 2026-09-21, 7.0.6 also on 2026-09-21, and 7.0.7 on 2026-09-28. The last push to the main branch landed on 2026-09-25. Release notes are published on the Homebrew Blog at brew.sh/blog/.

The governance structure is documented at docs.brew.sh/Homebrew-Governance. The Project Leader, currently Mike McQuaid, is elected by the Homebrew maintainer team. Lead Maintainers and other maintainers are listed in the README.

All code in the Homebrew repository is published under the BSD 2-clause Simplified License. Documentation is published under the Creative Commons Attribution 4.0 license. The two licenses cover different parts of the repository, so teams redistributing Homebrew as part of a larger product should verify which license applies to each file category before distribution.

Editorial conclusion

Homebrew suits individual developers on macOS or Linux who need a fast, low-friction way to install and manage CLI tools and GUI applications. Organizations that require reproducible, policy-controlled environments should investigate Nix or evaluate Workbrew, an enterprise layer listed among Homebrew's sponsors. Before adopting Homebrew in a team setting, review the anonymous analytics policy at docs.brew.sh/Analytics and decide whether to opt out. To verify the current state of a local installation, run brew update followed by brew doctor and address any warnings before proceeding.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes