It's also a sneaky strategy to deal with features you've decided to remove, because users are that fucking stupid.
1. Instead of just removing the feature, hide the feature and call it unsupported so the users who remember the feature can't complain yet.
2. Then finally remove the feature in the next update, with justification that it was an unsupported option and used by few people, so users can't complain.
Frog boiled. With each update the company seems to be acting rationally on "metrics" and principles, but the decision was set internally before that.
Of course, people who modify their settings in the first place are more likely to disable telemetry, particularly if they're choosing a non-default, low market-share application that specifically bills itself as privacy friendly.
If I recall correctly, that was their justification for no longer supporting it: too few people used it. Except it was tucked away in a small dropdown at the bottom of the customize toolbar screen, which requires right-clicking the toolbar to get to. If it was in the actual settings somewhere or, better yet, given as an option during the first launch flow, I imagine more people would've used it.
I didn't even know about it until after it became unsupported.
Usually when people call a feature bloat it’s because its presence, resource consumption, etc is too great relative to its value and utility to users or it’s not particularly relevant.
I’d hesitate to call something like optional compact UI metrics “bloat”. To me the term is better applied to e.g. features associated with only tangentially related services or something running in the background sucking up CPU cycles for little user benefit… basically the modern Microsoft playbook.
Code bloat is not that obscure of a thing. I think a decent portion of people realize that a program with features upon features is stretched too thin to meet users' needs in high quality, or in a timely fashion, especially if they paid $0 for it.
Don't get me wrong. When Firefox removes a feature, often it's not out the concern of bloat to be able to serve existing users better, but to shift resources for the next revamp that will make the browser ever more "modern", to claw for a new userbase.
All features require maintenance as code around them and through them changes with time. Feature bloat is very often code bloat and maintaining code costs money, especially 20 million lines of it. When a module owner sees an opportunity to improve their module by removing low-use features that are built on code that's a challenge to maintain, that's a good thing for the long term health of the code base and the features it provides and the app they make up.
1. Instead of just removing the feature, hide the feature and call it unsupported so the users who remember the feature can't complain yet.
2. Then finally remove the feature in the next update, with justification that it was an unsupported option and used by few people, so users can't complain.
Frog boiled. With each update the company seems to be acting rationally on "metrics" and principles, but the decision was set internally before that.