Oh, hell no.
Transparent telemetry for open-source projects
61–70 of 314 posts
Re: Transparent telemetry for open-source projects
#62If there is any virtue to collecting telemetry, make it opt-in. Any developer convinced of this being useful will gladly enable it. But making it opt-out is just nefarious, because most users will not be aware of it.
Re: Transparent telemetry for open-source projects
#63Nope, nope, and more nope. You're not moving the Overton Window any more on me. In fact it seems there's a clear correlation between the quality of software and how much spyware there is embedded in it. It's often merely another way to justify unpopular changes with "but the data says so". IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision.
> IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision. Serious (general) question: How do you do that given a non-technical user population? Debian’s opt-in popcon kind of manages to get a little bit of data from a fairly technical one, but nowhere near enough to estimate a low usage frequency, and it’s the only opt-in program I’m aware of that gets anything usabl…
How many people are installing and using open source software but couldn't understand a pop-up explaining what data is collected and asking if they'd like to submit it? Is the non-technical nature of the user the problem or is it just that when you have an opt-in option most people make the choice to opt-out? That's the thing about respecting users by giving them choice, they get to say no. If they mostly say no, and you don't get enough data, that's the will of your users and therefore not really a problem.
Re: Transparent telemetry for open-source projects
#64I haven't worked with golang in some time. How do golang devs generally obtain the compiler? If you're getting it from distro repos, it should be straightforward to convince the distro package maintainer to disable the telemetry / patch it out. Or is it a nvm/pyenv/rustup situation where you prefer to use bespoke toolchain managers to download upstream's compilers?
I mainly get it straight from golang.org, but this will be able to be disabled via environment variable just like the modules proxy stuff was. https://research.swtch.com/telemetry-design#opt-out
Running the command in that just shows me a message of "go: unknown go command variable GOTELEMETRY"
Re: Transparent telemetry for open-source projects
#65Earlier quoted context omitted.
I mainly get it straight from golang.org, but this will be able to be disabled via environment variable just like the modules proxy stuff was. https://research.swtch.com/telemetry-design#opt-out
Running the command in that just shows me a message of "go: unknown go command variable GOTELEMETRY"
Because this proposal has not yet been implemented.
Re: Transparent telemetry for open-source projects
#66[deleted]
Re: Transparent telemetry for open-source projects
#67[deleted]
Re: Transparent telemetry for open-source projects
#68The information and rate of upload as described seem reasonable.
Is the fear from most people that it will be a foot in the door? And a way for Google to collect extra overtime?
Note: I think Go is a regressive technology. That would have been great in 1970s. Not today. But that's a different topic. My point is that I tend to be biased very negatively against Go. But here I don't see something wrong.
Re: Transparent telemetry for open-source projects
#69Probably related to[0].
To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually.
The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You don't really get any kind of sensible sample if you only do it opt-in. Additionally, this ship has long sailed, everybody does opt-out.
What I do think however, is that it should very clearly notify the user of this, and give them an easy way to disable it. Like in OctoSQL[1] (disclaimer: which I'm the author of) which prompts you on first run and shows explicitly how to disable it.
All things considered, this is an open source project, so you're free to maintain a fork without telemetry. The Go toolchain also uses the Google-hosted module proxy by default, which really is a bit like telemetry already.
Re: Transparent telemetry for open-source projects
#70On-by-default makes me question whether rsc's judgement has been compromised, which leads me to question continuing to use the language. A strange miss for him.
Off-by-default in a scale likely means that there is no telemetry at all. I would not cancel a guy or programming language based on just suggesting that. He has given a lot of though for that if you read the blog posts.