In my point of view, it is rather difficult to determine the usage of an add-on by its installations. Some people might install a bunch of it without ever using it, while others might forget to remove add-ons they do not need any more.
Tracking number of downloads for each addon is still better than nothing.
And it is not invasive to anyones privacy.
Oviously unmaintained addons should go.
it seems to me that the idea is to list installed addons with FireInfo (and therefore used), not the number of downloads reported by the mirrors.
So we would have an installation number for each addon (as we already have for IPFire release), and therefore the interest of the community in this addon.
Downloading an addon (by the mirrors) can only be a temporary test (which will be uninstalled later), therefore less relevant data.
IMVHO this data could help you to understand better which kind of use is done by IpFire adopters.
I don’t suggest to use IpFire as OneComputerBand distro due to lack of various things, but someone would be happy to create a megamix of DB Server, Backup Server, ApplicationServer, Swissknife server…
for security purposes, people should run as little services as possible on a firewall. Any
additional process and port opened up increases the attack surface. The more add-ons we
maintain, the greater their maintenance/development “costs” and the easier it will be for
users to configure their firewall in an insecure way.
So why don’t remove the addons?
If the maintenance/development burden is too heavy, maybe dropping the addons (at least for finalize IpFire 3) could release more energy for the main goal…
I wrote “understand better”, not “understand”.
Even if don’t agree with the development team on several things (and IMO is quite normal, there’s no “standard” person in the world, don’t matter what the statistics and the organizational models can say) I am not assuming that you (development team) don’t understand the adopters.
To revive the discussion ( or even bring it to an end it, if the topic isn’t interesting anymore):
The last days ( since release of core 152 ) brought up broad discussions about issues in samba.
I think this bound some development power.
Regarding this it would be, IMO, ‘nice’, to have some numbers about usage of this functionality ( SMB file/print server ). How urgent is it, to fix this?
Same arguments are true for other servers in the IPFire system ( for example the various media servers ).