A German Government Agency Just Committed €508,640 to Fix Linux App Sandboxing Through 2027. The Useful Question Is Who Pays for Your Layer.
On August 27, Modal Collective announced that Germany's Sovereign Tech Agency is investing €508,640 into Flatpak through its Sovereign Tech Fund. The work runs through the end of 2027, co-organized by Modal with Para-Real Ltd. as the supporting organization.
If you do not ship Linux desktop software, your instinct is to skip this. I would push back on that, because the reason the money was needed is the story, and it generalizes.
From the announcement, on why Flatpak's security work stalled: development slowed "due to the specialized expertise required for this kind of platform-level work and the limited capacity of the overstretched Flatpak maintainers."
Now go through your own dependency list and count how many layers that sentence also describes. For most solo operators the honest answer is most of them.
What the money actually buys
This is not a general grant. There is a published technical roadmap, which is itself unusual enough to be worth noting.
New portals are the bulk of it. An audio portal that implements a static socket permission for PipeWire plus a WirePlumber policy, so that an app can be granted speaker access without also getting your microphone. That distinction does not currently exist, which is a genuinely startling gap in 2026. A network portal that isolates networking from the host with static permissions scoped to host, local network, internet, and specific ports. A VPN portal modeled on the Android and iOS APIs, so third-party VPN apps can manage system-level connections. A writing-assistance portal for spell checking, letting sandboxed apps share a system dictionary. And architectural research toward a secure password auto-fill portal to replace the current NativeMessaging approach, which the announcement describes as insecure.
Then infrastructure: an entitlements system for declaring static permissions so app store reviewers can verify what an app can actually do, an intents system for apps to declare offered services and handle deep links, and maintenance work including a port to libdex and integration tests.
The named contractors include several people from the 2023/2024 GNOME Sovereign Tech Fund project, plus new contributors and a veteran GNOME designer. Modal states an explicit secondary goal of growing the pool of people who know this part of the stack and putting more formal structures in place for Flatpak.
Why the gap existed in the first place
Flatpak is the primary application distribution method for Fedora Silverblue, openSUSE Aeon, SteamOS, and GNOME OS, and it is the preferred format for GNOME, KDE, and elementary. It is, by Modal's own description, the best option that exists on GNU/Linux today.
It also still trails Android and iOS on sandboxing. The audio example makes this concrete: on a phone, speaker access and microphone access have been separate permissions for over a decade. On the Linux desktop, through Flatpak, they have not been separable at all.
That gap is not a competence problem. It is a funding problem with a specific shape. Platform-level sandboxing work requires deep expertise, produces no visible features, and cannot be done incrementally in evenings. It is exactly the category of work that volunteer maintenance does not produce, no matter how good the volunteers are. Android and iOS have this because Google and Apple pay salaried teams to build it.
So a government agency stepped in and bought two years of specialist attention for roughly half a million euros. Which, set against what a single senior platform engineer costs at a large tech company, is not a large number for the amount of surface area it covers.
The transferable part
I do not think the lesson here is about Linux, or even about open source funding models in the abstract. It is a question you can answer today about your own stack, and most people cannot.
Pick the five things your product would stop working without. Not the big obvious ones. The auth library, the image processing binary, the date parser everyone depends on, the runtime for your background jobs, the thing that generates your PDFs. For each one, answer: is anyone paid to maintain this?
There are only a few possible answers. A company maintains it as part of a commercial product, which means it survives as long as the product does and dies or changes when the strategy does. A foundation with funded staff maintains it, which is the most stable outcome and the rarest. A government or public-interest fund maintains it, which is what just happened to Flatpak and which comes with an end date, in this case December 2027. Or nobody is paid, and it persists on the goodwill of people with jobs.
That last category is much larger than most of us admit, and it is not a moral failing on anyone's part. It is just a fact about the dependency graph, and knowing which of your dependencies are in it changes what you do when one of them has a security issue or a maintainer burns out.
Where I would push back on myself
The obvious objection: unpaid maintenance has worked fine for decades, and cataloguing your dependencies' funding status is busywork that produces anxiety and no code. There is something to that. Plenty of critical unpaid software is rock solid and has been for twenty years, and plenty of well-funded corporate software gets abandoned when a VP reorganizes. Funding is a weak predictor of survival at the level of any individual project.
The second objection is that government funding is not obviously more durable than the alternatives. The Sovereign Tech Fund's Flatpak commitment ends in 2027. What happens after that is a policy question decided by people who are not thinking about Flatpak, and a two-year runway followed by a cliff is not automatically better than steady volunteer maintenance. I think it is better here, because the specific work being funded is the kind that only happens with dedicated time and it produces durable infrastructure rather than ongoing obligation. But that is a judgement about this project, not a general rule about public funding.
I also want to be honest that the roadmap could slip. The announcement itself says "as design and implementation begin, these plans may evolve," and two-year open source roadmaps have a track record.
What I would actually do
Spend twenty minutes making the list. Five dependencies, one line each, answering who is paid to maintain this. You are not doing it to take action on all five. You are doing it so that when one of them makes news, you already know which bucket it is in and how worried to be.
For the two or three where the answer is "nobody," the useful follow-up is not to panic or to fork anything. It is to know what your replacement would be, roughly, and to sponsor the maintainer if you make money from their work. GitHub Sponsors at a small monthly amount is not charity and it is not going to save a project by itself. It is the cheapest possible option on continued maintenance of something you have already bet your product on.
And if you do ship Linux desktop software: the audio and network portals are the ones to watch. Separable microphone permission and scoped network access are the two changes most likely to affect what you can promise your users about privacy, and both are now funded work with a public roadmap rather than a wishlist item.
Author
Lukas
@lukcombinator