I think many, too many still fail to see two thing: - packages/package management is intimately tied to filesystems and so installers. Actual package models ar

I think many, too many still fail to see two thing: - packages/package management is intimately tied to filesystems and so installers. Actual package models are based on '80s Unix model that do not scale anymore since decades. Such model was designed decoupling "system code" to "user code" (script, mostly) while all along the IT history, both before and after unix we see a better model (see below); - packages in FLOSS are NOT meant do be made by upstream developers, that's a need of commercial only software. In FLOSS systems packagers of any distro package upstream code. Now a step at a time: classic systems where designed as a single application, indefinitively extensible by many, and users included. At a certain point in time AT&T/IBM and others say "ah, no that's bad" IMVHO just to deprive users of much power and gain the ability to sell limited, limiting and poorly designed crap. For more than a decade such decoupling take shape. After decades of big mess frameworks spring to life as a kind of middle-ground and they prove to be no better than the decoupled crap they try to solve without coming back to the classic OS-as-a-single-application model. Now essentially ALL non trivial applications being unable to effectively integrate each others try to be "the only one application" and finding no way to do so some pull out of the hat an even worse cage: hiding the OS on someone else computer, used as a bootloader of a modern more limited and limiting Java VM: the WebVM improperly named browser for legacy reasons. Pushing "the network is the computer" to "the cloud is the system". To solve this mess what we need is the original solution: the OS as a single application where source code is in the runtime, no "packaging" just SCM. Oh, surely that does not solve version conflict between source, these actually are ALREADY solved in architectural terms by the FLOSS distribution model: packagers assemble code. But working directly on source makes that far easier with simple sharable patches who happen to be also a bit distro-neutral. Nix/Guix offer the actual middle ground. To solve the storage mess it's far more complex. Today most solutions simply use a backend storage service, a kind of DB, no matter if SQL-alike or key-value or something else. SUN with zfs realize a very first limited evolution in that sense, but far from current needs. BeOS with if raw "query-able file system" have done another very small part before. https://twizzler.io https://twizzler.io seems to offer something more modern, but that's still an open issue.