> Instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. This actually is not the case (

> Instead of relying on distro maintainers who, say, check one version of OpenSSL, I'll be relying on the devs of each package. This actually is not the case (although you could do it). While Nix has the capability for every package to have it's own dependency tree, the actual channels/repositories don't keep track of more versions of packages than necessary. For example, OpenSSL has exactly 3 versions; the 3.0.x branch, the 1.1.1x branch, and the 1.0.1x branch. Some applications need the old 1.0.1x, most are probably on 1.1.1x, while others are moving towards 3.0.x Nix allows you to distribute packages and their dependencies as quickly as upstream allows but it still defaults to allowing dependencies to update normally and will rebuild packages automatically. For comparison, I checked Archlinux's repositories and they also have two versions of OpenSSL but they have to make sure the shared libraries don't conflict on the filesystem while Nix handles this automatically. For more sane examples, Nix can easily provide 5 different Python versions, 5 PostgreSQL versions, etc. But if a package doesn't care what the exact Python 3 version is, then it can just take "python3" as an input which will automatically upgrade as you would expect. If a package works with 3.8 but not 3.9 then it can be pinned to 3.8. Additionally, while the NixOS nixpkgs repository has a lot of maintainers, there are a lot fewer members with commit privileges so it's not the NPM wild west. With extensive use of Github actions/tags, they can quickly merge simple updates while making sure packages definitions are of high quality.