As a lot of you already know, backward compatibility has never really been the strong suit of Linux or the BSDs. Part of this is cultural: there's a mismatch in expectations around dependency and package management, and userspace developers don't always appreciate that “old” code is often still doing real work. People break it without realizing how much depends on it, and compatibility suffers as a result.
So here's the problem, stated plainly:
Dependency management and compatibility haven't been solved elegantly yet. There have been interesting attempts: Canonical's Snaps, Red Hat's Flatpaks, and Simon Peter's AppImage all come to mind, but it feels like app distribution and compatibility are actually two separate problems that keep getting bundled together. The attempts above end up overreaching outside their actual problem domain. App distribution shouldn't be on the hook for handling userspace components or compatibility with userspace, and it shouldn't be on the hook for security either. Those are genuinely separate concerns and should be treated as such.
To be clear, I'm not trying to single out Flatpak as the villain here. What it's doing is a natural response to trying to solve a fragmented ecosystem all at once. It's a holistic fix for a problem that's anything but holistic.
The plan, then, is to rethink this from the ground up. Instead of meeting the fragmentation halfway, which is essentially what Flatpak does, the focus should be on building a stable, backwards-compatible userspace first, as the actual foundation everything else builds on. Package management or app distribution and security would be split off as two separate concerns, each handled by its own subsystem, rather than crammed into the same tool. Naturally, this raises immediate concerns, particularly regarding the risk of centralization. These concerns are addressed in the Implementation Detail section of this page.
Basically: bring the Windows NT compatibility promise to Linux.
Implementation Detail
The compatibility layer is deliberately abstracted from the userspace beneath it. The userspace is intended to remain stable in its own right, even when software interfaces with it directly; the abstract API exists to reduce applications’ dependence on particular userspace components and implementation details. It is concerned with the operating-system facilities that applications should be able to rely upon initialization, service management, application lifecycle, permissions, desktop integration, and similar functionality not with replacing every library commonly found on a Linux system. It does not attempt to impose project-specific versions of OpenGL, Vulkan, traditional C-style sockets, or every other established interface. Those technologies may remain available where they are appropriate, while applications that want a more portable and durable target can use the higher-level API. The purpose of this layer is therefore not to make the userspace irrelevant, but to make dependence upon any one part of it less necessary.
Applications will primarily be distributed as application packages, but these packages are not required to be completely self-contained in the manner of an AppImage. Because the operating system provides a stable userspace and a stable application-facing API, an application does not need to bundle everything merely to protect itself from arbitrary changes in the host environment. The package may contain libraries and dependencies that are not part of the operating-system contract, including application-specific runtimes or, where necessary, its own C library (The project’s own C library is intended to be small, simple, and backward-compatible, but applications are not required to use it if another implementation better suits their needs). Publishers may bundle a more complete userspace when there is a specific reason to do so, just as with an AppImage, but this is an option rather than the normal distribution model. The aim is to avoid both extremes: applications should not depend blindly on an unstable host system, but neither should every application need to duplicate the entire operating system.
These packages may contain more than a single executable. Applications can be nested within one another, allowing a package to include supporting applications, tools, or components without requiring each part to be distributed independently. A Lisp-based definition and configuration layer will describe the package’s contents, relationships, metadata, dependencies, configuration, and required behavior. The same language will also serve as the principal configuration and systems language for the wider operating system, allowing the entire system including installed applications, services, permissions, system settings, and other state to be described as a reproducible configuration. Rather than applying a sequence of manual changes, the system can evaluate that configuration to produce a complete declared state, allowing environments to be recreated, compared, versioned, and rolled back. In this way, application packages and system configuration can share a common, inspectable means of describing composition and behavior, while still remaining separate from the stable operating-system API itself. The language is not intended to make every implementation detail part of the compatibility promise; rather, it provides a flexible mechanism through which applications, packages, and system components can be composed and entire system environments can be reproduced.
These packages will be distributed through a dual system. They may be installed directly from downloadable or offline sources, or they may be installed from repositories selected by the user. A synchronization system is also intended to allow packages installed from non-repository sources to be synchronized with a repository, and packages obtained from a repository to be detached, cloned, and used independently. In either case, the package may later be synchronized with its original or selected repository when necessary. The precise verification method used to establish legitimacy is outside the scope of this article; the important point is that repository-based and standalone distribution are not mutually exclusive states.
This gives the system flexibility without sacrificing compatibility. Applications can be obtained through repositories when convenient, deployed independently when required, and moved between those forms without being permanently tied to a single distribution channel. Combined with the stable userspace and application-facing API, this provides a distribution model that is both highly compatible and adaptable to online, offline, centralized, and independent use cases.
The project is not intended to become a centralized source for Linux or a mandatory standard imposed upon existing distributions. It is an independent system and reference implementation whose interfaces and design can be adopted voluntarily. If the approach proves useful, other projects should be able to implement compatible systems or create direct derivatives without relying upon one central organization or vendor-controlled source. A successful implementation would earn its place by providing a useful stable userspace, a durable abstract API, reliable application distribution, and a coherent security model. Other implementations could then preserve the same application-facing contracts while differing internally. Compatibility would emerge from usefulness and adoption, rather than being forced upon the wider Linux ecosystem.