Flatpak's Two-Year Maintenance Freeze: What 500M Downloads Didn't Reveal

Patch for Last Week's Snap vs Flatpak Article

Last week we covered the decade-long Snap vs Flatpak rivalry, praising Flathub's ecosystem — 500M+ cumulative downloads, 3,400+ applications, and upstream projects like GIMP, LibreOffice, and OBS officially maintaining their own Flatpak builds. Those numbers are real.

But that article missed one crucial detail. Today we fill the gap.

While the storefront thrived for three years, the engine behind it — Flatpak itself — nearly fell into pure maintenance mode.

Every app in the store updated on schedule, shelves fully stocked; yet in the engine room, core development had almost halted. This contrast remained hidden until a security vulnerability in April 2026 tore the cover off.

A Security Fix Lifts the Veil

In early April 2026, Flatpak released 1.16.4 / 1.17.4 to address a severe issue — CVE-2026-34078, a complete sandbox escape . Impact in one sentence: a malicious app could break out of the sandbox, read/write host files, and execute code in the host environment. The sandbox is Flatpak's foundation; this hole pierced its security promise.

The fix arrived quickly. The bad news came in the following days — regressions from the fix broke some browsers and the Steam client, forcing the team to ship 1.17.4, 1.17.5, and 1.17.6 between April 8–10 to stabilize.

What truly chilled observers was a simple check of the release logs.

Before this batch of security fixes, Flatpak's stable release line had been silent for nearly a year — the previous stable 1.16.1 shipped in May 2025, then nothing until April 2026 when the vulnerability forced action. Going further back, 1.16.0 arrived 14 months after 1.14.4.

By August, the picture sharpened — newly released 1.19.0 patched over a dozen security advisories (GHSA series), from sandbox escapes and path traversals to privilege escalations, a thorough cleanup.

Two years of accumulated security debt were paid down in a single 2026 sprint.

An infrastructure handling hundreds of millions of downloads per year — why the silence? The answer isn't technical; it's human.

Two-Year Freeze: Because "People Left"

Rewind to April 2025's Linux Application Summit. Red Hat engineer and GNOME member Sebastian Wick delivered a talk bluntly titled "The Future of Flatpak" , covered in detail by LWN.

He opened with a hard truth: by every metric Flatpak is successful, but look deeper and "it is no longer being actively developed." People maintain code and fix security issues, but "larger changes no longer happen." A pile of feature merge requests sits untouched; no one feels responsible for reviewing them.

Why? Core maintainers left one after another.

Founder Alexander Larsson (Red Hat employee, working on similar projects since 2007) essentially stepped back from daily development, only appearing when absolutely necessary.

Kalev Lember left Red Hat in February 2025, closing the flatpak-preinstall feature PR he'd worked on for most of a year.

The successor Wick resubmitted that PR, waiting nearly three months for a single review .

The most painful detail — zstd:chunked compression support (which lets Flatpak updates download only changed files instead of entire image layers) was submitted as a PR in September 2023. As of LWN's May 2025 report, it was still "sitting there" untouched.

A feature that would tangibly improve every user's experience waited a year and a half.

New contributors couldn't get traction either. Wick noted major changes waited months for first feedback, then months more for a second round — "not a good way to onboard people." A vicious cycle formed: veterans left, newcomers couldn't stay, features froze, only security maintenance remained.

Lay the timeline out straight:

2023-11 : 1.14.4, last release of previous stable series — Normal

2025-01 : 1.16.0, arrived after 14 months — Slowdown begins

2025-04 : Wick presents "The Future of Flatpak" at LAS — Problem goes public

2025-05 : 1.16.1, then stable line goes silent — Darkest period

2025-11 : 1.17.0, development line resumes — Recovery starts

2026-04 : CVE-2026-34078 sandbox escape fixed, three releases in days — Security stress test

2026-06/08 : 1.18.0 stable, 1.19.0 patches 10+ security issues — Full return

From the feature freeze in late 2023 to the development line revival in late 2025, this engine "ran sick" for nearly two full years . During those two years, the store operated as usual; nobody noticed.

The Ironic Contrast: The Hated Snap Is Doing Fine

Bring Snap into the comparison and you find a brutal dark humor.

Snap's controversies we covered last week — forced auto-updates, closed-source backend, Firefox cold start at 4.1 seconds, single centralized repo. Community dislike is real; MIT Technology Review-style critiques are abundant.

But Snap has one thing Flatpak lacks — Canonical's full-time salaried engineering team . Whatever you think of its design, it iterates on a stable quarterly cadence, security response never late, roadmap actively owned.

Flatpak's side? Red Hat contributes a few engineers' time (Wick et al.), Debian developer Simon McVittie backports fixes for stable releases (August's 1.18.2 was his backport work), the rest runs on volunteer passion.

Governance : Snap — Company-led (Canonical); Flatpak — Community + partial Red Hat time

Full-time staff : Snap — Dedicated team; Flatpak — Handful + volunteers

Iteration cadence : Snap — Stable; Flatpak — Frozen for two years

User sentiment : Snap — Constantly criticized; Flatpak — Widely loved

Ecosystem openness : Snap — Closed backend, single repo; Flatpak — Fully open source, self-hostable

One-sentence summary of this contrast — "The one getting cursed has a boss paying salaries; the one getting loved runs on love."

This isn't a victory lap for Snap or Canonical. It exposes open source's perennial problem: why can't core infrastructure maintenance come with a stable paycheck? Behind Flathub's 3,400 apps stand hundreds of passionate upstream developers; the foundation of the whole marketplace once rested on two or three people's sense of duty. Open source calls this the "bus factor" — one bus hits the team, the project paralyzes .

Why It Didn't Die

Fairly, Flatpak's last two years were far from dignified, but never reached "dead." Three redundancy mechanisms kept it alive.

First, security maintenance never stopped. Even in the most understaffed 2025, vulnerability patches shipped on schedule. Open source projects can be slow, but they held the "no security incidents" baseline.

Second, distributions backstopped. Debian's Simon McVittie continuously maintained stable backports — distro packagers are naturally upstream's last line of defense, a deep resilience of the Linux ecosystem.

Third, app layer and engine layer are decoupled. Flathub app updates flow through their own channel; during the two-year engine freeze, users barely felt it — both a relief and the reason the sickness went undetected.

But the cost is real. During the two-year freeze, a stack of necessary work stalled — nested sandboxes (essential for per-tab browser isolation), network namespace isolation, NVIDIA driver sharing model. Wick listed these debts one by one in his talk. Not to mention that zstd:chunked feature waiting a year and a half.

Future: Embrace OCI, Stop Reinventing Everything

The second half of Wick's talk laid out Flatpak's future. The direction is surprisingly simple — embrace OCI, stop building everything yourself .

What is OCI? The container image standard from the Docker world. Flatpak currently uses its own OSTree distribution plus a custom toolchain; globally, people who understand this stack are few, and everything must be maintained in-house. In the OCI ecosystem, registries, transport protocols, incremental compression, security scanning — all are pre-built wheels maintained by others.

Wick's ten-year vision in one phrase — "OCI for almost everything." Desktop apps, games, dev tools all run on the same container standard; Flatpak only keeps the sandbox runtime as its own small piece. Even a Rust rewrite of the core isn't off the table.

Proof this path works: Microsoft's newly released WSL Containers are fully OCI-native — the Linux container world's standard is settling from "Docker's proprietary format" into "industry-wide public infrastructure." Who stands in this river doesn't have to maintain their own dams.

Snap likely won't take this route. Its closed backend and single repo are deeply bound to Canonical's enterprise strategy — not a flaw, a choice.

The ten-year landscape will likely be dual-track — OCI-standardized Flatpak-next, and self-contained Snap ecosystem, each serving its own users.

User-level advice hasn't changed: prefer Flatpak for desktop apps, leave system services to apt, keep both — if one breaks, you have a fallback.

The One Thing to Do Right Now

After all this big-picture talk, on your own machine it comes down to one action — update Flatpak to latest . April's sandbox escape and August's batch of security fixes are already available in distributions.

flatpak update          # upgrade all apps and runtimes
flatpak --version       # 1.18.x or higher is good

Defense principle is simple: exploiting these vulnerabilities requires "a malicious app already running on your machine" — so the old rule applies: don't install apps from untrusted repos; Flathub's official review mechanism remains trustworthy.

One-Sentence Summary

Ecosystem prosperity and engine health are two different things. For three years Flathub hit 500M+ downloads while the foundation had only two or three people holding it up.

Linux packaging's next decade won't be decided by which format wins the war, but by whether the open source world can learn one lesson — pay salaries for core infrastructure . Otherwise the next "silently frozen for two years" infrastructure might be the one you use every day.