Earlier quoted context omitted.
> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken…
As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former…
However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.
Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.
From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.
[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/