When I was most active, Nixpkgs was new and interesting. I was intrinsically motivated to learn and discover how to use nix to package and use software. But as I “mastered” it more, it became less intriguing and more ordinary. Since nixpkgs is a voluntary opensource community, you “give up” your free time to be able to contribute to it. Right now, I mostly want to do “what’s needed” for the release, but not much more.
Similar to what @danieldk said, it’s very “gruntish” to do the grind of nixpkgs. Many upstream sources knowingly or unknowingly package breaking changes. This causes a large amount of work to react to the necessary breaking changes or poor release management. And unless you use that software regularly, there’s not much benefit to reviewing and testing that software from a “committer” point-of-view. At best, you updated or packaged some software, at worst you broke someone’s workflow and caused them trouble.
I don’t have great awareness of other FOSS projects, but I would expect many of them have similar contribution behaviors. Where, you have many contributors which do “drive-by” contibutrions, less which have “spikes” of contributions, and even less who contribute semi-actively for many years.
On top of this, Nixpkgs, is largely a “niche” community. We are significantly different from the other distributions do not “play nicely” with how they do package management. We can augment their package management, as most users are free to use nix alongside their distribution, but it’s another thing entirely to use nix as your package manager exclusively. I think if we were more mainstream, there would be more of an incentive to retain your “nix expertise”, as you will likely use them in the future. But currently the trend seems to be leaning toward to docker, with preference given to your background of using apt vs yum vs apk vs others.
I would say that the thing which I dislike the most about nixpkgs is that the work is mostly repetitive when contributing to nixpkgs. Reviewing a PR usually means doing a nixpkgs-review, and testing of some of the commands. Maybe there’s some comment about a better way to do something, but usually it’s just very repetitive and unrewarding. I’m usually reviewing software which I don’t use, and don’t care about. If it was my job, that would be one thing, but when I’m choosing to sacrifice my free time to review something, it’s another thing altogether. Not to disparage nixpkgs-review, ofborg, or other tooling, these are great additions to improving the quality of nixpkgs, but it’s not interesting or engaging for most contributors; and I feel like that is the main reason why contributors may walk away. They no longer feel really “connected” to anything, and that their actions are just “shouted into the void”.
. This is an open-source project; how do you suppose work gets broken up when contributions are completely voluntary? Efforts could be made here to help new contributors get familiar with the sprawling monorepo, perhaps triaging good first issues and things like that, but like all the other work of open-source maintainership, it takes work that someone has to do at the end of the day. So to write one sentence about the age-old problem of open-source maintainer burnout and then to call it a “simple” “solution” is a little bit reductive, I think.