Earlier quoted context omitted.
Well according to our telemetry 0% of users turn it off so it seems pretty popular. But more realistically what you gain in privacy you give up in having your voice heard by the devs. The decisions about the future of the product/project will be driven by the data, specifically the data from the kind of people who leave telemetry on.
If 0% of your users disable it, that kind of screams there's something wrong with your opt-out mechanism. Is it broken? Hidden? Difficult to do? I mean, with any group of people, there will always be a percentage that will disable it. If the telemetry is popular, that percentage might be very small, but it would be non-zero.
Transparent telemetry for open-source projects
51–60 of 314 posts
Re: Transparent telemetry for open-source projects
#52I 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?
Re: Transparent telemetry for open-source projects
#53Earlier quoted context omitted.
If 0% of your users disable it, that kind of screams there's something wrong with your opt-out mechanism. Is it broken? Hidden? Difficult to do? I mean, with any group of people, there will always be a percentage that will disable it. If the telemetry is popular, that percentage might be very small, but it would be non-zero.
I think you missed the joke.
Re: Transparent telemetry for open-source projects
#54Not only is it going to be opt-out (because of course it would be coming from Google), I really like the whole "wait a week before sending telemetry" part that just coincidentally has the benefit of sneaking right past people that actively look for suspicious network activity when they've freshly installed something.
Am I being uncharitable?
Re: Transparent telemetry for open-source projects
#55Re: Transparent telemetry for open-source projects
#56I 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?
Re: Transparent telemetry for open-source projects
#57Re: Transparent telemetry for open-source projects
#58Oh Google - never stop being you. Not only is it going to be opt-out (because of course it would be coming from Google), I really like the whole "wait a week before sending telemetry" part that just coincidentally has the benefit of sneaking right past people that actively look for suspicious network activity when they've freshly installed something. Am I being uncharitable?
Re: Transparent telemetry for open-source projects
#59Telemetry in open source exists for a long time. Debian has the popcon package that can be installed and reports weekly usage of the software packages. The telemetry data are published in the open. The Debian popcon FAQ could be used as guideline for other telemetry needs. https://popcon.debian.org/
Debian talks about what you, the user, can do: help out, participate and vote. If you choose to do so.
The Go team talks about what the developers and their software will do to the user's machine, but the user is completely passive in their description. This is also reflected in the term "telemetry" itself: the software is not a tool in the user's hands but rather a remote-controlled probe in the user's habitat that pokes at the user to elicit interesting responses.