And lets not forget an even more prominent example: Upstart by Canonical that RedHat replaced with Systemd.

Basically, Canonical will start at a project first, but RedHat specifically will look for ways to not join them, and start their own project instead.

Part of that is certainly due to Canonical itself, but I can't help but think a lot of it is RH making a call and then throwing more developers at something.

Upstart’s CLA was a non-starter.

Canonical has quite a history of the behavior you're dinging Red Hat for: Mir, Unity, LXD, Juju/Charms, Launchpad, and I'm sure I'm forgetting several.

Also it’s Orwellianly named “Harmony” effort to popularize CLAs because Canonical has long sought to control upstream technologies - and consistently failed because they do not play well with others.

Just to add to those wondering, CLA = Contributor License Agreement.

Ah, yes. Thank you - sorry for assuming on that one. I tend to get lazy when replying on my phone...

Sure, I have acknowledged there are plenty of missteps by Canonical too.

Though I don't think CLAs are a problem (FSF requires them for GNU projects too), but lack of committment not to switch to a non-free license.

Unity happened as GNOME 3.0 already went in an entirely different direction (mostly led by RH engineers) from 2.x series and as Canonical simply couldn't influence GNOME design. With a paradigm shift one way or another, it was a sensible move.

Launchpad was created as a tool to develop Ubuntu and free software: there was nothing else (and there still isn't) quite like it. Sure, it took a while to get it open sourced, but lack of contributions afterwards kinda proved the point that that wasn't really important (I mean, GitHub wasn't and still isn't).

Mir/LXD/Juju were attempts to improve on the incumbents (Wayland/Docker mostly).

The reason why Lennart decided to start systemd is publicly documented: the 2 facts that upstart had a serious design flaw requiring large changes, and that Canonical required copyright assignment for those changes. CLAs that unilaterally benefit a single for-profit business entity are generally seen as problematic.

Read this thread:

https://web.archive.org/web/20140928104327/https://plus.goog...

Here, Upstart author and former Canonical employee Scott James Remnant wrote:

Had the CLA not been in place, the result of the LF Collab discussions would have almost certainly been contributions of patches from +Kay Sievers and Lennart (after all, we'd all worked together on things like udev, and got along) that would have fixed all those design issues, etc.

But the CLA prevented them from doing that (I won't sign the CLA myself, which is one reason I don't contribute since leaving Canonical - so I hold no grudges here), so history happened differently. After our April 2010 meeting, Lennart went away and wrote systemd, which was released in July 2010 if memory serves.

snap's original sin was the moat of server being closed source and client /really/ wanting to talk only to the Canonical's instance. The latter is shared by Docker, in a way.

It's so upsetting that canonical will continually come up with cool tech, try to keep complete control over it and ideally make it so it long term becomes the only option, which people understandably don't jive with. Had they learned that in the space theyre in an open approach works better, we could still be using mir, upstart and most importantly unity now. God I miss unity.

I dont use docker anymore (podman ftw) but that is unfair criticism of docker.

You can use any container registry (including self hosted) with docker and it will work. Last I checked, you cannot use any other repo at all with snap without recompling it to add support for your snap repo.

By "in a way" I've meant the encroachment of the default namespace. Much less smaller sin than snap's, but then docker is much bigger.

I thought flatpak was a response to Ubuntu not open-sourcing the snap store code.

Sure, but I don't think it would have been much effort to build a snap store server with the client and package format open source.

IOW, if RH wanted to "join in", there was a cheaper path forward.

You don't want to be a sharecropper; using a format you can't meaningfully influence for something as key as application installation, is an obvious non-starter for any serious distribution.

Isn't the server software proprietary?

https://en.wikipedia.org/wiki/Snap_(software)

So I don't see how RedHat or any other FOSS distributor could have been happy with Snaps.

Flatpak development actually started much earlier than that. The first version happened in 2007 when it was known as "Glick".

https://github.com/flatpak/flatpak/wiki/Flatpak's-History

And AppImage was already a thing in 2004. To bad that everyone has to reinvent the wheel when it comes to packaging instead of building on the existing solutions.

> they do have a problem getting the community involved, but part of that is the size and limited time their developers have.

A tiny inconsequential part. The bigger one is their refusal to give a shit about usage outside of Ubuntu with Canonical-controlled servers and their insistence on CLAs. Canonical has noone but themselves to blame for Red Hat to continously win the community for their solutions even when they were late to the party.

Click was preceded by Alex Larsson's glick project, see this page from October 2007.

https://web.archive.org/web/20071012194830/http://www.gnome....

There was also glick2 in 2011.

https://web.archive.org/web/20111022070435/http://people.gno...

You may have heard of Alex Larsson as author of xdg-app.

I think the oldest related project was Klik, started in 2004 (and later renamed to AppImage).

This is his blog about the history of Flatpak.

https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

Also, the reason why Canonical have "a problem getting the community involved" is that they put a KEEP OUT sign on every one of their projects in the form of a CLA requiring copyright assignment.