The case against upstream packaging (postscript)

Original The case against upstream packaging The case against upstream packaging (postscript) Editable
version 2 of 2

Disclaimers, et al. These opinions are not at all related to Arch Linux, though maintaining Arch packages has certainly colored my opinions. I've been a volunteer maintainer for years now, because I feel it helps people. I have a bias towards the value that maintainers and maintaining packages provide.

While most people are talking about the new future of Universal Linux Packages from a technical standpoint, the social perspective isn't getting much attention. Frankly any technical issue can be solved by a better "universal package" but the social changes can't be improved by emailing a patch. So let's examine the relationship between upstream developers, distribution maintainers and end users. With a focus on how we got here and where we might go next.

Andy (2016-07-05-11-53-42-829)

How about the perspective: Look at the Apple app eco system. There you have dmg packages and it seems to work pretty well for their users.

Classic downstream Packages are perfect for the vanilla core system and server solutions but not for the Desktop. They overload the distributors as bottlenecks.

Why not take inspiration from the success Desktop systems?

Normally I really like the word 'upstream'. But it has a lot of connotations and doesn't suit the tone of this essay. To define it, upstream is generally used as a collective pronoun to mean "the group of people who gives us software". They are people who fix bugs, add features and occasionally make mistakes. They have the best interests of their users and their software at heart. They are good people who always mean well and take pride in their work. Upstream is not a single group, but spread among everyone who writes software.

"Upstream", however seems to be a mostly-FOSS concept, largely a side effect of the selective pressures that distributions provide. Since this essay goes into what a weakening of distributions would look like I'm going to use the original, older, uglier, more agnostic term "Independent Software Vendor" or ISV.

Why say ISV? Why does this word matter? "Upstream" is used both collectively for FOSS as a whole and singularly when talking about a single project. This re-use of the word is a small flaw as it suggests all software developers are fundamentally the same. This is not the case: some have very different values. Being "upstream" also has an implicit social contract attached to it. The "I", for independent, is to remind us that this is not always the case. And the "V" is for vendor, a reminder that sometimes these are businesses who consider profitability to overrule all other considerations.

Obviously this does a disservice to those who volunteer their time and intelligence without compensation, and do consider software quality and user happiness to be important. For the purposes of this essay I'm painting everyone with the "ISV" brush, even those pillars of the community who deserve better. But we are heading towards a future where the nice guys don't win.

Let us start with the (recent) past that kicked off the whole idea of "ISVs can package stuff" and "maybe we don't need maintainers".

The Cargo Cult of App

The promise: Phone app stores came out of nowhere and suddenly had millions of developers appear out of the woodwork overnight! If we make our distribution more like phone app stores then we get millions of application developers!

Peter (2016-06-21-21-50-22-453)

I think you mean premise, not promise.

The reality: App Stores have been a nearly unmitigated disaster for users. Supposedly one of Linux's failings is that there is too much pointless choice, too many K and G versions of things and it divides developer efforts. Why have so many window managers and text editors? App Stores have the same problem. With the traditional FOSS model, there are a hundred different programs and each program is missing a different feature. In the App Store, there are a hundred different programs doing the same thing but each screws the user over in a slightly different way. Spying? Ads? Battery sucking rookie mistakes? Battery sucking bitcoin mining botfarm? Take your pick.

The promise: But Linux is different! No one does those horrible things on Linux! And no one ever will!

The reality: But is it different? Somehow we've gotten this idea that everyone who writes software for Linux does it for the warm fuzzies. No Linux ISV tries to take advantage of people, and none of them ever had. Linux has been around for 20 years. Everyone has been ethical and trustworthy the whole time. Clearly they have proven themselves and will continue to be ethical and trustworthy. Alternatively, Linux is somehow immune to this darker side of human nature.

Andy (2016-07-05-11-57-50-222)

Is there any service you can buy to make downstream packages for your project, to get your code into the 15 flavours of a distribution?

Maintainers are the Difference

Linux-related news might suggest maintainers are useless. Either they are bikeshedding on mailing lists or closing bugs as WONTFIX, or introducing security vulnerabilities in software they don't understand, or generally being a BOFH. Of course this is wrong - we simply want to use the best operating system possible. So what does a maintainer actually do?

Mostly a maintainer is a packager: they take software from an ISV and repackage it for a distribution's packaging system. And here is where some people feel is a huge waste. Why package the same software a hundred times for a hundred different distributions? (There is good reason for this "waste", but let me finish describing everything else a maintainer does.)

More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support overhead. Non-bugs are caught and filtered out. Low-quality bugs reported to the distribution's tracker often becomes a good bug when the maintainer reports it upstream. Without distros the ISV would have to carry the full weight of support. Here's an example:

<NewUser> I've never gotten OpenSCAD to work on my computer, so I don't know anything particular to it.
<@teepee> NewUser: we could help with that (hopefully) :)
<NewUser> I'm gonna upgrade my system software when Slackware proper is RTMed. We'll see then.
<@teepee> ahh, cool, slackware is still around
* teepee used that like 15 years ago
<NewUser> Not a lot. I'm also installing Arch.
<@teepee> ahh, with arch, that's easy, you just complain to keenerd if it's not working
<keenerd> teepee: Spot on :-)
<@teepee> :)
<@teepee> it's always good to know there's someone who cares

Maintainers also shield users from developers, offering a layer of quality control. At the very least, all the software in a distribution should play friendly with any other piece of software in the repositories. Maintainers are responsible for that, as well as choosing a subset of the (subjectively) best software FOSS has to offer. Maintainers will disable features that they feel act in bad faith. Maintainers' greatest power is the ability to outright say "This is not good enough for our users" and consequently punish an ISV by either patching out the offensive part or in extreme cases removing the software from the repositories. ISVs know this and so don't act out. After 20 years of enforced good behavior this has lead to the idea of ISVs as "the benevolent upstream developer." This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising.

It is simply not possible for abusive software to exist in Linux today. No maintainer would willingly release it. If a maintainer ever got a reputation for releasing abusive software they would be stripped of their privileges. Someone who cares steps up and becomes a maintainer instead. The system is aggressively self correcting. It has been like this for twenty years, so much to the point that few Linux ISVs even consider being unethical. And Linux users have a very hard time imagining that any ISV could ever act in bad faith.

TR2 (2016-06-20-21-19-29-651)

"No maintainer would willingly..."? Hooboy, that optimistic outlook doesn't match my ongoing experiences. Let's consider some ready examples. First, the "geany" (text editor / IDE) application -- in just about any distro it has been (re)packaged for... you'll find the same ol' (asinine) default orange-text-on-white-background configured for cod syntax highlighting. Second, firefox web browser -- it's replete with plenty of abusive (or, privacy-unfriendly, at least) default preference values. Third, Akonadi -- same (unwelcome) default preconfigured behavior exists in 4+ distros where I've livebooted and found it preinstalled as default audiofile mime handler: it is configured to scour attached drives, searching for all a/v files present and (on the pretext of "retrieving missing album art") contacting 7 or 8 various "partner" websites (, jamendo, etc.) telegraphing the manifest of installed files found. I've strived to present distro-agnostic examples here; plenty more ready examples exist, supporting the (my) observation that "no, the (maintainer middleman) system is not aggressively self-correcting"; rubberstamp repackaging is the norm.

Clearly, across distros, the maintainer(s) of a given package are often too overworked/rushed to attend to configuring sane defaults, or just don't care, or do care but don't want to rock the boat by second-guessing the app author's chosen default configuration details, or don't have a sound grasp of implications related to the myriad configuration details of the application(s) they've agreed to repackage. Take your pick -- which "excuse" shall we attribute this sorry state of (mis)maintenance?

Stefan (2016-06-24-02-39-20-646)

Or like when the SuSE maintainers packaged BIND8 headers and BIND9 libraries in the bind-devel package. Or like when SuSE people also managed to mismatch the kernel headers and the shipped kernel, so the headers would tell you that a certain sockopt was available, but it wasn't. Or like when a kernel guy changed an ioctl()'s semantics, and the parted maintainer didn't understand the implications, so many people ended up with their dual boot machines not booting anymore; no distro maintainer got that either. Granted, it was a while ago (~SuSE 9 I think).

Come on. ISVs aren't perfect, maintainers aren't perfect. You can't simply talk about the failings of one camp, while assuming the other camp's problems are negligible or don't exist.

Maintainers Provide Consistency

For the sake of argument, let us presume that all ISVs are ethical and hold the interests of the community as their utmost ideal. Would this utopia still require maintainers to provide quality control? Yes, because no one can agree on what "quality" is beyond "does it build and run". Any good distribution is not about the file extension on the package - it is about the decisions the software implicitly makes. A distribution is a world view provided by the maintainers and shared by the users. In other words, maintainers don't just ship packages. They provide a certain flavor of consistent and preferred opinions to a group of users. (As an aside, this is why users of different distros often don't see eye-to-eye.)

Could ISVs possibly make everyone happy? They can't. It is impossible. What happens when two groups of users expect different things from the same software? To give an example, imagine an ultralight distribution like Puppy. They want the software as slim as possible. Recompile as i386, it'll save 5%. Chop out the built-in-help, we'll use the website. Get rid of the autosave-every-0.1-seconds, it'll wear out the flash drives. Now imagine an Ubuntu user. They want every bell and whistle enabled. In fact, could you add integration for our new notification and desktop search services? And then imagine the paranoid LFS user. They don't trust any binary package and insist on getting full sources, reviewing them and building them From Scratch.

mentaiko (2020-08-25-08-22-45-994)

How do the developers of Signal messenger meet the needs of all (Linux) demographic groups by providing only sources and .deb binaries which offer exactly the same functionality as the "maintainer versions" for openSUSE, Fedora, Arch, ... ? I.e. , e.g. what is the added value of compared to ?

What is an ISV to do? They can try to package half a dozen different flavors of their software. Now a hypothetical cross-distro Universal Packaging Format is not saving them any effort because they need to make (and test, and support) a different build target for each demographic of users. Or the ISV can ignore some users, making a subset of them unhappy.

If people are unhappy enough they will repackage the software in a more suitable manner. Now the users have unwittingly become maintainers. The moment someone starts improving 3rd party software, they become a maintainer.

And if a maintainer shares their packages, they'll attract like-minded users who appreciate the work as well as like-minded maintainers who can share the workload. And thus a distribution is born. It can't be fought. A monoculture will breed diversity.


To clarify a few points often heard:

  • The promise: Sandboxing makes you immune to bad ISVs.
  • The reality: It protects you from some things and not others. App Stores have proven that ISVs will try to get away with as much abusive behavior as possible. Sandboxing protects against many threats, but does not suddenly make people ethical. Distributions with human maintainers are more likely to make mistakes than an OS-enforced sandbox, but human maintainers are also more likely to sniff out the dumb stunts that ISVs try to pull. No human maintainer is ever going to willingly package a flashlight app which phones home. From source anyway. I imagine sandboxing will be used as an additional layer of safety in most distros (eventually) but mostly for the purposes of protecting from honest mistakes.
  • The promise: By cutting out the maintainer middle-man, security fixes can be pushed out to users faster.
  • The reality: Often maintainers are faster, particularly with anything using shared libraries. A distro can update a shared library once and all software is now safe, without needing to rebuild every piece of software using it. Most of the sandboxes do not share libraries and so you are waiting on the slowest ISV to rebuild their software. If they ever do. ISVs are notorious for using ancient libraries with extensive out-of-tree patches and never migrating the patches forward.
  • The promise: A universal package means that ISVs don't need be aware of every distro and its unique quirks.
  • The reality: They don't need to and never have. Put out the sources with a makefile. The maintainers can handle the rest. It's what we do. Heck, the makefile is optional. We can write one. (But please merge it when we send a pull request!)
Andy (2016-07-05-13-18-03-940)

How good does the classic system scale?

Is there a package for every distribution out there?

  • No. There are always less practically supported packages for your distribution than theoretically available ones. Depending on how large the user base it could be more or less. While it is technically possible to provide all software it never happens.

Is maintaining packages for multiple distributions a fruitful task?

  • No. It is a waste of open IT human capacity.

  • The promise: App Stores are a re-spin of the traditional distribution repository. One central location, easy search, easy install, automatic updates. Its practically the same thing.
  • The reality: They are still sorely lacking. No app store has the slightest concept of dependencies. They often aren't even dogfooded for the operating system's software. And of course anything that passes an automated scan can get into an app store. Distributions provide extensive curation that you can't get without an army of volunteers.
kiilo (2016-06-22-01-23-09-548)

Yes, reminds me sort of revival of the DLL hell :-) [HTML_REMOVED]but sandboxed, problem solved?[HTML_REMOVED]

  • The promise: Make an App Store and a million devs will appear to fill it with software.
  • The reality: Smartphones had a large user base before they had any apps. Get the users first and the devs will follow. Thinking an app store will bring in more developers is cargo cult logic at its finest. It will however bring in a wave of opportunistic software that was previously barred from Linux. There are entire frameworks designs to wrap an Android or iOS application with malware, integrating ads or analytics with a single click. That simply wouldn't make it past a maintainer.
kijin (2020-08-25-08-39-03-350)

That is to say: maintainers also inspect the code of closed-source (.deb, .rpm) software?

  • The promise: A common packaging effort will improve the quality of software on Linux, because packaging for every distro is too hard.
  • The reality: Handwriting is too hard. I have created a solution, the "keyboard". Now people will no longer write dumb things because the hard part is solved. Making packaging "easy" will not improve the quality. Just like how legible writing has no relation on writing intelligently, the mechanics of packaging has no relation on the quality of software. Write good software, release sources, and every distro will package it for you.
  • The promise: ISVs releasing packages means less duplicated work between distros.
  • The reality: Distros exist because users can't agree on how exactly we want software. A universal package will not be good enough for some percentage of them. The actual act of packaging is the fastest part. The slowest part (fixing bugs that upstream hasn't) is shared between distributions because all of our patches are public.
  • The promise: Many embarrassing bugs will be avoided, because ISVs are smarter and more experienced than maintainers.
  • The reality: Oh boy the stories I could tell about the things I've seen. But out of courtesy, I won't name names. Needless to say they are as dumb and human as we maintainers are. If you want, think of maintainers as outside consultants who will find the craziest thing an organization is doing. Except we don't charge $200/hour for what amounts to best-practice common sense.
  • The promise: Software directly from the ISV has a complete chain of trust and is better for users.
  • The reality: This is only true if the ISV won't try to sneak something in. You don't need to have blind trust in your maintainers, but don't get rid of them either. Instead, verify their work with your own builds and examine the chain of trust the distribution provides. Distros are usually way more open about the chain of trust than ISVs are.

Yes, all of this will happen.

I don't mean to pick on Shuttleworth, but he has explicitly stated that the whole point of their new universal packages is to give control to the ISVs. If you believe "control" is a finite resource then giving implies taking from elsewhere. Most likely from the maintainers and users. To quote:

"With snappy Ubuntu, Owncloud can publish exactly what they want you to use as a snappy package, and can update that for you directly, in a safe transactional manner with full support for rolling back. I think upstream developers are going to love being in complete control of their app on snappy Ubuntu Core."

Walt (2016-06-18-10-32-31-048)

Sir, Automatic updating is a horrid idea. Look at Microsoft's windows 10.

Thanks, Walt

MA (2016-06-22-01-24-09-348)

Shuttleworth is only hiding the fact that Ubuntu is severely understaffed and so it is merely a feeble attempt at tossing the packaging efforts upstream to the ISVs because he doesn't want to do it or sponsor proper maintenance. All the support period promises pertain to only a small portion of Ubuntu.

There's a reasonable German-language write-up on Ubuntu's non-support here:

And that's what makes Ubuntu - in my perception - drive endeavours such as new packaging approaches.

Not only will they love it, some are probably already cackling with glee at the prospects of "complete control".

Alternative Solutions

No, I'm not just going to carp about how change is bad. Here are some other ways to achieve the same goals.

Let's say your distro wants to attract developers. Suse's method has been to set up a comprehensive build service. Now the ISV doesn't have to maintain a distro-specific toolchain, the distro will do that for them. And if it builds on the build server, the distro promises that it'll run across their operating system. And Suse should be commended for supporting several distros beyond their own. Of course these services are not cheap. In exchange for hosting the service, the distribution retains their ability to curate. If an ISV acts in bad faith and refuses to meet the distro's standards, then the distro can de-list their packages. Suddenly the ISV needs to spin up a tool chain and hope that people will google them instead of using the integrated search and proceed to "sideload" their software.

Let's say you don't have the infrastructure for a giant build server, but you still want it to be easy for devs to get software into the distro. First and foremost, your distro should be easy to contact. Put in big letters on the home page something like "Want your software in the official repo? Send an email to this address and our maintainers will look at your proposal and get back to you soon."

Let's say you're an ISV and you want your software in a distro. You could learn how to make and release packages, but it is much less effort to cooperate with the distro and find a maintainer who will champion your software. And keep in mind this is a purely social solution to a supposedly technical problem. Supporting a dozen distros doesn't require learning a dozen build systems, just making a dozen friends at different distros. Note they don't even have to be an actual maintainer - any trustworthy person familiar with a distribution can do this job. Admittedly if you're an ISV who does proprietary software you are going to need some really good friends.

Maybe finding friends and contacting distros is hard. Perhaps we need a matchmaking organization that can pair up potential maintainers with ISVs.

Rens (2016-06-20-01-24-34-781)

Tindr for ISVs?

"Slick, high performance database backend seeking energetic Debian maintainer. Fully SQL compatible; plugins for PHP, Perl, Python possible; Ubuntu and Arch experience preferred..."

But let's presume you are an ISV who writes proprietary software. In this case, please don't release binaries. Give the maintainers source code and they'll do everything for you. You might think it is impossible to be proprietary and release sources, but you would be wrong. Microsoft has some brilliant lawyers who have drafted licenses which let you keep proprietary levels of control.

post_install() { echo $message; }

Maintainers, distributions and all the variety of "wasted duplicated effort" is the only reason the system has worked. Maintainers are the ambassadors between users and developers. Together we have formed a beautiful symbiosis with FOSS programmers because we could freely tweak, build and distribute their software. We will always disagree, do something about it, attract users, attract volunteers and formalize these groups as distributions. Putting packaging in the hands of those who write software (instead of those who use it) will inevitably lead to a proliferation of bad actors, as has been demonstrated in every other major operating system lacking strong community curation.

Thanks to Ivy Foster for reviewing drafts of this.


Wow! Around 15k unique visitors in the first 24 hours! A small thanks to Rackspace and a big thanks to static site generators for making that possible. Naturally with so many eyeballs there will be some feedback. Here are the /r/linux and the Hacker News threads.

kk (2016-06-16-12-53-37-419)

LWN thread

kk (2016-06-22-06-43-20-129)

Some thoughts about the most common reactions I've seen. For those who gave positive support and talked about technologies that give more power to users, thank you. I'm mostly going to focus on the negatives though. None of these are actual quotes, but amalgams of discontent.

"This essay is extremely self serving and exaggerates the importance of maintainers."

Well yes. I did put the disclaimer at the top. You were warned.

"That is nice and all but distros just don't have the manpower to do a good job, so I'll use ISV packages."

"There's no distro package for anything I want to use, so I'll use ISV packages."

"I don't want to be stuck on five year old software, so I'll use ISV packages."

"I don't want to update my entire OS just to get a new version of one program, so I'll use ISV packages."

Haakon (2019-05-24-13-15-42-045)

I think this is slightly unfair. I really do appreciate the work maintainers do, and I don't care if Firefox is say, 3 weeks out of date. The web still works fine. However, snaps means that I can get, say, Eclipse installed. A new version, which is great! And since it doesn't share libraries, I don't have to worry about how well it works either.

For me, the point of snaps are those 2-5 programs that are special to me. I can have those, and I can let the rest be left to the distro.

Is that an optimal solution? No. But it's clearly a more comfortable solution than what we had before snaps. Would I like to see everything being snapped? No. I'm not that insane. I see enough of the sheer hellscape that happens when everything has its own copy of the libraries in normal day to day activities to agree that snaps are not THE SOLUTION to packaging.

Turning to an ISV package as a primary solution to distro problems is not the answer. Another wrong answer is the change distros because the grass is greener. If you are not happy with your distro the solution is always the same: become more active in it. All of the aggressively-self-correcting mechanisms are powered by disappointment. Channel yours productively. Here is the general distro-agnostic sequence:

kk (2016-06-17-06-18-39-084)

is to change

lemon (2020-08-25-09-03-26-996)

Explain this to tech-agnostic Linux users.

  1. Learn the packaging tools. Your distro has made all of these available and well documented. Start by simply re-building the official packages, then customizing the official packages, building/customizing unofficial packages, and finally making new packages for software not in the distro.
  2. Share your new packages. Possibly your custom ones too.
  3. Actively work to improve your distro as much as you can. Write and submit patches, mostly. Fix bugs, both distro and upstream. Create tools that make the other points on this list easier/faster/safer.
  4. After doing this for a few years, you will either want to become a maintainer (and people will want you to become one) or you will have decided it just isn't the distro for you.
kk (2016-06-17-06-27-23-691)

1.5 - Now you can run any version of software on your install via custom build.

As a side note, switching to a rolling distribution was the most common suggestion. While on average this means you get new software earlier it does have its own headaches. (The "update my entire OS" complaint.) I suspect the best solution for release-based OSes is for semi-official 3rd party repositories. These would be run by actual OS maintainers (not random folk in a user repo) and simply offer more recent versions of in-demand pieces of software. Obviously they would not be held to the same reliability standards as the rest of the release, but they should have the same level of safety and trustworthiness. I would not be surprised if many of these already exist but are not well publicized.

"No one is saying that all packages should be replaced with universal packages from upstream."

Actually people have said that. I started assembling the draft of this essay three years ago. That was around the time containerizing stuff was just taking off. There were numerous articles with clickbait titles about how we wouldn't need distributions any more. And numerous people appeared to non-sarcastically support the idea. It is worth noting that Mark Shuttleworth also does not agree with clickbait headlines: "Nobody has suggested that snaps are the only way to do things going forward - don't misread headlines in the media as policy goals for me or anybody else, they are just ways to get attention to the article!" And conversely I feel the universal package technology is worth having and using. If nothing else, competition and variety are both good.

"Nix or Guix would solve all of this."

Your are absolutely correct! A fun project would be to figure out how to treat a distro repository as a giant collection of binary-only packages. Import the entire distribution and you instantly get a mostly familiar system but with all the futuristic transactional technology. Binary packages kind of cut across the grain of these tools, so I suspect this will not be easy.

kk (2016-06-17-06-38-22-387)

You are

"Here's a bunch of examples where $distro messed up."

Well yes, I did say we are still human. It is worth reading through the comment threads for specifics but I had expected people to come up with better examples than OpenSSL and the Ubuntu Lens. I was particularly amused by the person who suggested that it was a failure of maintainers that Heartbleed was detected by professionals at a security firm first. They are the professionals, I would hope they are better at it. Our job in security is to make sure 100% of installations are patched as fast as possible.

Ubuntu and Debian were mentioned the most. I suspect this is not because they are worse, but because they are popular.

Where it becomes tricky is when the distro is also an ISV. Most distributions hate writing software, even when it is seen as a pillar of their existence. When I started using Arch, /etc/rc.local was the reason to use Arch. We dropped it faster than you could say "good riddance" after a replacement we liked came around.

But some distros are in the business of becoming more and more of an ISV. Or occasionally an ISV will decide they need to have a distro. This leads to conflicts of interest and ethically questionable monetization decisions that never go over well with the community. Mint seems to be the counterexample of a good ISV/distro hybrid. They somehow manage to be an ethical upstream developer, listen to people and collect donations without making anyone too upset.

"Linux has mainstream malware and ad-ware."

Okay, no one actually said this directly. But they could have. The Opera browser for many years shipped a free banner-ad supported version. I even used it, because it was just so fast on a Pentium 2. And even after Opera did away with the ads, they had a license that made redistribution on mirrors (let alone modification) impossible. I was going to use this as an example, but it was more than a decade ago.

And finally, my apologies to Mr. Shuttleworth. He commented here and even personally emailed me within 12 hours of this going up. I tried very hard to keep the essay completely agnostic with regards to specific technologies, but he had the first pull quote I found and was the only person I named explicitly. This was lazy of me - I should have found similar quotes from all the major platforms.

TR2 (2016-06-20-21-34-41-960)

I'm not a ubuntu user, nor am I particularly enthusiastic about the prospect of dealing with snappy packages but this 4minute video

and another (I can't find the link. IIRC, it's a 45min Shuttleworth stage presentation, filmed during 2015 or 2016 SCALE convention, in which he thoroughly explains the rationale behind snappy, snaps, snapcraft ...and the related benefits to both devs and for users)

those videos throroughly impressed me. Respect!