I see Sublime Text itself and Package Control special cases. As such, I don't think the rules that apply to other packages need be applied, therefore:
- Sublime opt-in
- Package Control opt-in
It's hard to restrict what a package can and cannot do, but Package Control can set rules about what packages it accepts to its default channel. Notice that this is not saying that a package cannot do x or y, but rather that if it wants to be included in the default channel then it must follow rules.
The policy I advocate for packages to be included in the channel is:
- No data collection in any way or shape whatsoever, opt-in, opt-out or otherwise.
There are several reasons to prefer a no tolerance policy:
- Instils confidence because it clearly defines the boundaries
- Too few a percentage of users will opt-in anyway
- Makes it easier for the community to handle issues as the arise because there will be more often than not no ambiguity about it. When there is grey area it takes forever to close out issues, and by then a lot of damage is already done.
- Anything other than a no tolerance policy creates high cost and a complicated mess of what is acceptable and what is not, how it should be implemented, how it should not. It becomes very subjective and then impacts point three because a user is far less likely to raise an issue if they don't know if it's acceptable or not. They may feel they're wasting their time reporting it because it's probably accepted data collection procedure, even though they themselves don't think it is, they may just uninstall it, but that doesn't help the community.
I think SE is an example of why anything other than a no tolerance policy fails. SE has been data collecting for more than five months. It's about weighting the costs of a complicated ambiguous ruleset vs it's not allowed fullstop.
On top of that, opening up the Package Control data to provide, for example, package authors with stats of their packages e.g. ST versioning, package versioning, dependencies installed versioning, etc. All the things that will make it redundant for a package to want to collect data to "improve the plugin support". Pretty much no package should need to be collecting data to know what OS's their package is installed on or what versions are installed, etc.