Making Go telemetry opt-in is a mistake
twi.github.io
Making Go telemetry opt-in is a mistake
1–10 of 88 posts
Re: Making Go telemetry opt-in is a mistake
#2> For every kilobyte of Go code available on GitHub, GitLab, and other Git forges, there are unknowable megabytes of private Go code that will never see the light of day (or maybe they will if LAPSUS$ decides to make that company a target).
> Without knowing what ports of Go are used, the Go team can’t make sure that the right time is spent on maintaining those ports.
Am I being overly pragmatic if not selfish for thinking this is absolutely fine? If you use a free tool behind closed doors to make money and don't want to opt-in to telemetry, then I couldn't care less if the go team doesn't make go work better for your use case. Meanwhile I'm developing my open source project with telemetry turned on, ?????, PROFIT.
Re: Making Go telemetry opt-in is a mistake
#3 > Unfortunately, the proposal came from a Google employee. Google has a reputation of taking user data and feeding it into piles of linear algebra in order to skew its search results to match your existing biases or whatever the hell else people do with linear algebra.
If we lived in any other age, people might tolerate this, but we don't, and therefore everyone is well within their right to mutiny, regardless of how interesting a technical solution this is.
Re: Making Go telemetry opt-in is a mistake
#4They should simply allow for people to pick their default at installation. (so at download)
Even better if the go tool were to have a `go update` with a `telemetry-off` flag or something. (and possibly a prompt to remind people otherwise they will complain again)
Problem solved.
Re: Making Go telemetry opt-in is a mistake
#5Reminded of a post I saw the other day referencing Clausewitz to say "if your ideal military strategy is politically unachievable, it's not the ideal strategy". If going for opt-out telemetry makes your customers hate you and you're forced to retreat under a hail of fire, going opt-in is not a mistake.
There's also a philosophical problem in going too deep into "customers don't know what they want" and A/B testing everything to death: you end up using it as a substitute for dialogue. Ultimately customers are making conscious decisions. You have to make the case rather than assert that it's "better" from behind your metrics dashboard.
Re: Making Go telemetry opt-in is a mistake
#6> The problem of scrying into the unknowable
People really need to accept that they can't and shouldn't have full introspection into everything they're ever interested in. Even if it's a thing they care about (like their own homepage or programming language). Sure it's nice to get feedback. Sure it's nice to know that somebody uses it. But putting a tracker on everything with the argument of "will help me provide a better service", forgoing informed consent.. It's wrong when it's done on an institutional level, whether it's companies or the goverment, and it's wrong when individuals do that.
Re: Making Go telemetry opt-in is a mistake
#7> The problem of scrying into the unknowable People really need to accept that they can't and shouldn't have full introspection into everything they're ever interested in. Even if it's a thing they care about (like their own homepage or programming language). Sure it's nice to get feedback. Sure it's nice to know that somebody uses it. But putting a tracker on everything with the argument of "will help me provide a b…
The new owners of Audacity did this and then gaslit the community about it for weeks, despite constant, almost unanimous backlash.
Re: Making Go telemetry opt-in is a mistake
#8Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares.
The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.
Re: Making Go telemetry opt-in is a mistake
#9> For every kilobyte of Go code available on GitHub, GitLab, and other Git forges, there are unknowable megabytes of private Go code that will never see the light of day (or maybe they will if LAPSUS$ decides to make that company a target). > Without knowing what ports of Go are used, the Go team can’t make sure that the right time is spent on maintaining those ports. Am I being overly pragmatic if not selfish for th…
i.e. there are 10s-100s of millions publicly available LoC, but we really need to see your private workflow without your consent.
Re: Making Go telemetry opt-in is a mistake
#10Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch. That's how open source software is always supposed to work. Telemetry does nothing to improve this situation. If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop. Maybe focus on accepting PRs from people with ideas and strong enough motivation to work on them. I mean, there are 5000+ issues and 330 open PRs on the go github right now, so that should be plenty to keep them occupied. On top of that, how can literal thousands of issues not be a strong enough source of actionable usage information that they saw fit to try to get more? Do they plan on wrapping up all the open issues before looking at telemetry?