Back in 2018, the Linux desktop was at a crossroads. We had multiple distribution formats, but Flatpak was rapidly emerging as the frontrunner for a universal packaging system. One of the most significant milestones in this journey was the growth of Flathub, the central hub for Flatpak applications.
This retrospective looks back at the early days of the platform, inspired by the technical insights shared by Jiří Eischmann during the initial growth of the Flatpak ecosystem.
The Flathub Philosophy
The goal of Flathub was simple but ambitious: to provide a place where developers could publish their apps directly to users, regardless of which Linux distribution they were using. Unlike traditional repositories maintained by distro developers, Flathub put the power back into the hands of the creators.
The Submission Process
Adding an app to Flathub in its early days was a developer-centric process, heavily reliant on GitHub and build automation.
1. Creating the Manifest
The core of every Flatpak is the manifest file (usually in JSON or YAML format). This file describes:
- The application ID.
- The runtime and SDK required.
- The source code location (GitHub, GitLab, etc.).
- Build instructions and dependencies.
2. Forking the Flathub Repository
To submit an app, you didn’t just upload a binary. You had to fork the main Flathub repository on GitHub and create a new branch for your application. This branch contained your manifest and any necessary patches.
3. Opening a Pull Request
Once the manifest was ready, you opened a Pull Request (PR) to the Flathub “new-pr” repository. This triggered a set of automated builds.
Bash
# Example of checking your flatpak build locally before submission flatpak-builder --force-clean build-dir org.example.MyApp.json
4. Code Review and Validation
Human reviewers from the Flathub team would then look at your PR. They checked for:
- Correct application IDs (using the reverse DNS scheme).
- Licensing (ensuring the app is legally allowed to be distributed).
- Sandbox permissions (following the principle of least privilege).
The Buildbot and Beyond
Once the PR was merged, the Flathub Buildbot took over. It automatically built your app for multiple architectures (x86_64, ARM) and pushed it to the main repository. Within minutes, your app was available to millions of Linux users.
2026 Perspective: How Flathub Won
Looking back from 2026, the submission process described here was the foundation of the modern Linux app ecosystem. Today, Flathub hosts thousands of apps, from small indie utilities to massive suites like LibreOffice and Blender.
The “experience of adding an app” in 2018 taught the community that a decentralized, developer-focused distribution model was not just possible, but necessary for the survival of the Linux desktop. While the tools have become more polished, the core workflow remains a testament to the power of open-source collaboration.
Today, when you install an app from Flathub on your Steam Deck, Fedora workstation, or Ubuntu laptop, you are benefiting from the security and packaging standards created during those early years. The rigorous peer-review process championed by the community is why Flathub remains the most secure way to run third-party software on Linux in 2026.
