Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

Post reply on HN
Print view View original

221–230 of 314 posts

Re: Transparent telemetry for open-source projects

#221

Post by ergonaught »

nicce wrote: post #70
ergonaught wrote: post #55

On-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.

I would expect nothing less of him than to give a topic a great deal of thought and devise a principled and rational solution.

I am, however, reminded of a quote from Peter Drucker: “There is nothing quite so useless as doing with great efficiency something that should not be done at all.”

I’m not picking nits regarding the overall proposal. I’m questioning the judgement that concluded/rationalized “on by default” is the right thing to do.

Also not “cancelling” at the moment, either, but definitely reassessing my future language choices and taking a more critical appraisal of Go’s direction/choices. This isn’t really an isolated incident, and trust has accumulated some dents.

Re: Transparent telemetry for open-source projects

#222

Post by rcme »

gwillen wrote: post #200
Scaevolus wrote: post #194

Earlier quoted context omitted.

The proposal explicitly says they don't collect IP addresses or _any_ unique identifiers.

As far as I'm aware/recall, European privacy laws consider any connection back to a telemetry server to count as "collecting" IP addresses, since the telemetry server learns it (even if they pinky swear not to write it down.)

I think privacy laws only apply to things that “process” PII. Accepting a network connection is not, in and of itself, considered to process PII.

Re: Transparent telemetry for open-source projects

#224

Post by notpushkin »

bee_rider wrote: post #35

I don’t really see why a classic community-driven open source project would care about what non-contributing users are doing with the software. In that case, helpful users come with built-in telemetry (pull requests). But I guess this could be helpful corporatized read-only repo projects, or other groups that aren’t sure if they are building a community or a customer base.

Because pull requests aren't the only reason you might do a community-driven open source project. Perhaps you're just altruistic, or want to populatize some technology etc.

Re: Transparent telemetry for open-source projects

#225

Post by philosopher1234 »

masklinn wrote: post #158
cube2222 wrote: post #78

Earlier quoted context omitted.

All this boils down to "an unskilled engineer will misinterpret data even if they have it". I'll assume the Go team knows what they're doing, based on their track record so far. There's a lot of very simple questions you can answer very reliably, too, like "what proportion of the users are still using a certain compatibility flag".

> I'll assume the Go team knows what they're doing, based on their track record so far. Funny, I’d assume the exact opposite. After all much of the understanding of privacy and statistics at scale was developed after 1980.

Normally Hacker News is ruthless with stupid comments like this, but some sort of unexamined feelings of inadequacy make Go devs a fair target. I hate this attitude.

Re: Transparent telemetry for open-source projects

#226

Post by JetSpiegel »

Thaxll wrote: post #113
_ph_ wrote: post #102

Earlier quoted context omitted.

Still, opt-out is just inacceptable. At least with a mechanism which can easily fail, like setting an environment variable. This basically forces you to wrap the go tool in a script which ensures the environment variable to be set. As this seem to cache the results, another option is to fiddle with the cache to report bogus information.

You can set env variable for the go toolchain with a command such as: go env -w TELEMETRY=off which will be written to disk and use by the go cli.

What if a new version of go uses TELEMETRY_ENABLED? Do you read all the changelogs, always?

Re: Transparent telemetry for open-source projects

#227

Post by philosopher1234 »

wrldos wrote: post #176
BonoboIO wrote: post #175

Earlier quoted context omitted.

I think the comparison of telemetry and stealing is pretty harsh. Is opt-out telemetry unethical ... depends. If you use it in a privacy preserving way no, if you spy on your Users, sell the data for money or advertising obviously it is unethical. The hard truth is, nobody reads the manual. Opt in telemetry is often a minority, and you then work with niche data for a minority that influences your development in certa…

But is that not the decision of the person who owns the data?

The world is full of people making decisions for one another. Did you consent to unix files not flushing on every write() call? Its not a meaningful complaint.

Re: Transparent telemetry for open-source projects

#228

Post by JetSpiegel »

arp242 wrote: post #173
masklinn wrote: post #160

Earlier quoted context omitted.

> Telemetry has been around and matured and benefits users. Does it? Telemetry mostly seems used to justify removing features I need on grounds that they’re little used. As an other user noted, if telemetry is your yardstick, the average backup software removed the “restore” feature because that’s barely ever used.

There is a long list of use cases, which go far beyond "removing features": https://research.swtch.com/telemetry-uses "Is it safe to remove support for X?" is one use case. Right now the strategy more or less amounts to "remove and see if anyone complains, possibly too late to change".

> Is it safe to remove support for X?

What the hell, it's a freaking compiler. What do you mean, "too late to change"? Fail the compilation is suddenly a showstopper bug?

If go wants to deprecate features, just follow the same procedure done by literally all other non-spyware compilers.

Re: Transparent telemetry for open-source projects

#229

Post by yencabulator »

pcthrowaway wrote: post #33
bioemerl wrote: post #16

Honestly, this may be unpopular with hacker news, but just add your own telemetry. If people don't like it they can turn it off, and telemetry is essential for a good product. Do let people turn it off though please.

I think maybe even making telemetry mandatory with an open license, and customizable with a support license might be a sustainable way to run an open source company. For many open source project (anything with an attached business model), either telemetry or tight communication around usage patterns will be necessary to inform development. The latter of those two options consumes business resources.

> making telemetry mandatory with an open license

If it's mandatory to run the code that does telemetrics, it's not a very open license.

Re: Transparent telemetry for open-source projects

#230

Post by philosopher1234 »

JohnFen wrote: post #181
mananaysiempre wrote: post #170

Earlier quoted context omitted.

> I consider opt-out to be a manipulative approach. So do I, which is why I wrote I’m unwilling to implement it :) The original (and, to be clear, purely theoretical) point was, opt-out is too manipulative while opt-in is likely useless. Ah shoot. Did you take that to mean that I’m unwilling to implement an off switch at all? That wasn’t it, sorry for the confusion.

Perhaps we aren't so far apart after all. The struggle is real. As a developer, more data is obviously desirable and can make development much easier. I just can't think of a way to do telemetry that, if I were a user, I would accept. And I don't want to produce software that I wouldn't personally use. I just don't know how to have my cake and eat it too.

As a developer your entire purpose is to make decisions for users. "Where should this service live, how should security work, how should I increment their billed service usage, when should I shut down their vm..."

I don't think the issue here is making decisions for users and not giving them a choice. 99.999% of software does not have a flag to change it. The issue seems to be more about the precise nature of this specific feature.

Post reply on HN