I get that AppImage is a self contained executable. Fine - makes sense to me. The others... I've got both installed on my Ubuntu 19.04 box and I really have no idea why I'd choose one over the other, or what the projects are trying to do that's so different from each other.
Sure, competition is good - but wouldn't pooling resources be better?
The first difference is centralization vs. decentralization. Snap is centralized, there's no way to make your private repos fully under your control. If you want private snap repo, you must talk to Canonical. From the user perspective, there's are no competing snap repos, only the Canonical one. They also support update pushing, so users will get updates whether they want them or not. This is a huge departure from the way apt/yum repos were managed.
This mirrors in the runtime support: snaps have centralized core16 / core18 runtimes or whatever Canonical comes with. Flatpak runtimes are decentralized and everyone can make one. You can use org.freedesktop.Platform, org.gnome.Platform, org.kde.Platform, maybe in future there will be org.centos.Platform or even something entirely different.
Flatpak focuses on desktop - their main method of app integration are .desktop files and dbus names. Snap allows arbitrary applications, including services or cli apps. This impacts the visibility from outside the sandbox: flatpak uses namespaces, so outside you won't get to see the private bind mounts that the containers use. With snap, your mount namespace is polluted with the squashfs mount points.
For sandboxing, Flatpak uses namespaces and secomp, with optional SELinux. Snap requires AppArmor, but packages with confinement: classic are not sandboxed at all.
Flatpak uses OSTree to store the app, framework or addon files. OSTree is often called git for binaries, it is content-addressable repository with checkouts and pulls. Snaps are squasfs images.
Things they have in common: both are sandboxed (except classic snaps), that's why the first launch is slower than unsandboxed applications. There are some things, that are being done, for example font caches are being created, that the unsandboxed apps do not have to do, because the host environment already has them. Both allows you to target a specific runtime/SDK, so there's no surprise for the app at install or runtime. Both have a permission system, that can control, how the app can interact with other apps or host, though the permissions currently defined may differ.
If you want to distribute manually your .snap packages, then you can certainly do so.
For example, the libreoffice snap is easily available for download at https://uappexplorer.com/snap/ubuntu/libreoffice The recipe to create the snap package is shown on the same page. You can recreate the snap package and then keep it for yourself. Or, upload it to your website and share with your friends.
After you download the .snap package, just click on it and it will prompt you to install it.
What you do not get with snaps, is the source code of the Ubuntu Store. Most likely, if someone is really interested to replicate the store, I believe it is easy to reverse-engineer, then create a reference implementation.
Snap, as an ecosystem, includes not only the .snap package, but also the remote side, equivalent to apt/yum. Even if you do not want the store equivalent, just plain old repo, you cannot do that with snap. You would have to replicate all the add repo/check for updates/install/update logic on the client side too - snap won't allow you to register your repo, even if you had your server side solved (side note: for apt, yum, flatpak, plain old httpd server is enough).
Therefore, when comparing with flatpak, which does allow remote-add/delete/info/ls/update, snap is centralized. The "you can code it yourself" is not an argument; you can code yourself equivalent to many other proprietary systems, and that does not make them open or less limited.
uApp Explorer is not affiliated with Canonical and does not host any apps. uApp Explorer only displays publicly available information about the official Ubuntu Touch appstore.
That said, they're both still package managers as far as I'm concerned and don't really offer any significant advantages over those over-engineered abominations.
Apart from that Flatpak is largely, but not exclusively, a Gnome effort while Snap is backed by Canonical and Ubuntu, though again not exclusively.
That's a statement of fact but usually in these discussions it's uttered as a value judgement. The ensuing discussion creates much more heat than light.
Both snaps and flatpaks require a core image (a rootfs), and each package sits on top of that rootfs.
For snaps, there is the core16 (and core18) images, which have quite a lot of shared libraries. Your snap package simply contains your program and any other extra libraries that are missing from the core image.
I personally don't care and a .tar.gz is good enough for me if it works (as an example I use Intellij from a tar.gz installer, is simple and it works)
Here is their initial announcement, https://blog.jetbrains.com/idea/2017/11/install-intellij-ide...
Here is the snap package page for Intellij Ultimate, https://snapcraft.io/intellij-idea-ultimate You can see the usage stats and also the list of other JetBrains packages.
A bit off topic, some advice, don't update your IDE during your work week, sometimes something won't work and you will waste time trying to fix it, I learned my lesson and I download the new version .tar.gz and start using it, if something goes wrong I can go back to the previous version and look into finding a fix later.
These cover the case for daemons quite extensively.
Welcome to Linux.