I am the maintainer of the GNOME Podcasts application. Recently I discovered that there is a snapcraft package of the application but its extremely outdated. I noticed cause I am receiving reviews in ODRS about things that were fixed 2 years ago. It’s so old that we have since changed version scheme.
Snapcraft distributes version 0.6.1 which I tagged on Sep 18, 2023. The latest version, which is available on Flathub on the same day, is 25.3 published on 17 October 2025.
Not only is the snapcraft version outdated, it is also using different appstream metadata than the ones we provide while keeping the Upstream naming. This is extremely disappointing and damaging to the brand of the application.
At no point we were contacted about the application being available nor do we want to have to deal with outdated versions we don’t support.
Additionally I it’s impossible that the “Star developer” that publishes it can meet acceptable quality and QA all the 45 they publish at the same time. No human can.
Out of the 45 applications, 2 of them are marked unofficial. Doing so for only some of them makes the rest of them look “official” which clearly is not the case. This is incredibly misleading.
Just to clarify, when I moved from GNOME to KDE I anticipated I might not be able to reliably test future updates, so I intentionally kept the snap pinned to the last confirmed-working release. The weekly user metrics show that this build continued to serve the majority of users consistently, with a stable user base throughout.
From the numbers, it even appears to have significantly more weekly users than the officially supported build, so despite the outdated state, it has been actively used and relied upon.
Thanks for the work and updating the application! Also thanks for adding the Unofficial label!
Could you also remove my email from the contact point, I suspect its listed as such due to the appstream metadata.
It’s unfortunate that you had to revert the application to the 25.2 release (a release from April). I am guessing this is due to some bug or dependency not existing in the ubuntu runtime.
Given that the whole point of snaps was having up to date applications despite the OS version, being stuck on an already 6 month old release is less than stellar.
There are 4k monthly downloads on Flathub, so the snapcraft statistics are similar. But also it doesn’t matter how many they are. I wonder how many more people would have installed the application from Flathub if it they were not navigated into a higher-ranking and outdated version by default.
I never asked for the application to be published there and I would much rather have less users, all on a up to date channel I can support, than more users and half of them thinking the application is broken, buggy and dead in general.
On the last point and it might need to be split into a separate topic.
I would like clarification from Canonical on the handling of the “Official/Unofficial” labels in Snapcraft.
Currently there are many applications that are maintained by a third-party, but only a tiny fraction of them is labelled “Unofficial” and that’s only after upstream developers explicitly asking for it in all cases.
Having “Unofficial” labels and builds its fine, but when its not applied to everything, one is lead to believe that everything not labelled as such is there for “Official”.
This is very misleading and annoying. Most developers I know don’t even know that their application exists in snapcraft, let alone the state of it. They also don’t really have any more time to spend in triaging random issues or coming here to ask for the application be branded properly.
Can a Canonical representative comment on this matter? If you want to keep third-party managed builds online at least mark them unofficial and fix their metadata and contact points.
While I do work at Canonical, I’m by no means a representative speaker and what I will write below is not an official company statement…
The only mark of “officialness” of packages in the store comes via publisher verification which you can see with the little check mark next to the publisher name in the terminal output:
ogra@styx:~$ snap info firefox
name: firefox
summary: Mozilla Firefox web browser
publisher: Mozilla✓
store-url: https://snapcraft.io/firefox
… and with a larger check mark on the website or in the snap-store app.
The name does not matter at all here …
If it comes to actual “official” package names an upstream owner always has a veto right and can file a dispute in the store to take over the name, you will need to go and register the name through the web UI or through snapcraft when using the command line, a notification will tell you the name is already taken and you are offered to file a dispute (if it is the official name of your app).
If it is simply the packaging of “some opensource app”, there is no rule that blocks anyone from doing it as long as it is legally sound (i.e. as long as the picked app license is permissive)
Whether or not someone takes your opensource app and packages under $name-foobar or $name-unofficial or even bundles it into a combined snap that has multiple apps is in the end up to the packager, if you do not want them to package it you can ask them, but AFAIK we have no rules to block this and count on you to sort this with the actual packager (which you are talking to above in this particular case as far as I see), here Canonical is simply an infrastructure provider …
I believe it is pretty futile for an open-source project to “prohibit” third-party binary distributions of their software (regardless it is distro packaging, AppImage, Flatpak, Snaps or others), the best you can do is to mitigate the harm from them via better communication including but limited to:
Documentation and issue templates
Requiring the downstream publisher to:
Specifically marking the distribution as UNOFFICIAL
Drop/replace upstream support contacts
Do whatever patching to the distribution so that the user will be forced to acknowledge that this is not an upstream-supported distribution (e.g. Inform users with custom dialogs )
I believe most (active) snap publishers will be willing to comply with these changes.
As a last resort, request the distribution platform(e.g. the Snap Store) to:
Mark the snap distribution as unlisted (to not appear in search results or recommendation).
Drop the distribution when the publisher cannot address the problem within a reasonable time-frame.
