Nix team creation


Nix is the cornerstone of the ecosystem, but Nix itself is still mostly developed as if it were one-man project with some occasional contributors.
This model doesn’t fit the reality anymore1.

Having only one acknowledged maintainer has a lot of practical downsides. In particular:

  • A lot of knowledge about the codebase and its future stays implicit, making the codebase harder to approach, and leading to all sorts of misunderstandings with the broader community of users and developers
  • The response time suffers a lot. Some simple pull requests can linger without any formal approval or rejection for months (or even forever).
  • Because of the other reasons, potential contributors are discouraged, meaning that a lot of potential work and expertise is wasted.

To remedy these issues, we need to distribute the task of maintaining the Nix package manager to a team of people.

This was already tried in the past with NixOS/rfcs#25. This experiment was canceled because its scope was too wide (overlapping with the RFC process in particular) and it didn’t yield sufficient results.
It also suffered from the fact that most team members weren’t familiar enough with the codebase and were already overwhelmed with other responsibilities.

Introducing the Nix team

We announce the creation of the Nix team.


The Nix team shall take ownership of the Nix source code:
owners are accountable for deciding on changes, commit sufficient time and have the authority to make them happen.

This includes, but isn’t limited to:

  • Establish, communicate, and maintain a technical roadmap
  • Enable contributors
  • Ensure capacity for reviewing PRs and addressing issues
  • Define and assert quality criteria for contributions
  • Keep code healthy, documentation up to date
  • Manage the release lifecycle
  • Regularly publish reports on work done
  • Engage with third parties in the interest of the project

Composition of the team

The initial team members are:

Team members are expected to commit a sufficient amount of time to work for the team. This implies in particular:

  • Being present at the regular team meetings (or excused)
  • Taking time between the meetings to work on tasks

Details on the process of joining or leaving the team will follow.


The primary communication channels for the team are

The team holds a weekly meeting every Friday at 11:00 AM12:00 PM.
Agendas and meeting notes will be posted on Discourse.

1: Over the single month of November 2021, the repository received more than 120 pull requests by more than 40 different people. More broadly, some contributors did some big refactorings on specific parts of the code base, and are arguably as much if not more knowledgeable than the maintainer about these.


@peti @shlevy @vcunat @grahamc since you were involved in the 2018-2019 Nix Core Team, could you please share your experience and insights in running that team? Specifically, could you elaborate on why you think the team did not achieve its original goals? That would provide valuable guidance for the new team, and hopefully help it to operate effectively.

Hmm, I’m not sure. In my case I didn’t end up giving it much time; I should’ve thought better about that in advance.

Almost none of my work around can be justified in context of my “paid job”, so diving into nix could only be done by cannibalizing my work on nixpkgs. That was clear in advance, but in the end it felt much harder to abandon than I expected.

Hosted by Flying Circus.