nixpkgs isn't doing too hot

Open source maintenance continues to be difficult.

by Ruby Iris Juric

published august 9, 2026

• tags:

permalink

In case you can't tell, I'm kind of a Nix fanfox. I have a tendency to shove that thing everything it belongs, and most places it doesn't belong, too. I just think it's neat!1 Being able to specify every aspect of a Linux system or a development environment in extreme, stable precision is the sort of thing I just can't bring myself to let go of once I've gotten a taste of it. There's so much knowledge encoded into NixOS and Nixpkgs, and it's honestly kind of wild that so many people have coalesced around and contributed to those projects. It's a massive community effort, one of those things that rarely comes along, but when it does, it's honestly kinda beautiful, y'know?

...wait. sniffs Hang on. more sniffing You smell that? Smells like... like maintainers.

Burning maintainers.

Oh no.

we can't go over it

The broader Nix project (that is, the Nix/NixOS/Nixpkgs holy trinity) has, for quite some time now, been, uh... mired in governance complexities, shall we say. The transition from "de facto BDFL" to "structured governance bodies/teams" was quite a rocky one at the start, but the general shape does appear to have mostly stabilized at this point. I haven't been paying particularly close attention to how that new structure has been going,2 but from what I have seen, it's been a mixed bag. There's some rough patches, but there's also some signs that parts of the project are going in a positive direction, which is nice to see.

Unfortunately, those structures don't appear to be doing so hot as of late. Recently, the Nixpkgs core team announced their dissolution, citing struggles with member attrition and an ineffective Steering Committee. It's really unfortunate that the team found themselves in a situation where this was the only source of action they had remaining, but I also can't help but wonder whether this outcome was inevitable, to some extent. There seems to be a pattern emerging within the Nix organization, of teams being formed to tackle certain aspects of project management, and dissolving after struggling to do that management effectively.3

While the Steering Committee is a recurring theme in these events, I don't know if the entirely of the blame can be placed on them. To me, there seems to be a more fundamental issue of burnout at play here. Teams of volunteers are coming together to try and provide guidance to the Nix project, but ultimately failing as those volunteers start to accept that they don't have the capacity left to provide that guidance, and opt to leave their teams as a result. I really can't blame them - Nixpkgs in particular is an absolutely massive project. Even before adding a dubiously effective Steering Committee to the mix, there's so much in there to manage, design, and delegate, from NixOS to application packaging to language-specific tooling to CI and release management... It's a tall ask for a community of volunteers. Better governance alone can't solve that fundamental issue of scope.

we can't go under it

When it comes to people voicing criticisms of project leadership, there's always a group of people that come in with the age-old refrain of "just fork the project 4Head".4 It's very rare that this sort of thing is ever said in good faith, but, okay. Sure. Let's humour the idea here for a moment. There are definitely issues with the broader Nix project's governance, and we could theoretically work around that by bringing the project out of that governance environment. Would that work?

Turns out that this one was actually attempted last year, in the form of the ill-fated Floral project. It was a very ambitious project, that tried to spin up a full hard fork of Nixpkgs, with all of the infrastructure necessary to support it. Without getting into too much detail,5 the project started out with some high energy behind it, but gradually waned, as the true scope of the task became clearer, and we found ourselves lacking the time and the expertise to build out the tooling needed to run a Nixpkgs fork.

The work that goes into maintaining and providing Nixpkgs is a lot more complex than it looks on the surface. It's important to note that one of those components is a CI system that needs to be able to build the vast majority of the Nixpkgs package set - one of, if not the largest set of software package definitions out there - for both Linux and Darwin, on multiple architectures. That is not trivial! That is kind of the exact opposite of trivial! You can't have Nixpkgs without this very complex CI system, otherwise you run the risk of providing broken packages to downstream consumers.

I've seen Nixpkgs described by some as "too big to fork", and, yeah, I'd agree with that assessment. In fact, I might even go further and say that Nixpkgs is probably too big to maintain at this point. If one volunteer group found themselves unable to take the project and operate it themselves because of it's sheer scale, then it's not that surprising that the main project's volunteer group is getting burnt out as well. It's a necessarily complex project, and you can't just fork your way out of that complexity without severely reducing it's scope.

but how the hell do we go through it

Clearly, the situation here is getting pretty untenable. Nixpkgs hasn't been able to govern it's way out of burnout, and the broader community doesn't seem able to fork it out of there, either. Where do we go from here? What needs to happen to bring Nixpkgs into a place where it can thrive under leadership that isn't stuck trying to work through systems that are failing them, or reliant on the volunteer effort of a handful of people that understand all of it's technical complexity?

Maybe it's time to start cutting back on scope. It's bloody impressive that Nixpkgs is as comprehensive as it is, but - let's be honest - no one is using all of Nixpkgs. It's an admirable goal to package everything it does, but that goal is really starting to take it's toll on the project. Being selective about what gets accepted into Nixpkgs could go a long way to easing that maintainer burden. Sure, it's convenient to have everything in Nixpkgs, but it's also not that hard to bring in packages defined elsewhere, with tools and features like npins and Flakes. I think there's also some interesting technical ideas in this vein to be found in Tidepool, the Auxolotl project's attempt to create a Nix package set from scratch.

Could funding be a part of the solution? I know that I've got projects that I would really rather not maintain without getting paid. We're all just humans6 at the end of the day - volunteer work is admirable and all, but we've still gotta hold onto jobs that pay the bills and feed the mouths. There's a lot of talk about the "open source crisis" nowadays, especially with LLM coding tools lowering the bar for the most insufferable of techbros to screw over the signal-to-noise ratio of open-source maintainers. Open source maintainers have been taking on a lot of unpaid work, and the reality of that work is rapidly starting to catch up with them as the last remnants of the mask slip from the companies that pushed the open source model.

At the end of the day, I am but one single fox in the world. I don't have all the answers, as much as I love to spend time in my own head thinking about what they might be. I probably don't have the whole picture here, either, given how little time I spend around the Nix project's governance spaces. But, as a longtime Nix user, I can't help but worry about the future of the project. It hasn't looked good for quite a while, and that sucks. It sucks to see everyone involved with this awesome project get burnt and leave. I really wish I had a positive note to end this article on, but I'm just left with more questions than answers here. I guess that is the reason I'm writing this on my blog, though - the more people we get thinking about these questions, the more likely we are to find answers.

footnotes