I’ve posted a variant of this answer on other threads about Homebrew, but to summarize:
1. Homebrew is entirely maintained by open source contributors. Keeping thousands of packages up to date is a significant task even before considering maintaining the packaging core itself, and analytics serve as both a warning system and hard data for package importance, instability, etc.
2. Homebrew is somewhat unique among package managers because of its relationship with the host OS: it has no say over how macOS behaves, and needs to adapt quickly to changes made unilaterally by Apple. Analytics help detect that kind of top-down breakage.
FD: Current member of Homebrew, former maintainer.
Homebrew is one of those tools that actually makes MacOS a decent Unix workstation for engineering (often, it feels like in spite of Apple). Without brew, MacOS would not be an OS I would even consider for my personal machines -- but I really enjoy MacOS now that it's on the M1/M2.
Although, admittedly, I use Nix-Darwin to manage my Homebrew apps.
Used to feel this way until I discovered MacPorts. So much faster than brew and prefer it placing everything in /opt and not relying on system binaries. Now I only use homebrew to manage Casks and a few esoteric binaries (really rare).
Thank you for your kind words! The maintainers deserve nearly all of the credit; these days, I mostly just do a bit of security automation stuff and defend their work when it comes up here :-)
Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. For example:
- If a formula is widely used and is failing often it will enable us to prioritise fixing that formula over others.
- Collecting the OS version allows us to decide which versions of macOS to prioritise for support and identify build failures that occur only on single versions.
What is a product? They make something that is used by others, and if they follow a product development mindset, calling it a product is fair in my opinion.
What if a product is finished and needs no further improvements? And even if it isn't, isn't it better to talk do your users and find out their pain points with your product directly, instead of trying to guess at them from analytics data?
The only improvement I personally want for Homebrew is for library packages to never include version numbers in the dynamic library file names.
> isn't it better to talk do your users and find out their pain points with your product directly, instead of trying to guess at them from analytics data?
you're trivializing a very big and complicated issue. why not both?
what is worse - anonymous usage statistics or needing to sign up with an email address to get notified of surveys and whatnot. one is passive, one is active.
it's also about more than just feature improvements... brew runs on a ton of different platforms/environments (https://formulae.brew.sh/analytics/os-version/30d/) and having this data helps prioritize the efforts of open source developers.
There is no meaningful sense in which Homebrew is (or ever will be) "finished": it's constantly being updated with new package versions, by both demand and design.
Analytics are an essential burden-reducing component of the Homebrew maintenance workflow; the maintainers would not have time to make improvements like the one you're requesting if they spent their time on the things that analytics do for them.
If you're a company with lots of money and you can pay employees to do so, then sure.
Homebrew is an open source project solving a fairly complex problem with volunteer maintainers. Analytics are constant and measurable signal on all sorts of things and can be used both proactively and reactively to deal with an array of concerns from user experience issues to bad rollouts.
1. Homebrew is entirely maintained by open source contributors. Keeping thousands of packages up to date is a significant task even before considering maintaining the packaging core itself, and analytics serve as both a warning system and hard data for package importance, instability, etc.
2. Homebrew is somewhat unique among package managers because of its relationship with the host OS: it has no say over how macOS behaves, and needs to adapt quickly to changes made unilaterally by Apple. Analytics help detect that kind of top-down breakage.
FD: Current member of Homebrew, former maintainer.