I’ve been working on Flatpak for almost 4 years now, and 1.0 is getting closer. I think it might be interesting at this point to take a retrospective look at the history of Flatpak.
The earliest history goes back to the summer of 2007. I had played a bit with a application image system called Klik, which had some interesting ideas. However, I was not really satisfied with some technical details. One day at the beach I got an interesting ideas for a hack that could improve this.
Fast forward until August 2007 when I released Glick in the wild, based on these ideas. The name is sort of a pun on the old KDE/Gnome first-letter naming scheme, although neither Klik or Glick are really desktop-specific.
Glick was a a single-file-image system. It predates usable kernel container APIs, so it uses fuse and some weird hacks. It doesn’t integrate with the desktop in any way, and applications have to decide what to bundle, falling back to system-libraries for the non-bundled things. This means its not terribly robust., but it is completely stand-alone and need nothing installed on the host system.
Around 2011 the initial support for kernel namespaces had landed and started being useful. Using these I could avoid some of the hacks that my earlier experiment used. So, I got interested in bundling again and released Glick 2 based on this.
Glick 2 requires some software to be installed on the host, which allows it to integrate better with the system. For example, you can “install” bundles by putting the file in a known location, and doing this allows some level of desktop integration. Glick 2 also uses SHA1 checksums to try to automatically de-duplicate files shared between applicatins. Here we can see an early version of the ideas that make up OSTree.
Bundling using namespaces was lot more robust than the previous hacks, but it still relied on the system for the core libraries that the application doesn’t bundle. So an app would sometimes work on one distro, but not another.
Around this time I posted a blog about how I thought application bundling combined with read-only OS images can make a really good model for an OS. This idea is very similar to what Project Atomic / SilverBlue are doing now.
Containers, Portals and Runtimes
A few years later, around 2013 the kernel support for containers was starting to shape up, and Docker hit the market. I did a lot of work on the early docker, like porting it away from aufs in order to run on RHEL.
Around this time I also attended the Gnome Developer Experience hackfest in Brussels where one of the topics was Application deployment and sandboxing. From the discussions there (and my previous experiences) a lot of the core ideas of Flatpak, like runtimes, sandboxing and portals originated.
In 2014 the first version (then called xdg-app) was released. The current Flatpak is a lot more polished, but the initial version of xdg-app is still very much recognizable today.
xdg-app used OSTree to download, store and de-duplicate applications. It uses kernel namespaces (via a helper called xdg-app-helper) to do unprivileged containers. It has a split between applications and runtimes which allow applications to be portable between distros in a very robust fashion, while still limiting the duplication between applications and allowing security updates. There is also integration with the desktop (icons, desktop files, mimetypes, etc), and some very early portal code can be seen.
The great renaming
The name xdg-app was just something I picked for the first commit without much consideration, and it was not very good. However, names are hard, and we spent a lot of time trying to come up with another, eventually settling on “Flatpak” (with the above logo). The 0.6.0 release in may 2016 was the first with the new name.
The 0.6 release was also the first that split out the unprivileged container launcher (xdg-app-helper) into its own project, now known as BubbleWrap , hosted by Project Atomic.
Soon thereafter we had the first release of xdg-desktop-portal which is the host-side implementation of the portal idea, allowing sandboxed applications to safely break out of the sandbox in a controlled fashion.
Version 0.8.0, released december 2016 was the first long-term stable release, which was included in Debian Stretch and RHEL 7. Since then we have had another stable release series called 0.10.x.
We want apps!
Flatpak was always a decentralized system, in that anyone can host their own applications and be on equal terms with everyone else. However, while this is an important feature, it leads to a poor initial experience, both for users (hard to find apps) or developers (need to maintain their own repository).
To solve this we started the Flathub project, which is a single repository where you can find most apps. In the last year it has gone from a minimal viable product building its first app to something with more than 300 apps and a diverse group of developers.
Onwards and upwards!
No software is ever finished, or bug-free, but we have had a list of core things that we wanted to have before calling Flatpak 1.0, and that list is now empty. So, I’m planning to release a release-candidate (called 0.99.1) later this week.
Then 1.0 will be released later this summer.
10 thoughts on “Flatpak – a history”
This is an excellent history of Flatpak – thanks for writing it! Would you consider adapting this as an article? I think Linux Journal or Opensource.com would love to run something like this.
I don’t really have time to do that right now, but maybe I’ll look into it later this year.
Seeing Flathub getting fleshed out with more and more programs and games is pretty cool. However, a feature missing that I see in alternatives is availability of unreleased software. For example, there is a PPA that tries to build Dolphin-emu nightly. I’m sure frequent builds of a program’s “master branch” could help out developers that have projects with lots of changes. Will we ever see something such as “Dolphin Emulator Nightly” on Flathub or do you feel that should be maintained by someone from the project’s own community?
Gnome has a nightly builds system, and i think flatpak in general is a great way to test unreleased software. However, the resources to do this for flathub just is not there at the moment.
I completely understand. Keep up the great work.
This, so much. Every project whose “Reporting Bugs” asks users “Can you reproduce in the latest development version?” *needs* to have a link “…available here” to its nightly Flatpak. I don’t know what would make this easier – provide a Flatpak build container or build service, integrate it into CI pipelines and GitHub & Gitlab, badges?
As a user, it has been gratifying to see the command line tools improve and applications such as Gimp and LibreOffice become available as Flatpaks. Thanks and onward!
You say: “In 2014 the first version (then called xdg-app) was released.”
I think that would have been 2015, not 2014. The first check-in to the xdg-app repository was Dec 14, 2014. The first that I saw anything was an e-mail by you on Feb 11, 2015. But look for yourself from this e-mail in late May, 2015: https://lists.fedoraproject.org/pipermail/desktop/2015-May/012362.html
Yeah, the development started at the end of 2014, but I guess the first public release was in 2015.
Comments are closed.