The Homebrew maintainers who built a startup - Mike McQuaid and John Britton from Workbrew
Homebrew project lead Mike McQuaid and contributor John Britton explain how a pub-born package manager scaled through automation, why money alone cannot sustain open source, and how Workbrew sells the enterprise work volunteers should not have to absorb.
Mike McQuaid and John Britton are the cofounders of Workbrew. Mike is Homebrew’s project lead and longest-serving maintainer; John is a Homebrew contributor, and both previously worked at GitHub.
They trace Homebrew from Max Howell’s original design to a globally distributed project with tens of thousands of packages, then explain the deliberately separate company they have built for security, compliance and fleet-management needs.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did Homebrew begin?
In 2009, Max Howell complained about package management on the Mac in a London pub and somebody told him to build a better one. He first wrote down how users should interact with it, then implemented the code—a product-outside-in approach that prioritized usability. Mike discovered the early project after making his own MacPorts workaround, began contributing and eventually became its longest-serving maintainer.
Was Homebrew a case of “build it and they will come”?
It began as Max scratching his own itch, but growth was not passive. Homebrew embraced GitHub’s contribution model early and made the behavior it wanted exceptionally easy: install with one command, submit changes through pull requests and let a community share maintenance. Max’s reluctance to own every task became a design advantage because participation was part of the system from the start.
How did a small volunteer team scale such critical infrastructure?
The project continually reduces friction for users, contributors and maintainers, fixes repeated onboarding problems and automates as much manual work as possible. CI, linting and bots let roughly 30 maintainers support far more contributors and users than a manual process could. Sometimes scaling also means removing a beloved feature whose failure and support burden consumes too much of the team’s finite attention.
How has Apple worked with Homebrew?
Apple maintains contacts who can help the project and became especially involved during the Apple Silicon transition. It supplied developer hardware and helped place machines in data centers so packages could be built in CI before the transition. The collaboration also exposed a cultural mismatch: Apple had to distribute kits to volunteer maintainers across many countries because Homebrew has no office or conventional corporate structure.
Why is using open source not an obligation to fund it?
Mike argues that a permissive license intentionally lets companies use the software without payment; changing that bargain turns it into a proprietary product with a free tier. John’s corresponding rule is “don’t give what you’ll later have to take away.” Open source can maximize reach, but founders create conflict when they treat those users as a customer base they are entitled to convert later.
How can Workbrew build on Homebrew without capturing it?
Homebrew has independent governance, and Mike is elected project lead rather than owner. Workbrew cannot close or take over the community project. The model resembles GitHub building collaboration around Git or Tailscale building a managed experience around WireGuard: the open technology remains available to everyone while the company sells complementary coordination, administration and service.
What work belongs in the company rather than the open-source project?
Large organizations need security questionnaires, audit history, policy controls, fleet configuration and support for requirements that affect a tiny share of Homebrew’s users. Volunteers are neither motivated nor properly resourced to maintain that complexity. Workbrew can charge the companies that value it, keep the functionality reliable through daily customer use and contribute suitable improvements back without forcing enterprise priorities onto the wider community.
Why can’t money alone solve open-source sustainability?
A project may receive too much money for stickers but nowhere near enough dependable revenue for a salary. Cash does not automatically create maintainers, boundaries or a scalable support model. Sustainability is specific to each project: decide what is in scope, automate aggressively and refuse work the community cannot carry. A business is useful when it can promise a paid experience and employ people with the dedication that promise requires.
Who is Workbrew built for?
Developers get Homebrew and consistent local environments without giving up the ergonomics of their Macs. IT teams can deploy it across a fleet and see what is installed. Security teams gain vulnerability visibility, policies, compliance support and control over third-party taps. Basic deployment and visibility are free for unlimited users and devices; paid plans add security controls, remote management, automation and environment configuration.