> If people don't like it they can turn it off

If I, perchance, encounter software I use phoning home without my explicit permission it's done on my systems. Period.

That is fine, but in this case telemetry trades you (and other more hardline users) as a user for all the extra users you gain from instant crash reports, quick feedback, and generally better productivity.

I would never personally make that trade-off, and would always put (disableable) telemetry in my projects.

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.

See, I _am_ a dev. I run telemetry on my infrastructure, I analyse it and fix what's broken, and if necessary, try and get upstream fixed. Also, I'm not opposed to telemetry in general, but if a switch like this is turned on by default, trust is broken for good.

Software which does any type of computing without it's user's informed consent is classifiable as malware, mind you.

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.

Oh! That's what the whooshing sound over my head was!

Oh shit, I missed it as well.

Well, those that turned it off are not phoning home, so the rest will be 100% ;)

> telemetry is essential for a good product

Up until now, you've had to make these design decisions on your own, relying only on perplexing intangibilities like 'taste' and 'intuition'.

Those design decisions were never made in a vacuum. They relied on telemetry (or, less scarily, user testing, user feedback, user research, etc) to figure out what works best. As a reminder, our intuition doesn't come from nowhere, rather centuries of survival and expectations. If you do not know what these expectations are, and if you do not know how your users interact with your product based on these expectations, you cannot make a good product. Certainly, you can make a product that appeals only to you, but how many of yous exist?

The design of a teapot is a great one. It didn't magically appear with handles and a spout and a place to hold leaves, but after years of refining based on usage. As shocking as that is, tea wasn't even discovered on purpose, let alone having a specific vessel for it right out the gate.

So yes, telemetry is essential. Taste is personal.

I think it's somewhat silly to fly blind on the assumption that your taste is better than any real world observations you can make.

Especially if you haven't had the chance to develop an intuition yet and are new to the field. Without data to correct you, how do you get better?

> telemetry is essential for a good product

No, it isn't, and the idea that is is toxic.

Essential is probably not right, this is true.

But I'm confident I'll make a better product with telemetry vs without.

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.

Mandatory with an open license might shoot yourself in the foot when people fork your code.

For me, the harshest you can go is to have telemetry and not prompt for the setting on start with the user opted in by default. Ideally, you ask on first load, and that's what I'd probably aim for.

You can't ever try to force people to do anything in open source. They'll run right by you and make it do what they want it to do with or without you.

I'd even imagine paying customers are broadly more happy with telemetry than open source ones. And their needs more important anyways.

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

Just because Linux is open source doesn't mean you can't have both Fedora and Red Hat (an enterprise version built on the same codebase)

I don't think any closed source goes into Red Hat, it's just the patch delivery pipelines, package repositories, etc that require a license. And support of course.

Same with any distributed system whose core contributors could gain insight from telemetry. All the components are open source, but they can package it all up and make it available under different terms.

If there's a community version and an enterprise version, you can then make telemetry required in the community version. If people don't like it, they can pull the package apart and put it back together however they want, or they can pay for an enterprise license.

You can make submitting telemetrics a condition of some other agreement, such as copyright license on the Red Hat name, or a B2B support contract. That, however, is pretty far removed from what's discussed here; if the software license itself makes telemetrics "mandatory", then it's no longer an open license.

I don't think I made myself clear.

The company ships one product which is a community edition of a bundle of open source software. That version has telemetry enabled and can't be disabled. Users who want to patch the code manually can of course disable it, just like they can disable the Ad lens in Ubuntu if they want to build it themselves, and those users will be off the beaten path and likely to run into issues that aren't easy to find paved solutions for.

They also offer an enterprise edition with a support license, on which telemetry is enabled by default, but can also be disabled.

> bundle of open source software. That version has telemetry enabled and can't be disabled.

I'd recommend saying "and cannot be configured off without code changes", or something. Of course it can be disabled, if it's open source.

Go compiler without telemetrics opt-out would fragment the community even harder than Go compiler with telemetrics default on. While your scenario is, of course, possible, it's not very relevant to the Go compiler.

As for your original "might be a sustainable way to run an open source company", if the primary feature one gets buy paying is "easy to turn off telemetrics", that just doesn't sound like enough value.

Well I mean. In a lot of the popular Linux distributions you kind of get what the distro comes with.

Can you configure openSUSE to use apt instead of zypper? I mean, sure, probably, it's open source.

Is it going to be straightforward? I don't know. I suspect it's going to be harder than it's worth, and you might need to rebuild the operating system image to change the directory layout to work with apt's assumptions or something.

So in practice, even though these things are all open source, people who bundle complex software lay down the paths that 99.9% of people will take.

I wasn't proposing "disabling telemetry" as the primary business proposition.

Instead I was suggesting that open-source companies spend a lot of time dealing with issues from people who use the open-source software in unanticipated ways. If "the beaten path" for using the software without support includes telemetry, they get value from that.

If people want to use the software without telemetry, then they're paying for a support license, so the issues they run into which the supporting company has no telemetric insight into are at least better aligned with their support resource allocation.

Distros are roughly defined by their package managers. Replacing one is a huge amount of effort, compared to adding `false &&` to a single if.

My take is that distros are collections of opinions, some with exposed customization allowed.

The package manager is part of it, sure.

The filesystmem is another big part of it (though it's possible most are following XDG now https://specifications.freedesktop.org/basedir-spec/basedir-... )

Init system used to be a big point of deleniation, but I think systemd is the standard now (for better or worse)

The filesystem and networking stack still have some variability.

There's still default applications, kernel modules, a gui app installer, the desktop, included drivers, and many more things that go into a distro. If you go with a distro that uses KDE and you switch to GNOME for example, you might lose a lot of GUI support for customization, might have to build addon packages yourself, etc.

It's all open source at the end of the day, but that optionality leads to a less streamlined user experience and lack of guardrails as soon as you step off the beaten path, than you would get with something like OSX

To be more explicit: If your license does not let users patch out your telemetry code it is not an open source license at all.

From my response to your sibling:

I don't think I made myself clear.

The company ships one product which is a community edition of a bundle of open source software. That version has telemetry enabled and can't be disabled. Users who want to patch the code manually can of course disable it, just like they can disable the Ad lens in Ubuntu if they want to build it themselves, and those users will be off the beaten path and likely to run into issues that aren't easy to find paved solutions for.S

They also offer an enterprise edition with a support license, on which telemetry is enabled by default, but can also be disabled.

If you do, and if people find out about it, they'll send you false data.