Contributor retention

Development
42

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

I fully agree with that! From both my own experience in the past ~4 years and from what I know from other contributors. Occasionally I’m losing my motivation and just do less / only stuff related to packages I care about and then there are times where I’m motivated to do more.

And of course, constraints like a job or being a student (both apply to me for instance) are also relevant.

macOS support is often lagging behind, because we do not have a lot of maintainers on macOS, so it’s great that @domenkozar and others raised money, so that someone can be paid now to improve macOS support

I think that this was a nice idea. It is something to be answered by somebody who has more insights about the NixOS foundation, but I’m wondering if we have sufficient budget at the moment to actually pay somebody for maintenance work (follow-up question is how to decide who to pick).

However I fail to understand how these issues can be solved by ripping apart our package set.

First of all I’d like to know whether we’re talking about a subtree-like approach as it’s the case in e.g. the Linux kernel where I think it could work (though I don’t know for sure - I’m not a kernel hacker) or about just many independent repositories (e.g. for subsystems such as python packages, haskell packages etc), managed through e.g. flakes. This would be something I’m pretty much against it for the following reasons:

  • First of all, we need python3Minimal to build glibc since version 2.30 (IIRC), so it’s actually something needed to bootstrap stdenv, so we’ll either have circular dependencies or two python expressions. While this is certainly doable, I don’t think it will make the responsible maintainers happier. This is just the the first example that came to my mind, I just want to make it clear that the package set isn’t really a tree.
  • Due to Nix’s purely functional model (and only an experimental CAS implementation), changes in core packages such as openssl, glibc and friends will basically cause a full rebuild. This is currently manageable (from my PoV at least) since we have a few people doing a decent job at maintaining the staging workflow. However I don’t see how this will work with packages distributed over tons of let’s say flakes:
    • As soon as a core package changes in a breaking way, we usually create a branch from staging and fix the majority of failing stuff there (minor things can be fixed in e.g. ZHF iterations). Since there’s only one jobset to watch and one branch to work at, it’s a lot of work, but doable (done that myself or helped out during such changes).
    • As soon as we have to make a lot of changes like this, one would have to contribute to tons of different repositories, keeping probably even more dependencies (in the worst case weird circular ones) in mind. Tbh, this would be something I’d refuse to do.
    • Also, some of you may know that people tend to run into issues when mixing up different glibc versions due to ABI incompatibilities. Right now, we can keep the issue somewhat under control, but I doubt that this will be possible if we have to do this for multiple repositories. In the worst case, endusers will have to solve these issues on their own and tbh, I wouldn’t take any distribution seriously if I had to do this.
  • Also, what about security updates? I’m aware that the current situation isn’t optimal, but what will happen if we have to make sure that every subsystem takes care of these? Usually rebuilds are needed to fix let’s say openssl CVEs. Right now it’s possible to push a patch to staging-next (or even master), wait for a rebuild & channel bump and we’re done. If I have let’s say a matrix-synapse subsystem, I’ll have to wait for at least the stdenv subsystem and the python subsystem (this scenario is e.g. relevant for a “bad” glibc CVE).
  • Disclaimer: I don’t have such a big problem with removing niche packages that are probably used by two people, my problem is that if we stop being a software distribution, I’m afraid that we’ll run into the problems I described above. Don’t get me wrong, I’m happy to be proven wrong :slight_smile:
16 Likes