riot-web - Githubissues

ℹ This issue tracks the quality of the snap riot-web. If something in this list is outdated, please let us know by writing a comment below. If you're interested in helping out, please read the testing guide and the fixing guide.

Info

Checklist

Functionality

[x] Runs without crashing
[x] All functionality works
[ ] Works on Wayland
[ ] Is up-to-date

Ease of Use

[x] Starts quickly
[ ] Size comparable to regular package

Metadata

[ ] Title, summary, description and license are correct
[ ] Website and contact url are correct
[ ] Has screenshots
[ ] Store Icon is correct

Look and Feel

[x] Has a working desktop launcher with Icon
[x] Uses system themes (not applicable to most games)

If something in this list is outdated, please let us know by writing a comment below.

The Snap package is outdated (I realized this only now 😑), last version is 1.6.0 (officially released on 2020-05-05) and released on Snapcraft on 2020-05-11.

This is about the 5th Snap app I'm gonna remove from my system due to lack of maintenance. The state of the whole Snapcraft store is just wretched – lots and lots of unofficial, poorly maintained packages, the lack of proper metadata to assess the Snap's affiliation to the upstream project (or even tell who exactly is this entity that released the Snap) and not lastly the fact that even Snap's maintained by Snap devs (like this very Riot Snap) don't receive timely updates.

For everyone that wants to use an up-to-date Riot (actually Element in the meantime) Desktop app: Just use the official DEB package or the Flatpak which is maintained by the FlatHub community (they actually live up to the word maintenance).

Why does Canonical always have to stubbornly pursue their ego projects (Upstart, Mir, Unity, ...) to only realize years later that cooperation with the rest of the free software world would have been the better choice to begin with (which then leads to the usual decision to bury the solo action)?

After ~3 months of using Ubuntu 20.04 with a wide variety of DEB, Flatpak and Snap packages, I must draw the clear conclusion that the latter offers by far the poorest user experience. Of course not least because lots of free software devs don't wanna participate in and contribute to another Canonical silo project (whose server parts are propietary).

Thanks for letting us know about the issue!

I agree that there are a bunch of bad snap packages out there. The goal of this initiative (the snapcraft papercuts crew) is to get a community effort going to test and fix snaps. It hasn't started officially yet, but I'll do it as soon as possible.

Even with all the broken snaps, I really do like the snap store because there are so many good packages too. We really need to move away from this Windows mentality of "search the internet for an installer and run that". It's not secure and has a bad user experience. We really need an app store which contains all apps and includes secure confinement. The apt repository is great but it's not designed for apps that update too quickly, too slowly or are too messy.

One advantage of how everything works right now is that you're not stuck with the snap store. You can still use all the other installation methods if the snap doesn't work. However, when the snap does work, it's a much better user experience than searching the internet. It's annoying you have to try out multiple packages every time you want to install a new app, but that was the case before snaps too.

Lastly, if you go through the apt repositories in Ubuntu, you'll notice that it has many of the same issues: it contains many broken deb packages, especially when you search for less-popular apps. Some packages (like Arduino) are incredibly outdated etc.

Why does Canonical always have to stubbornly pursue their ego projects (Upstart, Mir, Unity, ...) to only realize years later that cooperation with the rest of the free software world would have been the better choice to begin with (which then leads to the usual decision to bury the solo action)?

What do you propose Canonical and the community use instead of Snaps? I'm not part of Canonical, I'm just a community member, but I use snap because it solves my issues. Flatpak is a great tool, but it's not a replacement for snap. Flatpak is built for app distribution, while Ubuntu contains much more software than apps. Even if Ubuntu switched to Flatpak, we would still need Snaps to distribute the printing stack, themes and the kernel, for example.

I also want to point out that Snaps exited before Flatpak was a thing. The Flatpak project was announced almost immediately after Snap officially launched their desktop app support. Moreover, Canonical is collaborating on Snap with a lot of people from Gnome, KDE, Manjaro, Solus, Google, Microsoft and many more. A bunch of those people work on both Snap and Flatpak, because it's useful to have competing products. Snaps and Flatpaks also share some underlying techology such as XDG Desktop Portals, and it shares a lot of infrastructure with container technologies etc. This is a collaborative effort, despite what some people might be claiming.

Note that this was the same for Upstart, for example. Upstart was actually adopted by many other distro's such as Fedora, Red Hat Enterprise Linux, Debian and OpenSUSE. Systemd was created later, and has been adopted in Ubuntu once it reached critical momentum. This is the way an open source company such as Canonical should work, in my opinion: build something to solve your problem, collaborate with those who want, and switch to something better when it comes along. Other technologies such as Mir and Unity have seen less adoption by other distributions but Canonical is far from the only one doing their own thing. Mate and Cinnamon were created at the same time as Unity, and for the same reason: many Linux developers did not like the direction of Gnome. We currently have at least four popular Wayland display servers, of which Mir is one. Wayland was specifically created to allow this, because the "monoculture" of Xorg has been an issue for a long time. Canonical is actually working on two of those display servers: Mir and Mutter.

Flathub has a lot less broken applications, but that is mostly due to a different focus: the snap store focuses on making it as easy as possible for anyone to publish applications. Flathub is focused on having a smaller selection of curated software. Flathub has a higher barrier of entry, and a much more centralized community of packagers, which results in less low-quality packages but less packages overall. I think it's good to try out both approaches, and the papercuts crew project will try to solve some of the issues with the "low barrier of entry" method.

If you find any issues with other packages, feel free to create an new issue in this repository. Just make sure to use the issue template and fill in as much info as you can find. We'll use this repository in order to figure out where the community should focus their effort on first.

The goal of this initiative (the snapcraft papercuts crew) is to get a community effort going to test and fix snaps.

Well I guess you'll be having a hard time building a community for a package management system that doesn't respect free software principles... :confused:

We really need to move away from this Windows mentality of "search the internet for an installer and run that". It's not secure and has a bad user experience. (...) Lastly, if you go through the apt repositories in Ubuntu, you'll notice that it has many of the same issues: it contains many broken deb packages, especially when you search for less-popular apps. Some packages (like Arduino) are incredibly outdated etc.

Ehm, yeah, that would apply to Windows users. On Ubuntu, the move to Snaps kinda has the opposite effect I fear: Unexperienced users search for and install an app from the Snapcraft store (which is even exposed when running unavailable cmds on the terminal) and then have to realize months later that the Snap package just was some one-time effort of some random guy on the internet that's not affiliated with the actual upstream software project. How could that be a good security design?

You're right about the default DEB sources of Ubuntu. But users are mostly aware of this and don't expect apps in universal to get updates. Instead they can search for and install DEB packages from PPA's or other DEB repos maintained by the respective upstream project.

And Flatpak, the main competitor to Snap in many regards, at least offers sensible identifiers for their packages (like org.videolan.VLC for the VLC media player), same as Android does, which allows users to easily tell if the package is an official one or not. On snapcraft, the names are assigned first-come-first-serve if I'm right and everything appears less transparent for an outsider. I also have better experience with getting timely updates with Flatpak packages than with Snaps.

Flathub has a lot less broken applications, but that is mostly due to a different focus: the snap store focuses on making it as easy as possible for anyone to publish applications. Flathub is focused on having a smaller selection of curated software. Flathub has a higher barrier of entry, and a much more centralized community of packagers, which results in less low-quality packages but less packages overall. I think it's good to try out both approaches, and the papercuts crew project will try to solve some of the issues with the "low barrier of entry" method.

Well, I'm not convinced of the Snapcraft approach. The "open for everyone to package" approach hasn't to be that terrible I guess but the lack to enforce properly structured metadata (visible to normal users) and transparency is. F-Droid (which is also pretty open I think) does a way better job in that regard IMHO.

One advantage of how everything works right now is that you're not stuck with the snap store. You can still use all the other installation methods if the snap doesn't work.

Yeah, I wouldn't use Ubuntu anymore if I couldn't do that! :grimacing: But as it seems, with Snap, regular updates are more of a pipe dream than than a real feature. When I always have to manually check if I still get updates for a specific Snap, it kinda renders the whole purpose of a package management system ad absurdum.

We really need an app store which contains all apps and includes secure confinement.

I fully agree.

What do you propose Canonical and the community use instead of Snaps?

I would propose to build upon/extend the Flatpak project to achieve the missing functionality. And if this is not possible, I would wish Canonical wouldn't pursue a lock-in model as it does right now with the Snap server/Snapcraft store being proprietary. It scares of other developers that care about free software principles, thus leading to less cooperation and knowledge sharing.

A bunch of those people work on both Snap and Flatpak, because it's useful to have competing products. Snaps and Flatpaks also share some underlying techology such as XDG Desktop Portals, and it shares a lot of infrastructure with container technologies etc. This is a collaborative effort, despite what some people might be claiming.

Ok, that at least doesn't sound so bad. But Ubuntu doesn't ship Flatpak support out-of-the-box which I think is sad and just a strategic business decision to push Snap.

Regarding collaboration in Snap world: Do you consider the criticism from the Linux Mint devs (in German; use DeepL to translate if necessary) to be FUD? @popey from Canonical did respond to this but didn't actually answer the issues Lefebvre raised. Addendum: Here's a concise summary of Linux Mint's reservations against Snap. Also worth a read is this blog post about disguising Chromium as an APT package being an act of "subversion".

Thank you for the rest of your substantiated remarks! I might have been a bit rash in condemning Canonical for pursuing/building their own infrastructure. But I strongly believe it should always be published under an open source license (ideally AGPL-3) and I really don't like the Snap server being proprietary.

If you find any issues with other packages, feel free to create an new issue in this repository. Just make sure to use the issue template and fill in as much info as you can find. We'll use this repository in order to figure out where the community should focus their effort on first.

Like any Snap? Or just Snaps released by snapcrafters?

edit: apologies; I seem to have edited your comment instead of writing my own, I think I fixed it now.

I'm happy to continue this conversation with you. Many of the issues you bring up are the exact issues I have. I'm trying to fix as many as I can because the potential of Snap is enormous and they have already made so much more software available than any of the previous attempts did.

This is our chance to solve the software distribution issues that have been plaguing Linux for decades. I personally much rather help achieve that goal than dismiss an attempt because it isn't perfect yet.

Well I guess you'll be having a hard time building a community for a package management system that doesn't respect free software principles... :confused:

You're right that the snap store back-end is not open source. I'd like it more if it was open source but this is less of an issue than some people claim. As an example, take a look at the massive communities built on GitHub and DockerHub, which are both completely closed source. At least the snap store fontend is open source. There will obviously be people who won't contribute because the snap store back-end is closed source, but Snap already has a large community and there is no indication that it will stop growing anytime soon.

It's also important to note that almost everything in the Snap ecosystem is open source. See the sources for the package manager, the most popular build tool, the build service and the Snap Store front-end. Only the snap store back-end is closed source. Canonical actually published an open source back-end a while ago, but there was no real interest from the community in actually using it, so the project stopped.

Part of the reason why I still contribute, even though the snap store back-end is closed source, is that this is a very small component. Ubuntu Touch, for example, is using click, a precursor of snaps, which was using the same store back-end. When the community picked up Ubuntu Touch, they were able to create their own back-end and now continue to benefit from click. We can do exactly the same with Snaps if/when that need arises.

Ehm, yeah, that would apply to Windows users. On Ubuntu, the move to Snaps kinda has the opposite effect I fear: Unexperienced users search for and install an app from the Snapcraft store (which is even exposed when running unavailable cmds on the terminal) and then have to realize months later that the Snap package just was some one-time effort of some random guy on the internet that's not affiliated with the actual upstream software project. How could that be a good security design?

The worst thing a bad snap can do is crash itself. The worst thing a bad ppa can do is make Ubuntu stop booting. The snap sandbox can't stop bad snaps from existing but it limits the reach of bad applications. Note that anyone can also create a ppa.

But you're right that we need an effort to adopt "abandoned" applications.

And Flatpak, the main competitor to Snap in many regards, at least offers sensible identifiers for their packages (like org.videolan.VLC for the VLC media player), same as Android does, which allows users to easily tell if the package is an official one or not. On snapcraft, the names are assigned first-come-first-serve if I'm right and everything appears less transparent for an outsider. I also have better experience with getting timely updates with Flatpak packages than with Snaps.

I personally do not think org.videolan.VLC is a sensible identifier. I think vlc is the actual sensible identifier, and this is what people expect. When you have a single snap store, there can only be one vlc and the snap store team solves name disputes based on what users will expect to install.

The names are not assigned first-come-first served. When a name is free, you can take it, but if it turns out you're not actually the rightful owner of the name, or the software you publish is not what most people would expect, then you will lose the name. The names for some popular and sensitive software like tor are even pre-reserved so that only the Tor project can claim it.

The KeepassXC project, for example, also publishes a snap for KeepassX (without the C), but they use the name keepassx-elopio. This is advised if you're not the rightful owner.

There is a lot of metadata in snaps that can help you trust the publisher more, but this information is currently hard to access.

Well, I'm not convinced of the Snapcraft approach. The "open for everyone to package" approach hasn't to be that terrible I guess but the lack to enforce properly structured metadata (visible to normal users) and transparency is. F-Droid (which is also pretty open I think) does a way better job in that regard IMHO.

I'm assuming you're talking about the build manifest? Snaps built on the open source build service contain extensive manifests which explain what repositories and sources were used, on which servers they were built and even where you can view the log files. These are not shown in the snap store but users can view them in /snap/<snap-name>/current/snap/manifest.yaml. I agree that these should be much more visible and work is ongoing to make them available in the Snap Store. Afaik, this situation is currently very similar to Flathub; the manifests and build logs are available, but it's not obvious how to get there from the store page.

Yeah, I wouldn't use Ubuntu anymore if I couldn't do that! 😬 But as it seems, with Snap, regular updates are more of a pipe dream than than a real feature. When I always have to manually check if I still get updates for a specific Snap, it kinda renders the whole purpose of a package management system ad absurdum.

Yes, a bunch of snaps are not well maintained, but it's a bit apocalyptic to say that this means the updates are not a useful feature? Is the giant debian repository useless because it contains many old and broken packages? No! Because it also contains many working updated packages.

I would propose to build upon/extend the Flatpak project to achieve the missing functionality.

I don't think it's feasible to extend Flatpak to be able to do everything Snap can do. Even if it was feasible, I don't think the Flatpak devs actually wants that, because it would remove a lot of the advantages of Flatpak. The fact that Flatpak only does app distribution and leaves everything else to the distro is a big advantage for adoption. I also genuinely think it's good to have both Snap and Flatpak. They can learn from each others' failures and successes, for example. What I have an issue with is that some people act as if there's two "gangs" and if you like one of them you have to hate the other. I think the projects should work together even more than they do now.

And if this is not possible, I would wish Canonical wouldn't pursue a lock-in model as it does right now with the Snap server/Snapcraft store being proprietary. It scares of other developers that care about free software principles, thus leading to less cooperation and knowledge sharing

I agree that the snap store backend should become open source. However, I want to make it very clear that Canonical is not pursuing lock-in. I'm in the process of writing a blogpost about this, but this is the gist of it:

Snap is designed so that every device only connects to a single store, but that doesn't mean there should only be one store in existence. Another distribution such as Linux Mint of Fedora could very well use Snap and point it at their own store. But those devices would not be able to access the Snap Store of Canonical. "Single store per device"; not "single store in the world". The reason for this is that Canonical already tried the "multiple stores" approach with apt and ppa's, and it gives a bad user experience. The Flatpak devs are now experiencing the same issue, which is why there is this big push to get as much apps as possible into Flathub, instead of each software developer hosting their own Flatpak repo. That said, Snap developers have said that the community is welcome to add "multiple stores" functionality into snapd, but they don't want to add it themselves.

Also note that Canonical published an open source back-end for people to host their own stores in the past but there was simply no interest in the community to run such a store, so the project died down.

Ok, that at least doesn't sound so bad. But Ubuntu doesn't ship Flatpak support out-of-the-box which I think is sad and just a strategic business decision to push Snap.

I think it's entirely in Canonical's right to push Snap more than Flatpak. Fedora also doesn't install apt by default. Flatpak in Ubuntu is maintained, users can easily install it, and the Ubuntu devs make sure this experience is good. The team creating the Ubuntu Yaru theme, for example, also publishes the theme on Flathub so that Flatpaks on Ubuntu are themed correctly.

This is very different from what Linux Mint does, for example. Linux Mint goes out of their way to make it as hard as possible for their users to install Snap. I think this is the kind of "political/strategic" moves that actually hurts the Linux desktop as a whole. I don't think there is anything wrong with carefully choosing the default installed software but you should not make it harder for users to install other software if they prefer.

Regarding collaboration in Snap world: Do you consider the criticism from the Linux Mint devs (in German; use DeepL to translate if necessary) to be FUD? @popey from Canonical did respond to this but didn't actually answer the issues Lefebvre raised. Addendum: Here's a concise summary of Linux Mint's reservations against Snap. Also worth a read is this blog post about disguising Chromium as an APT package being an act of "subversion".

I do not know any more details about the Mint situation than what is available online. I think this move by Linux Mint is largely political and is hostile to users; it removes choice. Because of this, my personal dislike might color some of my answers.

The page in your addendum gives two issues. Let's address the FUD (Fear, Uncertainty and Doubt) first:

"Backdoor via APT"

Before Chromium was distributed by a snap, Canonical was paying a single developer to do almost nothing else except packaging Chromium updates for Ubuntu. By distributing Chromium as a snap, this developer now has much more time to work on other parts of Ubuntu desktop. I like that decision, it keeps the Ubuntu desktop team focused on what really matters. It seems like Linux Mint wants a deb package for Chromium but they don't want to create it themselves, they just want to use the work Canonical was doing for many years. I don't think Linux Mint is entitled to that work. If Linux Mint thinks that work is worth paying for, they should hire a developer themselves.

The second issue seems to be the "deb to snap" package for Chromium, what they call "the backdoors" (fear). They claim Ubuntu might drop APT (uncertainty) and don't believe Canonical when they say apt will keep existing (doubt). The chromium apt package is a "transitional" package. Transitional packages have been used in Debian and Ubuntu for a very long time. They are used when a new release removes some packages. The transitional package simply installs an alternative. Without it, users would suddenly see software disappear when they upgrade their system.

This is the description of the Chromium transitional package: Transitional package - chromium-browser -> chromium snap. It makes it very clear what happens, it turns the chromium browser package into the chromium snap. The Linux Mint page adds the following "fear":

also run snap commands as root without your knowledge or consent

This really seems like a bad faith argument to me because every deb package runs commands as root without the consent of users! This is why they are so dangerous! This is one of the issues Snap wants to solve! I also would hardly state "without consent" when the description of the package literally states Transitional package - chromium-browser -> chromium snap.

Centralized control

This is somewhat true, for the snap store at least. Although it contains more fud like "Nobody knows how to make a Snap Store" (there was an open source one and Ubuntu Touch has a store for the precursor to snaps) and "following a protocol which isn’t open" (oh please, the code is open source and you can find docs online. uappexplorer connected to the snap store for a long time)

But I completely agre that it would be useful for a distribution to be able to "override" some packages. The snap store already supports that functionality because many enterprise users want that. The downside is that the snap store backend is closed source, but (1) we know it's not impossible so someone could create an open source store doing that and (2) Linux Mint did not actually ask Canonical if they want to open source that store. The last time Linux Mint wrote about this issue, Canonical reached out to them to see if they could solve it. However, it seems Linux Mint never actually continued the discussion, so it went nowhere.

If you look at how KDE and GNOME switched to Gitlab, you can really see the difference. When they were looking at options for hosting code, they had some criticism for Gitlab. Gitlab contacted them and said "let's see if we can fix this", and GNOME and KDE started collaborating with Gitlab to fix issues. If I'm not mistaken, Gitlab even open sourced some of their proprietary functionality in order to support them. This is completely normal for such large projects. The Linux kernel is now adding Rust support, but the rust compiler is missing some features the kernel needs. So the developers contacted each other and are now working together to fix those issues. Linux Mint can not expect to write a single blogpost, not respond for two years, and have the issues magically solved..

Thank you for the rest of your substantiated remarks! I might have been a bit rash in condemning Canonical for pursuing/building their own infrastructure. But I strongly believe it should always be published under an open source license (ideally AGPL-3) and I really don't like the Snap server being proprietary.

I agree.

Like any Snap? Or just Snaps released by snapcrafters?

Yes, any snap. I have personally worked with many other developers to fix issues in their snaps. As long as the snaps are open source, it's easy for us to do. Some issues are also caused by the snapcraft tool used to build snaps, so when we fix an issue there, all snaps receive the fix after they rebuild.

I'm happy to continue this conversation, too. Just was a little overhelmed by your extensive reply and only now found the time to answer. Sorry for the delay, which is in no way meant as a sign of contempt.

This is our chance to solve the software distribution issues that have been plaguing Linux for decades. I personally much rather help achieve that goal than dismiss an attempt because it isn't perfect yet.

Absolutely agree. And I much appreciate your efforts to help the Linux desktop become more user friendly!

I personally do not think org.videolan.VLC is a sensible identifier. I think vlc is the actual sensible identifier, and this is what people expect.

I could imagine there are some valid arguments for namespace-like app IDs like those of Android and Flatpak. But I'm not an expert on the subject and you're probably right that most people expect the above ID to be just vlc.

When you have a single snap store, there can only be one vlc and the snap store team solves name disputes based on what users will expect to install.

Well, a federated system with an appropriate concensus mechanism to avoid name ambiguities would be ideal IMHO – and not a store governed by a single Linux vendor. But I'm aware this is complaining on a rather "high level" given the current Linux desktop app distribution reality.

Regarding the "solving name disputes on what users will expect": So is there some public and transparent process for this? Or at least some kind of committing documentation that explains this in detail? How does Canonical determine "what most people would expect"?

I agree that these should be much more visible and work is ongoing to make them available in the Snap Store. Afaik, this situation is currently very similar to Flathub; the manifests and build logs are available, but it's not obvious how to get there from the store page.

I agree that exposing more metadata in Flathub would be desirable, too. But regarding the current situation, I strongly disagree that the situations between Flathub and Snapcraft are "very similar". Compare for example Thunderbird on Flathub with Thunderbird on Snapcraft. The latter is just awful – it doesn't provide a single link, neither to the upstream project nor to the publisher repo. I have to dig myself to find out that the publilsher "Ken VanDine" seems to be a Canonical employee (which is probably trustworthy). IMHO this is a bad UX.

I hope the efforts you mention to improve on this situation will be continued. Besides all the merits Canonical has done for the Linux desktop, it also has some record (Amazon lens) on making crappy decisions from a user perspective. So, I'm sorry that I don't blindly trust a commercial company to do the right thing just like that.

I don't think it's feasible to extend Flatpak to be able to do everything Snap can do. Even if it was feasible, I don't think the Flatpak devs actually wants that, because it would remove a lot of the advantages of Flatpak. The fact that Flatpak only does app distribution and leaves everything else to the distro is a big advantage for adoption.

Ok, I honestly don't know enough about this on a technical level. What is it that Snap does so differently that it couldn't be added to Flatpak, too? I'd be really interested in some enlightenment here. Comparisons like this one don't seem to indicate that there are so many fundamental differences...

Yes, any snap. I have personally worked with many other developers to fix issues in their snaps.

Cool, glad to hear!

Lock-in / platform economics

I also genuinely think it's good to have both Snap and Flatpak. They can learn from each others' failures and successes, for example. What I have an issue with is that some people act as if there's two "gangs" and if you like one of them you have to hate the other. I think the projects should work together even more than they do now.

I'm not in any "gang", trust me :wink: The situation of Flatpak vs. Snap just reminds me very much of GNOME3 vs. Unity. For me as a user, I would have preferred it if Ubuntu would have set on the "GNOME3-horse" from the beginning instead of stubbornly trying to set itself apart from other distros by developing a desktop environment they completely control (but still had to bury in the end). I can't get rid of the feeling that the main motivation for developing Snap is the same – being in complete control (which, from a commercial perspective, allows for more attractive business models like "branded stores" etc.).

Last but not least, only one of the two "gangs" actuallly behaves like a gang and requires newcomers to sign a CLA to join in... 😏

You write

I do not know any more details about the Mint situation than what is available online. I think this move by Linux Mint is largely political and is hostile to users; it removes choice. Because of this, my personal dislike might color some of my answers.

and at the same time

I think it's entirely in Canonical's right to push Snap more than Flatpak. Fedora also doesn't install apt by default. Flatpak in Ubuntu is maintained, users can easily install it, and the Ubuntu devs make sure this experience is good. The team creating the Ubuntu Yaru theme, for example, also publishes the theme on Flathub so that Flatpaks on Ubuntu are themed correctly.

This is very different from what Linux Mint does, for example. Linux Mint goes out of their way to make it as hard as possible for their users to install Snap. I think this is the kind of "political/strategic" moves that actually hurts the Linux desktop as a whole. I don't think there is anything wrong with carefully choosing the default installed software but you should not make it harder for users to install other software if they prefer.

Nice if Canonical employees help to ease the Flatpak user experience (I haven't heard of this before, though)! But it's ridiculous to contend that these setup steps would be any harder for users to perform than these.

If Canonical would esteem the user's free choice as much as you seem to do, they would ship Flatpak support out-of-the-box in their Ubuntu Desktop. Period. In reality, Flatpak is not even included in the default Ubuntu 18.04 repos. As I see it, Canonical is no better than Linux Mint in that regard.

You kinda contradict yourself when you a) write

You're right that the snap store back-end is not open source. I'd like it more if it was open source but this is less of an issue than some people claim. As an example, take a look at the massive communities built on GitHub and DockerHub, which are both completely closed source.

and then b) write

If you look at how KDE and GNOME switched to Gitlab, you can really see the difference. When they were looking at options for hosting code, they had some criticism for Gitlab. Gitlab contacted them and said "let's see if we can fix this", and GNOME and KDE started collaborating with Gitlab to fix issues. If I'm not mistaken, Gitlab even open sourced some of their proprietary functionality in order to support them.

I think you know exactly why both GNOME and KDE chose to self-host a fully open-source GitLab CE instance over locking themselves in by using GitHub (or any other proprietary platform).

About the willingness of Canonical to open up their Snap store back-end and/or help implementing a free Snap server I can't say much else than that I've been hearing criticism from open-source "competitors" for several years now and Canonical spread some misleading statements about collaboration with other distros and obviously didn't follow open design principles. If Canonical really would be so open about having an open-source Snap back-end – why don't they just release their own under such terms?