|
|
|
|
|
by cjsuk
3247 days ago
|
|
Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect. If you get an uptake of say 5-10%, if that's worth it then problem solved. If it's not then don't bother adding telemetry to start with. But before you do this, you have to ask the question: how did the software industry get by before the sudden rise of telemetry? It engaged the customer. I think a lot of cases it is used it is used as a substitute for engaging the customer. |
|
If adding telemetry is faster and easier than engaging with the customer, then you'll see projects that add telemetry that wouldn't otherwise have the bandwidth to engage with the customer.
In general, I think the best way to go is to ask in the installer or initial setup, whether you want to send telemetry, and have a sane default according to whether you gather potentially personal information (location? personal, commands run (without args), not personal).
Example Prompt: Send telemetry (commands used, version) (y/n)[y]: