This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users
My project is open source. That means I'm asking my users, explicitly or implicitly, to download the source code, download Go's tooling, and compile my code. That exposes them to Google's telemetry.
If you are building a library, then you are likely targeting Go developers who have already made their decision. If you are building a binary you can publish those and no one has to compile them
It's a CLI program with an associated library. That means anyone who wants to use it on a system I don't happen to publish binaries for, or who prefer to compile things from source rather than using pre-compiled binaries, or anyone who wants to use a commit I haven't published binaries for, or who uses a source package from their distro (Gentoo users, Arch users who use a source package from the AUR), anyone who wants to modify it to add a feature or fix a bug, all potential contributors, etc etc etc. would be exposed to Google's telemetry because of my decision to use Go.
And then there's everyone who wants to make use of the library and chooses whatever language makes that easier. I've certainly used Python for some projects just because a certain library is most easily used from Python.
I'm not sure if you're aware, but the official Go tooling is developed and managed by Google; the decision makers and core developers are Google employees. Go is deeply died to Google.
I'm not comfortable asking my users to send telemetry information to Google. The exact details aren't very important. People can make their own decisions about whether they're fine with it or not, but I'm not going to push people towards accepting it.
If that's the way you feel, then stop using Go. No need to make misleading statements because you have some gear to grind every time telemetry comes up
What have I said that's misleading? I don't want to expose my users to Google's telemetry, and that is affecting my choice of language; what part of that do you have a problem with?
There was a Nobel Prize in Economics awarded specifically for recognizing that things "disabled trivially" generally won't be, and this is a fully generic method of denying people their agency. See [0].
Opt-out, in most cases, is malicious, and you only think about introducing it when you're trying to make a change that leaves your users worse off.
That’s true, but there is another side to this same coin — people won’t do the right thing if it’s opt-in. Organ donation’s percentages are the two ends of the spectrum simply depending on opt-in/out.
I’m of course not comparing telemetry to organ donation, but I do feel that the problem is often overblown and is not that big of a deal. There is not much evil in trying to find out how many people used your toolings and from which OS approximately. (I dislike the Go language as much as it gets, so I am as unbiased as it gets)
You're right, of course, and your take is how "nudge theory", "trivial inconveniences" and low-key behavioral interventions are typically presented. I chose to use a phrasing biased towards the other end of the spectrum to highlight the "dark side" people often forgot about.
Now when I first learned about all this, I loved the organ donation and retirements plans examples - this all seemed like a brilliant hack to leverage human nature for greater good! However, my view on this flipped almost 180° over time. Two major reasons for this are:
1. Software industry. I actually deleted the long rant, because I have a specific, highly negative opinion of the business side of the industry - but we could debate that one all night, and it's not the main thing I want to say.
2. I actually brought the organ donation and retirement plan arguments up with family and friends, and was surprised by how much pushback I received in response. The specifics of each counter varied due to individual beliefs on those particular issues and politics in general, however the overall shape of the counterargument was always the same:
"I agree that having more people ${opting to donate organs, having a retirement plan} is good for everyone, and I understand there's a pool of people who don't make that choice simply because they never thought of it, don't care either way, or find opting in too difficult. Personally, ${I'm already signed up, I would consider signing up}.
However,
if they would do a trick like this to me, I would be angry. I have a right to be informed and make a choice on my own. This is denying me that choice, it's patronizing. If this was done to me, I would opt-out out of spite - in fact, just hearing now that people do this makes me want to not participate. After all, if it was all good-intentioned, they'd be up-front about it. Nudging with opt-outs smells like a scam."
Hell, a close family member said plainly to me that, hearing about this idea, they're now very skeptical about organ donation, and will no longer consider signing themselves up.
I tried to respond to people saying this. I tried to find a flaw in the overall spirit of their counter, tried to find a counter-counter of my own. But after many conversations, I instead found that I agree. On paper, opt-outs sound like super useful trick for doing good. In practice, they're predominantly used for bad, to exploit and abuse people. People know it, people feel it, and people also (even if irrationally) feel patronized by such attempts. As a result, even if you're 100% honest and well-intentioned with your opt-outs, whatever good you achieve this way comes at a cost of burning trust in the whole market/problem space.
The organ donation example now haunts me a little. Sure, signing people up by default may save lives in the short term - until enough people realize they haven't been given the respect and consideration that comes with decisions this big. Then those people will opt out, saying they've been used, and then others will follow, and then more people will die because of the bad reputation of the medical system wrt. organ donations.
I know it can be disabled. Whether an environment variable is "trivial" or not is certainly up for discussion. We're talking about, "never ever run the command on a system without the invonment variable set globally or in a context where the environment doesn't apply". (Did you know `sudo` strips most env vars? `sudo -u www-data go build` would send telemetry even if you added the env var to your profile)
It's trivial to disable telemetry for any given invocation, but making sure that no invocation at all, across decades, is far from trivial.
This is a valid forward-looking concern that I think needs to be much more clearly addressed. It's one thing to have default-enabled telemetry in the toolchain itself, but once that window is open it's going to be much more difficult to close it and stem the tide of telemetry features creeping in further elsewhere in the Golang ecosystem where they'd be much more of a privacy concern.
Without a strong commitment from the Golang maintainers that this is where it would stop (have they communicated anything to that effect?), we have no reason to believe it will stop here, and all the more reason to be concerned that this is just the beginning and it will be pushed much further in the future.
From the issue on GitHub, Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this
> To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by the Go compiler to all Go programs in the world: that’s clearly inappropriate.
> Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this
Erm, not quite....
Somebody explicitly asked (on one of the moderator hidden posts, I might add) "@rsc Can you guarantee that this will always be the case?"[1]
The answer was wishy-washy to put it politely:
"I can't guarantee we'll all still be here tomorrow. But for as long as Go exists and is developed, I expect that interested open source contributors like yourselves will notice and flag changes that move backward. That seems to me a more useful check on the future evolution of Go than anything I promise."
Saying "you'll have to notice and flag it" is not exactly reassuring. Especially given the way the Go team have been reacting to the "flagging" on the telemetry discussion itself !!
That's pretty common. It's what you say to your kid when they want to go to the amusement park this weekend, but you don't want to disappoint them right that second so you say something to push it off until you figure it out.
The telemetry is still only present in the toolchain. A library would be imported and built, and could trigger the telemetry collection, sure, but in what way would that be considered "part of their code".
If another developer is using their library, then it would ostensibly be a go developer who themselves has chosen to opt in or out of the telemetry, so they wouldn't be pushing it onto their users either.
If there are a wide variety of well-maintained libraries available in Go, people are more likely to pick Go, or even feel compelled to choose it, and possibly be subject to telemetry.
If the bulk of developers cease to create or maintain Go libraries, fewer people will use Go and be subject to its telemetry.
Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole?
One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random library.
And that still doesn't answer the question on how that possibly means telemetry gets injected into their code.
OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".
> but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain.
does not follow from this:
> One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".
An ecosystem becomes enticing due to a number of factors. Availability of libraries is one thing, but so is the language, tooling, and general popularity. Those are all interdependent as a thriving ecosystem will generally mean better tooling and more focus being put on the language development, which boosts the language's popularity.
A user is going to choose a language based on all these factors, and while a large number of libraries would be one of the factors in favor, telemetry would be one against. It's up to the developer choosing the language to weigh these factors, not the individual library developers. Nor does writing a library for a particular language "push telemetry onto their users" unless the library is actually pushing telemetry directly onto their users. The language or tooling doing it does not equate to the library itself doing it.
