Locara

Homebrew

What it is: macOS / Linux package manager. Community-curated, Git-PR-driven. Formulae are Ruby files in a Git repo; new packages are accepted via PR review. Status: Dominant on macOS dev machines. Run by a small team of volunteers + sponsors. Most relevant to Locara: A model for community-curated distribution with strong quality bars. The PR-as-review model is interesting and surprisingly scalable.

Background

Homebrew launched in 2009 (Max Howell) as a friendlier macOS alternative to MacPorts. Its key insight: package definitions are just Ruby files in a Git repo, additions and updates are PRs, automation does most of the testing, humans approve. This turned package maintenance into the same workflow open-source contributors already understood.

Key design decisions

  • Formulae as Ruby files in homebrew-core Git repo. Each formula has URL, version, dependencies, install logic, test.
  • Tap system — community-maintained Git repos can be added as additional formula sources (brew tap user/repo).
  • Required metadata — homepage, license (DFSG-approved list), tests. Without these, PR rejected.
  • brew audit automated style/correctness checks.
  • BrewTestBot runs PR builds across architectures.
  • Bottles — pre-compiled binaries cached by SHA, fetched instead of building from source.
  • Autobump for routine version updates of upstream sources.
  • No formal approval team for homebrew-core — a rotating set of trusted maintainers + global automation.
  • API distribution since v4.0 (2023) — formulae served as JSON from formulae.brew.sh, regenerated from the repo.

What worked

  • PR-driven curation scales surprisingly well. Tens of thousands of formulae maintained by volunteer reviewers, mostly bot-assisted.
  • Quality bar is high — packages that don’t have homepages, licenses, or tests get rejected. Catalog quality stays good without heavy editorial.
  • Tap system as escape valve — users who want unsupported software make their own taps. Doesn’t pollute core.
  • Ruby DSL is approachable. Writing a formula is < 50 lines for most simple things.
  • Automated bottling removed compile-time-from-source friction for users.
  • Genuine community ownership — maintainers come and go, project keeps running.

What failed / criticisms

  • Telemetry controversy. Homebrew added Google Analytics by default in 2016, faced backlash, eventually moved off but trust took years to recover. Lesson: don’t phone home from package managers.
  • Slow on edge cases — niche software often gets stuck in PR limbo.
  • brew install --cask for Mac apps is a separate parallel system that’s grown organically and is sometimes inconsistent with formula UX.
  • No real security review. A malicious formula author could ship a backdoor; auditing is “do the build steps look reasonable?” not “is this binary safe?”
  • Updates can break workflows when upstream software changes incompatibly. Tap pinning is awkward.
  • Performance issues as catalog grew — Homebrew used to be slow; performance work has helped but it’s not snappy.

Specific learnings for Locara

  1. PR-as-review is a viable model for app submissions. Submit a Locara app = open a PR against locara-registry. CI runs tests, automated checks (manifest valid, capabilities consistent, signed binary), human-on-rotation approves. This scales further than imagined.
  2. Required metadata gates spam. Locara should require: homepage, license declaration, screenshots, capability manifest, test scaffold. Submissions missing these are auto-rejected.
  3. Bottles → signed binary cache. Don’t have devs upload binaries to a registry — have CI build from source on submission, sign, cache. Locara CDN serves only Locara-CI-built artifacts. Eliminates a class of supply-chain attacks where dev’s machine is compromised.
  4. Tap-style escape valve. Power users / orgs should be able to host their own Locara registries (taps) for private/internal apps. Locara client points at locara-core by default, but can add other sources.
  5. No telemetry by default. Homebrew’s mistake is the cautionary tale. Locara runtime should have zero network calls absent explicit user opt-in.
  6. Automated update bot for trivial bumps. If an app’s only change is a model version pin → new pin, automate the PR.
  7. Don’t conflate “package manager” with “app store.” Homebrew’s brew install --cask shows the awkwardness of using a CLI package manager UI for Mac apps. Locara is an app store; use app-store UX for it, not CLI-first.
  8. Volunteer maintainer model is real. With the right process, a small team can curate a large catalog. Plan for delegating review authority to trusted users by phase 4.

References