Making Go telemetry opt-in is a mistake

Here'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?

I think that the author has kind of a Stockholm syndrome.<p>&quot;Users are liars, so let&#x27;s spy them directly to know what we want to know&quot;.<p>It is mind blowing how, as an user&#x2F;the target, you can support that.<p>Nothing is really anonymous and your anonymous data can say a lot about you.<p>Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days. That kind of build pattern is there, so they are using the xxx crypto library...<p>And when they say, let&#x27;s trust Google, I would propose to Google to accept the opposite:<p>Now they will transmit to the public telemetry of their internal systems: how many users, what do they do, how many users they block, for what reason, how many build nodes they have, how many commits, how long the go team is spending looking at telemetry reports, which website are the more visited by Google employees,...<p>And let&#x27;s see if they will accept. It&#x27;s for the good of the world, why they would refuse?

&gt; 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).<p>&gt; 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.<p>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&#x27;t want to opt-in to telemetry, then I couldn&#x27;t care less if the go team doesn&#x27;t make go work better for your use case. Meanwhile I&#x27;m developing my open source project with telemetry turned on, ?????, PROFIT.

&gt; The problem of scrying into the unknowable<p>People really need to accept that they can&#x27;t and shouldn&#x27;t have full introspection into everything they&#x27;re ever interested in. Even if it&#x27;s a thing they care about (like their own homepage or programming language). Sure it&#x27;s nice to get feedback. Sure it&#x27;s nice to know that somebody uses it. But putting a tracker on everything with the argument of &quot;will help me provide a better service&quot;, forgoing informed consent.. It&#x27;s wrong when it&#x27;s done on an institutional level, whether it&#x27;s companies or the goverment, and it&#x27;s wrong when individuals do that.

<p><pre><code> &gt; 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. </code></pre> Right. We live in an age now where gigantic, powerful, organizations are ruining everything to privilege a fantastically small few. They have consistently shown a complete lack of any moral compass and a willingness to do absolutely anything necessary to increase their power or continue to enrich themselves.<p>If we lived in any other age, people might tolerate this, but we don&#x27;t, and therefore everyone is well within their right to mutiny, regardless of how interesting a technical solution this is.

Reminded of a post I saw the other day referencing Clausewitz to say &quot;if your ideal military strategy is politically unachievable, it&#x27;s not the ideal strategy&quot;. If going for opt-out telemetry makes your customers hate you and you&#x27;re forced to retreat under a hail of fire, going opt-in is not a mistake.<p>There&#x27;s also a philosophical problem in going too deep into &quot;customers don&#x27;t know what they want&quot; and A&#x2F;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&#x27;s &quot;better&quot; from behind your metrics dashboard.

Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares.<p>The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.

&gt; Unfortunately, the proposal came from a Google employee<p>Not really. People hate opt-out telemetry regardless of who runs it.

Good job Russ Cox. Despite initial concerns around this the right decision was made. Opt in is the morally correct choice for any software community. Notably I will opt into this where it is appropriate.

To be honest, the fact that Google is behind Go, is whats holding me back from getting into it. Same with React and FB. I dont really have any sympathy points left for them.

&gt; <i>Developers using macOS are used to just installing Xcode to make the error messages go away, so they just installed Xcode and assumed it was normal behavior.</i><p>So, they don’t test go in CI on clean Mac OS installs? If this sort of issue is the rationale for the telemetry system, it sounds like they’re trying for a older, slightly-less-evil Microsoft approach where you fire QA, and just treat user machines as your test environment.

Google: &quot;we don&#x27;t want to talk to people, or hear their opinions, so we&#x27;ll add telemetry to make decisions we want without including anyone else!&quot; Also Google: removed &quot;do no evil&quot; so they could... Do evil... Without sounding like hypocrites.

Mozilla shows time and time again that decisions based on opt-out telemetry are worse than decisions taken without telemetry at all.<p>&quot;Telemetry shows people aren&#x27;t using this (privacy &#x2F; internet freedom related) feature, so we can just remove it&quot;

There are vast amounts of Go code available in the wild to study. Open source is a thing.<p>If the Go team wants to see what features are used, go audit open source Go code.<p>Since Go is also a Google thing, they could likely audit the presumably large sums of Google Go.<p>Yes, you will miss unknowable amounts of code this way. Who cares?

If they want to add telemetry without asking the user, then they have to fix an entire industry including Google itself. They trained the people to hard disagree with such approaches, because in the past there was way too many incidents where data was unnecessary collected and misused.<p>Just trying to add this telemetry with opt-out in the first place shown one thing: They don&#x27;t know their audience. Because if they would, if someone would have come up with that idea, everybody in the team should have screamed: &quot;No, hell no!&quot;. You don&#x27;t have the trust of your users.<p>I get it, getting trust back is much more effort than collecting more data (even if it&#x27;s with good intent). But hey, the industry put itself into this.

They should simply allow for people to pick their default at installation. (so at download)<p>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)<p>Problem solved.

Yes, the data won&#x27;t be as good. But it will still be able to catch issues like that motivated this in the first place.<p>Knowing the goal allowed rsc to make this judgement.

Honestly, I think they should go with opt-in and make it clear to the community that the public dataset will be the sole source of decision making for future deprecations. If you want your favorite pet feature still enabled and no one using it is sending them telemetry then too bad.

As someone who was considering getting some Go and Rust under his belt, they&#x27;ve saved me a lot of time. This whole telemetry nonsense has ensured I won&#x27;t waste my time investing it in Go. Great job.

For me every kind of telemetry, data harvesting and so on should be opt-in.

Consent is always opt-in

All these situations I blame Google not Go, sometimes people are ignorant when to differentiate Google corporation itself and the Go team