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