Around when RFC 140 was accepted, participation in the Nixpkgs Architecture Team (NAT) fell to a lower level, where the “Team” format was not working out anymore.
As the team lead I’ve thus decided to officially dissolve the team.
This sound more dramatic than it really is though, because not much will actually change. In this post I’ll go over how it has come to this, what to learn from it, and future plans to look out for.
History
Out of frustration with various architectural problems in Nixpkgs I created the NAT in July 2022 and subsequently got some members to join me. We started having weekly meetings, all recorded and with meeting notes. Asynchronous discussions were being held on Matrix, with a separate GitHub organisation for more persistency.
After an initial period of various brainstorming discussions, we started focusing on fixing a single problem, which is now known as pkgs/by-name, established by RFC 140. While very slow and tedious both before, during and after the RFC, I’m happy to say that this has been a definite success. It’s not done yet, I’m continuing to work on it, but expect it to be done Soon™. If you’re interested about more technical details, I gave a presentation about this last NixCon.
Unfortunately some time along the way the team meetings started falling apart. Around the time of the RFC, we were struggling to find much to discuss in the weekly meetings, they often just turned into me monologuing what I’ve been working on. Because of that, the meetings were at first reduced to just 30 minutes, then made bi-weekly, and then just once every 4 weeks. The intention was to schedule longer in-depth discussion meetings when necessary, though that never really happened. And with meetings 4 weeks apart, it’s easy to forget about it, and a single absence now meant a two month period without synchronisation.
I’ve also grown increasingly grumpy as a team lead, since I’ve been doing the vast majority of the work:
- I administered the team effectively by myself: Leading every meeting, taking almost all meeting notes, pinging people in advance to join, keeping team information up-to-date, etc. Attempts to delegate such tasks have failed for various reasons.
- I wrote RFC 140 mostly by myself, with only @roberth helping out a bunch (appreciated!). While the RFC was discussed in meetings and on Matrix, actually putting these discussions in concrete writing was left mostly to me.
- I’m implementing the RFC entirely by myself, without much feedback in PRs. This is at least partially due to it being a lot of Rust and not Nix code. Only since recently I’ve gotten some very thorough reviews by @PhilipTaron (appreciated!).
Of course I can’t expect anybody else to actually do anything since I’m not paying anybody. I’m in the lucky position to be sponsored for this (thanks Tweag and Antithesis!), but this is rare. In the end, this just didn’t feel like a team at all anymore and made it hard to stay motivated.
Challenges
Lack of authority
A core problem from the start has always been the lack of authority: The team used the community-based RFC process to enact changes and had no concrete ownership of Nixpkgs’ architecture, despite the name. Considering that there are over 200 Nixpkgs committers without a dedicated owner, this seemed like the best way to make substantial progress. And while this works, it’s very slow and tedious. While it’s very beneficial to write down decisions and involve the community in that way, at some point somebody should just be empowered to make decisions.
Lack of resources
As in almost every corner of Nix, there’s a shortage of resources. This is especially problematic for Nixpkgs’ architecture, which is notoriously hard to change due to the scale of Nixpkgs, with over a thousand PRs being merged every week. The vast majority of which add and maintain packages, making heavy use of the architecture. This effort is largely problem-oriented, where people do the work to solve their own problem, but don’t have the time and knowledge to do more. To make any significant changes, somebody with these resources needs to take the initiative and push it through. While admirable, we cannot expect people to undertake such efforts for free and should instead hope for this to be sponsored.
Plan
The following will continue to exist:
- The public Nixpkgs Architecture Matrix room for ephemeral discussions
- The Nixpkgs Architecture Discourse category for more persistent discussions
In the following weeks I will do these changes to dissolve the team:
- Remove the NAT from nixos.org
- Move all Nixpkgs Architecture issues into Nixpkgs
- These will be labeled with a new “architecture” label, which will also be applicable to many other Nixpkgs issues
- Publicly archive the private Nixpkgs Architecture Matrix channel
- This was used very sparingly and contains no sensitive information that couldn’t be shared
- Archive the Nixpkgs Architecture GitHub organisation
- Retire the Nixpkgs Architecture YouTube channel
- I’ll only keep it around for archival purposes
- Remove future NAT meetings from the NixOS calendar
Prospects
To work towards improving the authority situation, I wrote an open Nix organisation draft proposal, which is being experimented with by @zimbatm and me. This wouldn’t directly fix such problems, but rather create a place to discuss and propose changes to it. Feel free to discuss this idea by opening issues/PRs or in the Nix Platform Governance Matrix room.
Not having the burden of trying to manage this team structure anymore allows me to focus more on actual work. I fully intend to both finish the implementation of RFC 140 (see this milestone for the status), and continue to work on Nixpkgs’ architecture after that.
Furthermore I’ll start holding a weekly personal office hour, where anybody can come talk to me about anything relating to Nixpkgs’ architecture, but preferably with a focus on what I’m working on at the moment. I haven’t decided a time yet, but if you’re interested you can enter your availability here:
?
.
