This conversation brings up another consideration… the graveyard of unmaintained snaps that could build up over time. It could also be interesting to come up with a process if a snap is to be decommissioned/unmaintained. Maybe marked a “depreciated” or outright deleted (maybe some cleanup process associated) for example.
Having a vast graveyard could lead to confusion for users over the long term is they are less experienced with Snaps in particular or Linux in general.
We’re aware there are some ‘orphaned’ and crusty snaps in the store. Some even owned by (current and ex) Canonical employees . We’ve recently implemented a system to ping mails to developers who haven’t updated their snaps for a while. But some will bounce, others will go unnoticed. It’s entirely possible there will be snaps which never get updated. That’s certainly not ideal. In some situations we (after contacting the original publisher) we could request a transfer to someone who is active.
This is partly a product of enthusiastic community / users who publish snaps and not the upstream owners of software. Partly it could be lack of interest, time or something else.
You’ll note that snaps in the store now have a date showing when they were last updated. This helps users to make a decision about whether to install software which may be outdated.
Perhaps the store will grow the ability to bubble up active snaps and push down snaps which are less active. Maybe we could have cobwebs appear on the bad snap web pages and shiny gold stars on the good ones
All good ideas. The only potential adverse side effect of bubbling active Snaps to the top is that the more active upstream projects would then get pushed to the top more often (in theory). Assuming this is a simple time sort vs some sort of actual algorithm to push as needed. It is a hard thing to solve (without putting too much thought into it yet).