As in the post: they're intending to drop the GA part entirely within 90 days, and it sounds like the new metrics are entirely anonymous, and so not covered by GDPR etc. IANAL but as far as I can tell that should avoid all legal concerns once GA is gone.

It's hard to send stuff over the Internet without exposing some personal information, like your ip number.

I guess they might send it over TOR to get around that.

Isn’t it GDPR compliant if you never store the source ip at all? So from a GDPR perspective there’s no user data to track and remove.

I’m not sure how organizations get audited to prove that they actually do that and that there’s no other way to reidentify users (eg, I download the prepend package every day and that’s unusual enough to link that it’s me, prepend, the author of that package, etc etc).

This is exactly the use case that Oblivious HTTP is being built for in he IETF.

Why does a package manager need to track their users at all?

If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

> Why does a package manager need to track their users at all?

According to https://docs.brew.sh/Analytics they use it to measure how often formulas fail to install, to get overall metrics on which OS versions are used, and to correlate those (i.e. to tell on which OS versions specific packages fail to install correctly).

> A maintainer has no need to know who's installing what

Aside from the IP, they don't know who's installing what, and in the new model announced in this post they now don't store IPs or any other user token at all, so it should be purely anonymous aggregate metrics.

All stuff that should be in a trouble ticket from a whiney user. Which we know this type of user would be.

Edit-Also, this is for Mac OS. Chose a few standard OSes to support and test them. If a system update will fix the issue then it shouldn't be fixed at the package manager level.

Much rather deal with anonymized telemetry blowing up than tickets from whiney ass users.

Does anybody put a paywall in front of submitting tickets? Seems like homebrew could if anybody. Ie $10 to submit and might need more for a larger problem.

I agree that they don't need to know the "who", but it is perfectly understandable that they want to know "what" is being installed. And as part of the "what", they would want to know on which platform, and whether the install succeeded or failed, and probably a few other metrics about the install to ensure that things are working correctly and identify gaps that should be filled.

Based on what I read on the site, that looks like exactly what they are doing, and they are explicitly NOT storing information that would identify "who".

They can already gleen a lot of this since they run the hosted formula db anyway. A 90-day analytics capture isn't a big deal IMO.

Correct: there's no identifiable information being stored, either before or with these changes.

Aside from the IP? IP nowadays is all you need…

They've been quite clear about what they store and it's not IPs.

I think nowadays IP is less and less relevant when majority of people sit on dynamic IPs

Maybe they want to include the most common packages in their unit tests, or understand usage patterns so they can prioritize development?

It’s very hard to write and maintain good software without knowing how it’s used. No package manager needs to know how you specifically use it, but aggregate data and the ability to identify scenarios it does not handle well are both very important for SW lifecycle.

It's 2023. Hard drive space shouldn't be an issue. Test installing the full software suite, make it work, and you know the lesser installs will all work.

Do you think “hard drive space” is the constraining factor when building and testing over 6.5k third party packages?

Do you really not see any advantage to maintainers having visibility into what packages people actually use?

How much would you be willing to pay so that Homebrew can maintain a large amount of hardware covering nearly all configurations?

As a data point, they seem to be receiving about US$2k/month via Patreon:

https://www.patreon.com/homebrew

From rough memory (!), I think it was around the same when I looked ~12 months ago.

$2k/mo is a terribly low figure for a piece of software that nearly every dev on macOS uses.

That US$100k seems to have arrived over the last year, and their overheads - from quickly looking over their OpenCollective expenses tab - seem to be mostly buying hardware for CI things, and a monthly GSuite bill.

It's also pretty likely they get a lot of their resources for free / sponsored too.

So, US$2k/mo might be fine (no idea).

> Test installing the full software suite, make it work

Are you paying for the compute?

Assuming their claims of anonymity are true, they won't be tracking users at all.

I imagine they can get much richer metrics through this as opposed to only tracking downloads on the server side.

I'm not saying I like it. In fact, I plan to keep it disabled. I'm just saying it's a bit naïve to think client-side analytics are the same as server-side download tracking.

Richer how, exactly? I fundamentally don't 'get' what richness they actually need.

If anything they need money, of course, and to know their software works for their users. Prior to release have a test system install the full base, test those packages work, and you know anything less will work too.

I haven't looked at what they're actually collected, but here's a few things that come to mind:

- Time to install packages - Versions of things - Has the compilation (when required) failed? What dependency versions are installed? - CPU architecture - OS version ...

There's a lot more that can be sent from the client that's not available on the server side.

> I fundamentally don't 'get' what richness they actually need.

That's fine. Perhaps you could ask them instead of ranting about what you don't know or don't 'get' in a public forum?

> to know their software works for their users

Sounds like you're not very far from understanding why they want better telemetry.

> Prior to release (...) and you know anything less will work too.

Things break in unexpected ways. OSs are complex systems and there's a lot of interactions between components. Homebrew's user base is enormous and very diverse. There's 2 different architectures, many OS versions, lots of environment variables that might be set differently in each user's systems, different versions of libraries, ... I could go on but I think you get the picture.

Im okay with sending data to the server if things break and be asked each time to okay it. Is it safe to assume that if no errors or exceptions are encountered nothing should be sent back home?

How can they monitor failure rate if they only track failures though?

Why does it have to be a rate? Failures counts and failure types are good enough to extrapolate whatever else you need

They really aren't. If a package is downloaded 100k times and fails 1k times it's a very different issue than if it's downloaded 1k times and fails 1k times.

IMO installation failures are equally bad, no matter if they happen in 1% of cases or in 100%.

Well, you're wrong. If you have 10,000 packages and 1,000 of them are failing it's clearly useful to be able to prioritize which to fix first.

> Why does a package manager need to track their users at all?

Do any of you actually work in this industry shipping software products to end users? Without telemetry the problem there is literally one of trying to read the mind of your end users to figure out what they're doing, hoping that your internal CI manages to reflect the configuration in their environment.

I think HN has a very varied audience - some work in the industry, others want A/B testing to be made illegal on the grounds that it is non-consensual mind-control experimentation :P

The groups of people who work in the industry and those who believe A/B testing is psychological experimentation aren’t disjoint.

I am in both groups. I work in the industry and I am so tired of colleagues wanting to grab or data they can get their grubby hands on and then barely use it at all for anything useful. So many companies collect data just in case.

Any actual arguments?

I don't see why something that's little more than a file server needs telemetry.

I know people like you. Because you can't see any reasons, there must be no reasons.

Meanwhile "little more than a file server" shows you have no concept of the problem in the first place.

Yet you will go on beleiving you're smarter than the actual people who build the system.

Several phrases yet zero actual counter-arguments.

Everyone from 6 years old and above can swoop in and insult. Maybe you were lost on your way to Reddit?

How about calling it nothing more than a file server is also just a Reddit style insult.

If you think a package manager is nothing more than a file server, I'd suggest you learn more about what a package manger does or just go live in Reddit land with all of the other willfully ignorant types. It is not for us to convince you otherwise. It's such lame comparison that even searching for "file server vs package manager" doesn't even autofill because nobody searches for it because probably nobody would ever even sanely think to make the comparison.

> something that's little more than a file server

You're doing an awful disservice to Homebrew.

I am, yes, and sorry about it.

I don't like telemetry at all and I believe we have to find other ways to do QA. Hence my strong reaction.

Have you looked at the analytics yet? Or are you only speaking from ideological priors?

The most valuable one I’d guess is package install error rates. Seems pretty useful to me.

Homebrew is a package manager with thousands of packages, not a file server. We maintain those packages, and knowing when they break (or can be deprecated due to lack of use) is critical to the project's sustenance.

And with packages that compile.

Which the software that I used to be employed maintaining has actually broken homebrew compiles when they've been installed at the same time (which I think I made better but I never got the PM who actually owned the product to spend the resources to properly fix).

A good example of how the configuration in the end user environment can affect package installation.

Okay, fair enough. But the breakage can't be detected without telemetry then, I take it?

If so, that's... not ideal for sure.

Homebrew can detect a lot of things during normal maintenance work: there are extensive tests and checks during compilation and bottle building, for example.

However, we can't catch everything: Homebrew has millions of users, and those users have all kinds of different setups. We can't predict every possible host and software interaction; basic failure analytics help bridge the gap there.

Okay, I'm sold, and I'm sorry for being blunt.

Where can I learn more? Can you point me at the right place in the source?

I'll not be banning Homebrew telemetry.

I understand the desire for privacy, and the seriousness that comes with it!

I've linked Homebrew's analytics data and the source code that collects it elsewhere in this thread.

And, to be absolutely clear: it is perfectly fine for you to disable Homebrew's analytics. There are an infinite number of legitimate reasons for doing so, including the most basic one of "I just don't want to." My sole goal is to dispel the small number of inaccurate beliefs about what Homebrew collects, why we collect it, etc.

Thank you for engaging. <3

This industry has managed to ship software products without telemetry just fine - mass-collecting usage data from end users is only a relatively recent trend.

Users report issues to GitHub? It's not like Brew users aren't sophisticated in that sense.

In addition to being INCREDIABLY slow, now I have to worry about what it might spy on. If I have a problem I'm more than happy to go to GitHub (or which ever site it's hosted on), and report it.

I imagine many of us work shipping software to end users and also respect their right to privacy, and only track their actions with informed consent.

"Without telemetry, developers rely on bug reports and surveys to find out when their software isn’t working or how it is being used. Both of these techniques are too limited in their effectiveness."

https://research.swtch.com/telemetry-intro

> If you want usage statistics for packages just track how often individual packages are downloaded on the server side. A maintainer has no need to know who's installing what.

To be clear: Homebrew has no idea which users are installing what. We only store counters for package install, failure, etc. events, and everything that's stored is visible on the Homebrew website[1].

Homebrew's architecture doesn't really have a "server side" in the way your suggestion requires: the formulae and bottle components rely heavily on public services like GitHub Packages and GitHub Pages, which don't offer those kinds of analytics.

FD: Member of Homebrew.

[1]: https://formulae.brew.sh/analytics/

What kind of decisions do you make based on the analytics? Do you drop unpopular packages? To me, one of the advantages of a package manager is having a huge database of long-tail packages that are just one command away. If you kept only the popular packages you might as well just have an installer that installs them all together in bulk.

> Do you drop unpopular packages?

Yes: Homebrew deprecates and/or disables packages if we see evidence that they're unmaintained and not actually supported on the platforms we support, or only used by a tiny fraction of users while also requiring disproportionate maintainer time (e.g. due to complex or flaky builds).

The goal is to balance conflicting user interests: 99% of users want maintainer effort focused on the top 100 (or 500, or 1000) packages, and many of those packages also require significant maintainer effort (e.g. making sure that they don't cause transitive breakages).

So if a package has a small community of users and is well-maintained upstream but not popular overall you'll keep it around?

Generally speaking, yes: we don't remove things that aren't disproportionately burdensome. You can see that in the yearly analytics[1]: there are packages that only get a few dozen downloads a year, and we don't remove them because they don't cause any issues.

[1]: https://formulae.brew.sh/analytics/install/365d/

That's good to hear! I think small, well-maintained projects with loyal users can add tremendous value to a package ecosystem due to the long tail effect. I believe these long tail effects are a big part of the reason behind the staying power of tools like emacs, vim, and LaTeX.

I agree completely!

This discussion on GitHub reveals the mindset of the Homebrew people: https://github.com/Homebrew/brew/pull/6745

The Homebrew folks think this is a non-problem. You may agree or disagree, but the pull request is certainly a non-solution to this maybe-problem. Not just because it gained zero traction and did not get merged anywhere, but also because it's just an obscure band-aid. Either opt-out anonymous telemetry is a good idea, or it's a problem. If to you it's a problem, advocate for its removal in its entirety.

So even if I have an issue with telemetry, good on the Homebrew maintainers for ignoring this MR.

Never advocate for compromise?

We only have their pinky promise that the new analytics are anonymous. For all we know this might be a PR operation because people increasingly dislike Google, and they'll sell the "anonymous" analytics to Google under the table.

I'll make it a goal to stop all their tracking on the level of my router.

> We only have their pinky promise that the new analytics are anonymous.

Isn’t Homebrew open source? One could audit the source themselves. If you’re talking about what happens on the server side yes, but I don’t see the difference with any other computer I connect with over the internet.

[1] https://github.com/Homebrew/brew

Homebrew is not a custodian of any personally identifiable data.

Does that include IP addresses? Because I think that is considered PII

Homebrew does not store IP addresses, so yes.

You can see the totality of the information stored on the Homebrew website[1].

[1]: https://formulae.brew.sh/analytics/

From the post:

> Our self-hosted InfluxDB instance does not store either anonymised IP addresses or an anonymised user token so it has additional privacy benefits over Google Analytics.

Opt-in analytics are useless, unless a large part of your userbase just clicks through the entire wizard without thinking; there’s little overlap with Homebrew’s userbase

Ok, so don't do analytics.

Yes, hardware2win, have a worse product. Not everything needs to be phoning home all the time.

Then have worse product for the users?

Homebrew was fine before they started collecting analytics. There are plenty of great package managers outside the macOS ecosystem that don't use analytics.

So, just because you werent affected then no one was?

Yes, you don't get to decide to violate your users' rights and surveil them because you think it will improve your product.

1 it is their choice what soft they use, isnt it? Its not like chromium on android being pushed on you

2 there is "reasonable" / "good faith" data that in my opinion can be sent e.g crash log, stats like e.g package popularity etc.

You just create drama over nothing.

Ive used data like this to improve my soft countless times and there is nothing shady at all, everything is about what you collect.

Theres difference between keylogger or stealing nudes and tech data

> it is their choice what soft they use, isnt it

Yes. More evidence for an observation I've been having that ultimately the software is always about what the creator of the software wants, and not the user. I'm working on moving to running only my own software for that reason.

Not my problem. They don't have a right to spy on users.

Stop it. They are not spying on users.

Anytime "analytics" are opt-out instead of opt-in is spying in my book.

"The alternative is useless" is not a valid legal defense.