There's a lot of strong reactions here, which I don't think are generally unfounded. Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development.
For example, we had a CLI with many commands and flags, some of which were costly to maintain. By adding analytics, we were able to see that literally no one was using certain commands, and we could safely remove them without messing up workflows.
On each CLI invocation, we collected:
- hash of user ID
- which command is run
- which flags were included
- operating system (not version information, just mac/pc/linux)
This data wasn't used for marketing, had no identifiable information, and was diasablable (but opt-out). You could also log exactly what was sent to the server, so you could see.
We could have collected some of this via occasional surveys, but the data would have been less useful and less accurate.
I didn't look into the details of what Go is proposing to collect, but treating all telemetry of any kind as a boogeyman isn't productive; just have to do it the right way.
> Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development.
This perfectly exemplifies the whole problem. Google views Go as a product which Google is responsible for.
Go is a programming language. Go is critical infrastructure. Go is not a product. Viewing it as such is a fundamental misunderstanding of what Go is to its users.
This will practically implement my choice of programming language going forward. My question will no longer be, "is Go the right choice for this?", but rather, "is a Google product the right choice for this?". The answer is often yes to the former question, and no to the latter question.
I guess that begs the question - if Go was an independent project (totally unattached from google) and had the exact same telemetry plans, how would you feel?
Better, because most independent projects aren't the world's biggest advertising company whose business model entirely revolves around invading people's privacy as much as possible.
But that doesn't mean it would be good. The fundamental misunderstanding of Go's place as infrastructure rather than a product remains. And even though I acknowledge that spying on your users provides useful insight into their behavior, that doesn't mean spying on users is good.
For example, we had a CLI with many commands and flags, some of which were costly to maintain. By adding analytics, we were able to see that literally no one was using certain commands, and we could safely remove them without messing up workflows.
On each CLI invocation, we collected:
This data wasn't used for marketing, had no identifiable information, and was diasablable (but opt-out). You could also log exactly what was sent to the server, so you could see.We could have collected some of this via occasional surveys, but the data would have been less useful and less accurate.
I didn't look into the details of what Go is proposing to collect, but treating all telemetry of any kind as a boogeyman isn't productive; just have to do it the right way.