I think Snapcraft has a problem going forward, where it’s doomed to become the app store of broken and old apps unless there’s some more effort on curation.
Whilst snaps can significantly prolong the length a single package revision can work, they won’t extend it infinitely. Network protocols are obsoleted, bases will be obsoleted, architectures might change overtime at both the software and hardware level. Effectively, every Snap if left un-maintained will break eventually, perhaps on the scale of months, years, or even decades, but eventually non the less.
This problem is worse given that a lot of snap packages use the package name scheme of $PROJECT-$USER ; whilst the policy of reserving key project names has some value, you end up with a significant amount of snaps that effectively replicate the same functionality, or package the same project, but with several different versions of them that all work slightly differently. A normal user will get confused on this, and question why there’s over 300 hello world applications on the store, or why there are several versions of their favourite app and none of them are getting updates. It reflects badly on the Snap Store, whereas contrasted to something like Flathub, Flathub enforces that they can rebuild any project they host, take over the maintenance of any package they host, and effectively prevents unnecessary duplication of effort and an excess of package choice. Single packages may go unmaintained at some point, but they will never end in a position where they couldn’t be picked back up in the future by any contributor with enough interest.
Adding a flag package option is a good improvement. A simple system that prompts someone to investigate if a package is still functional and notifies the package collaborators, potentially escalating to unlisting it from the store, fixes some of the concerns. It is however a pretty high effort solution, seeing as someone will have to do explicit testing, and some Snaps may be fairly obscure to test. It’s hard to decide what has value if you aren’t the one getting value from it, because the definitions of something being non-functional, or old to the point of providing poor value will vary dramatically from person to person. Overall I still think it’s worth considering.
I think alongside it, the Snap Store could consider an automated system of unlisting Snaps that appear inactive. Defining inactivity is a challenge, since some snaps may be fine for years without a rebuild. My feelings are the best method would be to email everyone who has submitted Snaps at a regular interval, say every 6-12 months; and ask them if they are still actively working on these packages or otherwise satisfied they are functional. If they respond positively by clicking a link, then nothing happens. If they respond negatively or not at all, the packages could be unlisted automatically. Unlisting doesn’t stop people from continuing to download them if they already know the package names of course, but it still increases the likelyhood people would going forward pick snaps that are being maintained.
I think in the future aliasing names, so that $PROJECT-$USER could be mapped back onto $PROJECT would help tremendously here too, so that any older instructions for unlisted packages, or links to the unlisted pages could be fixed. I understand that it’s a big ask as of right now, but on the scale of years and decades, this is almost certainly something that needs doing eventually.
Tl;Dr
I like the flagging idea, and I think the automated unlisting for inactivity alongside it would also be helpful.
