Contributor retention

After about eight years of continually pushing stuff to NixPkgs, I feel like people with relatively intense contributions almost never hold out long and they tend to (almost) disappear soon.

Well, it makes sense that for most people it’s impossible to maintain that state over years, but it feels like there’s typically as a distinct cut-off rather than gradual decrease. (I don’t want to juggle vague names like “burnout”, but the symptoms generally seem close.) These events make me sad, but I’m not sure if it’s even possible to improve this somehow in our community, and I’m most likely not a good person to try doing something like that.

18 Likes

Do any of you(great contributors/etc) think that core members lack financial support from community, or maybe any other kind? Is there a solution nix community knows and just haven’t managed to implement for some reason yet?

For example it seems obvious that nix community should be capable to pay for most important maintenance jobs

I’m sure if you were to ask for donations on every occasion(banners in discourse, donationad in videos, pinned issue in repo, etc) you would get at least enough

P.S. I’m relatively new here, and not a contributor at all.

2 Likes

I split this into its own topic.

3 Likes

Burn-out can be one of the issues, but I can think of several other obvious cases:

  • Students often have ample time to work on things (at least I had when I was a student) and there is a sharp drop-off once they get a job, perhaps family, etc.
  • Sometimes you are in a position that is compatible with Nix and then you move on to another position where it is more difficult. E.g., I was in academia, which was very compatible with using Nix and NixOS – I could pick my own tools and infrastructure, and for rough edges that I encountered I tried to do PRs. I am currently consulting and when e.g. I was working on a Java-Rust library for a customer, which is much easier to do develop on a traditional FHS distribution, especially if that is also the target platform.
  • People’s interests change. This is perhaps related to the burnout point, but I think it is natural to get very hyped when you are new to NixOS. It’s so radically different and in some aspects so much better. But newness wears off at some point and then you either become a regular user (with perhaps less frequent, but regular contributions) or move on.

It would be nice to kind of have ‘exit interviews’ to get an idea of why people stopped contributing to Nix.

19 Likes

There is a simple solution to it: decentralization, break things up and spread the burden more evenly.

(Provocative Geistesblitz, context evolves in the discussion below)

1 Like

Couldn’t resist :stuck_out_tongue_winking_eye:. 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.

I think danieldk’s exit interview idea is great. Some data on why people leave might help address pain points specific to Nix projects. But ultimately someone will have to set that up :sweat_smile:

14 Likes

I’m purely arguing with the entire stack of viable systems theory and organizational complexity theory in my backpack. One is able to research that mostly without access to paid library services, it’s in the public domain. Peter Drucker & Stafford Beer make a good head start. That being put forth for the interested parties, now:

The owl analogy is brilliant!

Giving the drawing of an owl a twist: “We normatively need to focus on 1. The viable system will figure out the rest.”

The problem is precisely focusing too much on step 2. that prevents us from a — and I correct myself here — simple viable pathway to solution.

Proof: just 2.5 people spontaneously made real quick progress on divnix/devos in a “naturally emerging” bare two week sprint. Nothing was planned. Just decentralized spontaneous organization of the chaos by pure chance and social interaction. For the analogy, it would be a breaking out of lib.nixosSystem. ! And it’s been real fun ! — unthinkable in NixOS/nixpkgs is that.


But, I guess, instead of me dumping a good portion of the world’s management literature into the discussion to support my Geistesblitz, it will be much more powerful if a growing number of people figure that out for themselves.

So please do the research and find it out for yourselves!

nixpkgs is very different from a greenfields project. In greenfields projects you can always move fast. Maintaining nixpkgs is just the grunt work of doing a lot of updates and figuring out what upstream broke this time around. There are some larger, more spectacular changes, but they require planning and a careful roll-out because you cannot break the systems of thousands of people. Also, the whole PR process is necessary, because allowing everyone to commit to master (directly or through a bot) is a large security issue.

5 Likes

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”.

22 Likes

Our packaging infrastructure is so good that it takes far less work to do a drive-by submission of a new package than to actually maintain it. Combined with the tendency for Nix to eat up the world (since NixOS is not FHS-compatible, software often needs to be packaged to be used), we have a lot of leaf packages that probably have less than a dozen users, but still require the boring maintenance work. I think we would be better of with a smaller package set and have niche packages maintained by stakeholders in something like the NUR.

5 Likes

and mass adoption of flakes will help with that.

nixpkgs could be composed of a few tiers(separate flakes repos), with different level of scrutiny for contributors, the last one being nur where author of a contribution is solely responsible for the deriviation.

But i’m still inclined to think that nixos needs some fulltime paid maintainers/managers(in a good sense)

5 Likes

Nixpkgs is held together by Hydra and pushed apart by calls to raise quality standards uniformly. And if core parts need availability of a stream of newcomers, then we do want to hold Nixpkgs together.

I would surely be in favour of whatever makes version-and-hash updates to niche leaf packages mergeable by absolutely whoever has ever contributed anything at all (anywhere in Nixpkgs) if test pass. No tests? Well, build passes, good enough.

8 Likes

For me, this would only make the situation worse and make my live harder. If a drive-by contributor adds an obscure niche package to nixpkgs, then I can still easily update/fix/improve it, and the changes will get merged quickly. Even if I didn’t have commit access personally, there are several other people active who will merge it.

If that niche package was in some users’ NUR repository, then this would be much harder. The PR would sit a much longer time, since there’s only a single person who can merge it. Maybe that person has also lost interest in nixos by now. Fewer people review the changes and there’s no ofborg or other linting tools either, making breaking changes much more likely.

If the NUR is anything like AUR, then we should strongly discourage it. The AUR is full of badly-written, unmaintained, duplicate packages. Even the worst packages in nixpkgs are typically at least okay.

17 Likes

It doesn’t have to be in a single user’s repo. It could also be a community repo with a lower bar of getting a commit bit. Or perhaps topic-based package sets (science, games, …).

Also, while it is true that moving niche packages out of nixpkgs has its downsides, Keeping them in also has downsides. Just look at the PR queue and the number of packages that build but don’t actually work (I have encountered quite many when reviewing r-ryantm PRs).

2 Likes

Also, while it is true that moving niche packages out of nixpkgs has its downsides, Keeping them in also has downsides. Just look at the PR queue and the number of packages that build but don’t actually work (I have encountered quite many when reviewing r-ryantm PRs).

If only we had lower standards on test quality for currently untested things…

(also, for many niche packages with a grab-bag of weird use cases «actually does not work» and «useful» can coexist — if only we had not explicitly rejected lightweight tests for duplication with NixOS VM tests, we could have at least a chance of knowing which usecase was tested initially)

5 Likes

Automated tests could replace a lot of this. For example nixos tests catch a lot of problems but are also way underused.

edit: there are 478 nixos tests total, for 50000+ packages!

4 Likes

Note that contributors (as of recently) have been encouraged not to use NixOS tests for regular packages, since they are relatively expensive (fire up a VM, etc.). The passthru.tests attribute should be used instead.

Unfortunately, we also only have ~215 passthru tests.

5 Likes

seems like test coverage is something that could be improved with funding, it’s relatively simple and something noone wants to do, so put bounties on tasks like this, and some students will get it done relatively quickly

2 Likes

I haven’t used Ubuntu in a number of years, but they had the idea of a primary repository that was supposed to be “perfect”, and then “universe” and “multiverse” repositories (or whatever they were called) that were of varying degrees of quality, but usually decent enough. It wasn’t AUR or NUR, it was still Ubuntu community maintained, but with at least some standards (IIRC)

I wonder if introducing the idea of support tiers for packages would be helpful at all. Packages are still maintained in our monorepo, but we can apply more liberal automatic merge logic to them.

Just a random thought, maybe I’m off the mark entirely.

7 Likes

Part of this is, I think, documentation. The only mention in the nixpkgs manual, in the meta attribute section, is thin on how you’d write a test from scratch or what would be meaningful. Most of the examples in nixpkgs are simply selecting tests from nixosTests, so it takes a bit of hunting to get a sense of what patterns are “normal”, let alone best-practice.

I recall this coming up in the course of Improve a pkgs' tests for nixpkgs-update, but it doesn’t look like that produced anything yet (I think mostly because it was focused on the bot, and broke down around where the docs should go?)


No objection to bounties, but I also wonder if test-writing would feel more meaningful if we had:

  • a meta attribute for marking packages that are well-tested enough for updates to be auto-merged if they build and passthru passes
  • a standard for deciding when packages are well-tested enough to grant this attribute
  • a process for deciding whether a package is sufficiently tested to meet the standard?

In the short-er term, I imagine test-writing would be more intellectually rewarding (than update/review work) if the result was a significant improvement in the maintainability of a package (and the knowledge that, at scale, you’re helping rebalance what human maintainers spend time on?) Maybe @jonringer has a sense of whether that feels less Sisyphean?

Additional levers could be applied…

  • nudging people who use under-tested packages to submit real test cases
  • requiring them on new packages
5 Likes