GNOME Software in Fedora will no longer support snapd

In my slightly infamous email to fedora-devel I stated that I would turn off the snapd support in the gnome-software package for Fedora 31. A lot of people agreed with the technical reasons, but failed to understand the bigger picture and asked me to explain myself.

I wanted to tell a little, fictional, story:

In 2012 the ISO institute started working on a cross-vendor petrol reference vehicle to reduce the amount of R&D different companies had to do to build and sell a modern, and safe, saloon car.

Almost immediately, Mercedes joins ISO, and starts selling the ISO car. Fiat joins in 2013, Peugeot in 2014 and General Motors finally joins in 2015 and adds support for Diesel engines. BMW, who had been trying to maintain the previous chassis they designed on their own (sold as “BMW Kar Koncept”), finally adopts the ISO car also in 2015. BMW versions of the ISO car use BMW-specific transmission oil as it doesn’t trust oil from the ISO consortium.

Mercedes looks to the future, and adds high-voltage battery support to the ISO reference car also in 2015, adding the required additional wiring and regenerative braking support. All the other members of the consortium can use their own high voltage batteries, or use the reference battery. The battery can be charged with electricity from any provider.

In 2016 BMW stops marketing the “ISO Car” like all the other vendors, and instead starts calling it “BMW Car” instead. At about the same time BMW adds support for hydrogen engines to the reference vehicle. All the other vendors can ship the ISO car with a Hydrogen engine, but all the hydrogen must be purchased from a BMW-certified dealer. If any vendor other than BMW uses the hydrogen engines, they can’t use the BMW-specific heat shield which protects the fuel tank from exploding in the event on a collision.

In 2017 Mercedes adds traction control and power steering to the ISO reference car. It is enabled almost immediately and used by nearly all the vendors with no royalties and many customer lives are saved.

In 2018 BMW decides that actually producing vendor-specific oil for it’s cars is quite a lot of extra work, and tells all customers existing transmission oil has to be thrown away, but now all customers can get free oil from the ISO consortium. The ISO consortium distributes a lot more oil, but also has to deal with a lot more customer queries about transmission failures.

In 2019 BMW builds a special cut-down ISO car, but physically removes all the petrol and electric functionality from the frame. It is rebranded as “Kar by BMW”. It then sends a private note to the chair of the ISO consortium that it’s not going to be using ISO car in 2020, and that it’s designing a completely new “Kar” that only supports hydrogen engines and does not have traction control or seatbelts. The explanation given was that BMW wanted a vehicle that was tailored specifically for hydrogen engines. Any BMW customers using petrol or electricity in their car must switch to hydrogen by 2020.

The BMW engineers that used to work on ISO Car have been shifted to work on Kar, although have committed to also work on Car if it’s not too much extra work. BMW still want to be officially part of the consortium and to be able to sell the ISO Car as an extra vehicle to the customer that provides all the engine types (as some customers don’t like hydrogen engines), but doesn’t want to be seen to support anything other than a hydrogen-based future. It’s also unclear whether the extra vehicle sold to customers would be the “ISO Car” or the “BMW Car”.

One ISO consortium member asks whether they should remove hydrogen engine support from the ISO car as they feel BMW is not playing fair. Another consortium member thinks that the extra functionality could just be disabled by default and any unused functionality should certainly be removed. All members of the consortium feel like BMW has pushed them too far. Mercedes stop selling the hydrogen ISO Car model stating it’s not safe without the heat shield, and because BMW isn’t going to be supporting the ISO Car in 2020.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

9 thoughts on “GNOME Software in Fedora will no longer support snapd”

  1. Good riddance. Flatpak is community-friendly alternative and should have universal adoption (already has?). Canonical thinks it can use it’s market share to do what they want? Let them do it, alone.

    If anyone believes that moving away from free software ideas is smart, they aren’t thinking far enough into the future.
    Flatpak is free software. Snapd is a vendor semi-proprietary lock-in.

    1. @Laki lets keep in mind the first version of Snaps was released before Flatpaks so its not a thing where they just all of the sudden decided they wanted to do an alternative to Flatpak.

      1. Michael Tunnell lets keep in mind the first version of Snaps it only worked on Ubuntu and was not meant to be an a distro agnostic from day zero like Flatpak. Besides xdg-app (former name of Flatpak), it was already developed for a long time and Alexander Larsson had been working on proposals like that for a decade. My point is how silly your argument sounds “they were first.”

      2. First commit in Flatpak (named xdg-app at the time) is from December 17 2014: https://github.com/alexlarsson/xdg-app/commit/a640cd365bd21743165adedb00bd9fac981687b2

        First commit in snapd is from December 11 2014: https://github.com/snapcore/snapd/commit/d00bfa93d6c33c1a504342236761919386ba502e

        Seems to me like both were started in parallel at roughly the same time, not one before the other.

        To add a bit of context though, Alex has been working on app distribution for at least 12 years now: he released Glick 0.1 back in August 2007. Then he’s been working on Glick2 on and off until September 2012.

        While today Flatpak doesn’t share much code (if at all?) with those, you can see this topic has been brewing in Alex’s head for a very long time, and you can certainly imagine how all that work must have informed his work on Flatpak.

        So, should we count that as the real start of Flatpak development? ️

        I genuinely have no idea whether the snapd developers have a similar history of working on app distribution before snapd and that’s why I’m not talking about it. I’ll be happy to learn about it if someone wants to share that info. ️

  2. Wow what a complicated story! While we were already all convinced you were right.

    Focus on making gnome software ux strong, reliable. Forget about snap.

  3. Thank you. I have been pondering the differences between snaps and flatpaks. Recent Canonical/Ubuntu behaviour in which the snap for Chromium will apparently replace the repo package has disturbed me.

  4. There’s poor analogies, very poor analogies, and car analogies. ;-)

    Also, what’s with those “Kar Koncept” etc. names? Are you trying to insult the KDE project (which has nothing to do with this issue)? Or people whose names start with a ‘K’ (in which case I have to feel doubly offended ;-) )? Or is this just a cheap stereotype on the German language because you picked BMW for the analogy? The company that you are actually unhappy with has 2 ‘C’s and not a single ‘K’ in their name. ;-)

    Now, for the actual issue, I do not wish to take sides because I actually dislike both Flatpak and Snap. :-)

  5. So, you really don’t like BMW? I feel you.

    Not that I learned much about the issue at hand here. Thing is, all commercial Linux vendors want to earn money and everyone in these organizations is driven by that to some degree. Red Hat’s way and Canonical’s way of making money are still pretty different. Company leadership also works very differently between the two (if you want car analogies, it’s a bit like pitting Akio Toyoda v/ Elon Musk) which has huge influence on what communities form around the companies and where/how they participate in communities.

Comments are closed.