Telemetry

You're right. Opt-in results in a survey population that is self-selected, and therefore largely meaningless. But compulsory participation in surveys is deeply objectionable; just because it's easy doesn't make it OK.

So you can't have representative telemetry that is also optional (for the user). So firms should stop trying to use telemetry, unless they're OK with telemetry data from a narrow pool of users, e.g. users of Beta versions of software.

All software - including Linux and vim - makes some choices that benefit the developer over the user. Any choice of technology or software architecture with consideration of developer ergonomics is doing this. Every app that ever shipped with a runtime abstraction (classes, dependency injection, testable code patterns, debug logging, etc) chose to make the software fractionally worse for the user, to help the developers to actually write the software.

There is a meaningful and debatable tradeoff in all such decisions, and it's not clear cut. It is often (but not always) sensible for software to include extra code that, yes, must be maintained etc, which exists purely to make the development process of the software more effective. All extra code like this is strictly speaking a bad thing for users when considered in isolation, but overall improvements in development processes (better software, fewer bugs, quicker fixes) mean it's a net benefit for the user in the end, hopefully.

In this case, these developers genuinely do think the telemetry will help them build better software. You may not agree! That's an interesting point to explore, but their opinion is that the maintenance cost is worthwhile for the benefits that this information will provide. They think that the downsides of telemetry will be outweighed by the resulting significant improvements for people using the tool for its intended purpose.

They may well be totally wrong - there's an interesting balance there that is worth discussing, in terms of concrete benefits and real-world costs. Reducing all DX code to "literally no value" though is unhelpful and misses the real discussion.

“Opt in , by default” would seem to mean you have to opt in, unless some unnamed external condition was met, so normally you would have to choose to participate… which is the opposite of this case , where to NOT participate you must, by default, opt OUT. And if you do not you are automatically committed to participate.

This is essentially about checkboxes. “Enabled by default” would mean tracking is always on, but doesn’t tell you if it can be disabled by the user.

In the realm of privacy choices in software, we then started referring to these as “opt-in” (default off) or “opt-out” (default on) to communicate the default setting + the ability to change it.

Advertising trackers, for example, are mandated by law to be “opt-in” (they pre-select the checkbox for you of course, without submitting, but that’s a whole other story).

In that scenario, the default is to not play soccer. If you want to play, you have to choose it, i.e. opt to play soccer, i.e. "opt in". So the default is that you're "out". Thus, playing soccer is "opt-in".

If people were born into soccer matches and had to actively try to escape, that would be "opt-out". You make a choice (opt) to escape out of the soccer match.

Notice that "opt-in" and "opt-out" describe the inverse of the default value: "opt-in" is the same as "out by default" and "opt-out" the same as "in by default". Mixing these phrases with opposite meanings (e.g. "opt-in by default") creates confusion, perhaps intentionally, about what the default value is.