My desktop machine is running Kubuntu for a while now. As the new LTS came out I decided to update it. One major change in this release is that Firefox is no longer provided natively, instead it is a Snap package. If you have any experience with computers you might guess that this will cause issues. It surely did.
First the upgrade failed on Firefox and left me with broken packages. After fixing that by hand I did have Firefox but it could not be launched. The launcher app only shows a "Find Firefox" entry but not the browser itself. It can only be run from the command line. For comparison, all apps installed via Flatpak show up properly.
I could go on about this and Snap's other idiosyncrasies (like its insistence to pollute the output of mount with unnecessary garbage) but there is a wider, reoccurring issue here. Over the past years the following dance has taken place several times.
- A need for some sort of new functionality appears.
- A community project (or several) is started to work on it.
- Canonical starts their own project aiming to do the same.
- Canonical makes the project require a CLA or equivalent and make the license inconvenient (GPLv3 or stronger).
- Everyone else focuses on the shared project, which eventually gains critical mass and wins.
- Canonical adopts the community project and quietly drops their own.
This happened with Bzr (which is unfortunate since it was kind of awesome) vs Git. This happened with Mir vs Wayland. This happened with Upstart vs systemd. This happened with Unity vs Gnome/KDE. The details of how and why things went this way vary for each project but the "story arc" was approximately the same.
The interesting step is #4. We don't really know why they do that, presumably so that they can control the platform and/or license the code out under licenses for money. This seems to cause the community at large to decide that they really don't want Canonical to control such a major piece of core infrastructure and double down on step 5.
Will this also happen with Snaps? The future is uncertain, as always, but there are signs that this is already happening. For example the app delivery setup on the Steam Deck is done with Flatpaks. This makes business sense. If I was Valve I sure as hell would not want to license such core functionality from a third party company because it would mean a) recurring license fees and b) no direct control of the direction of the software stack and c) if things do go south you can't even fork the project and do your own thing because of the license.
If this ends up happening and Snaps eventually lose out to Flatpaks then I'd like to send a friendly suggestion to the people who make these sorts of decisions at Canonical. The approach you have used for the past ten plus years clearly does not seem to be working in the long term. Maybe you should consider a different tactic the next time this issue pops up. There's nothing wrong with starting your own new projects as such. That is, after all, how all innovation works, but if the outcomes have no chance of getting widely adopted because of issues like these then you are just wasting a lot of effort. There may also be unintended side effects. For example the whole Mir debacle probably delayed Wayland adoption by several years.
A more condensed version would go something like this:
History shows us that those who oppose cooperation have eventually ended up losing.
Full disclosure bit: In the past I have worked for Canonical but I did not have anything to do with these decisions and I didn't even know where and how they were made. I still don't. Everything in this blog post is my own speculation based on public information.
I mean, you might have a point, but to straighten out history here: Upstart *did* come before systemd. And I think first release of bzr also came a bunch of days before git.
ReplyDeleteSure, but this is covered by "The details of how and why things went this way vary for each project but the "story arc" was approximately the same.".
DeleteOn some occasions step 2 and step 3 were swapped: but the problem and the conclusion were the same. For example Upstart is older than Systemd (by almost 4 years according to Wikipedia), but the CLA probably largely contributed to the motivation of creating Systemd instead of improving Upstart.
ReplyDeleteI don't use Ubuntu and didn't worked for Canonical but used the same list often in discussions. Minus Bzr which I missed? Forking or creating an own solution for the right reasons is helpful but for the wrong reasons (bad communication, human interaction...) is just a loss:
ReplyDeleteUpstart vs. Systemd
Unity vs. GNOME
Mir vs. Wayland
Snap vs. Flatpak
I assume Flatpak isn't perfect. For example question as user the high number of files within "/var/lib/flatpak". And I see the need for purchases and fees and the valid business case behind it. This is not wrong! But we don't need another proprietary App Store. On the other hand I see all the improvements Canonical made recently on GNOME and especially Mutter. Maybe also some decisions made by GNOME within last years could have been made different when Canonical would have been more cooperative.
To be fair, snaps come from click packages which became snappy which became snap and had a completely different target audience than flatpaks (IoT) and then got repurposed to app delivery.
ReplyDeleteFlatpak still has no means of distributing command-line software afaik, so it only competes in the desktop application subspace.