Lessons from Rust

Meta NixOS Foundation
1

In the light of NixOS Foundation board: Giving power to the community, it might be worth re-visiting the recent history of power transition in the Rust programming language community. The result of that transition is the following document:

It is perhaps a worthwhile, if long, read for anyone interested in designing similar structures for NixOS.

Some notes from me:

  • Rust relies heavily on independent small autonomous teams with authority. In my reading, this is very different from Nix, where there are teams, but they generally donā€™t have a lot of power to just go and do things. While Rust builds consensus within a team, nix builds community-wide consensus.
  • Teams were the seed for constitutional assembly. Semi-arbitrary, the leads of top-level teams were designated as such.
  • The benefit there was legitimacy: given that Rust is a federation of teams, everyone felt its fair if all teamleads together decide what to do next.
  • The drawback was that the result group of people turned out to be pretty large, and not really focused on solving governance issues. As a result, it took more than a year and a second crisis to go from ā€œwe have constitutional assemblyā€ to ā€œwe have a proposal for governanceā€
19 Likes
2

From what Iā€™ve heard, grievances about leadership were not foreign to the Rust project, even after this RFC.

3

Good thing is that Rust isnā€™t dying, obviously :slightly_smiling_face:

3 Likes
4

Thanks for sharing this! Itā€™s quite similar to one of the models Iā€™ve read into quite a bit.
I also believe that this format allows the community to keep scaling sustainably as long as those teams and leads are sufficiently empowered to act/take action and unblock.

5

Another interesting property is resilience: while the top-level structure of Rust governance was historically quiet unstable and not always functioning satisfactory (hence the abovelinked overhaul), the underlying engineering was steadily moving forward, thanks to the fact that each team can successfully execute autonomously.

One specific reason for this resilience is that formal power to decide is separated from actual power to change things. All private keys, passwords, etc are owned by the infra team, which manages various accesses, but doesnā€™t itself decide who needs to access what.

1 Like
6

I donā€™t want to wade into this, but there are important differences between Rust and nixpkgs:

  • Rust has clearly defined interfaces between teams which change slowly if at all.

    • :white_check_mark: the language specification is mostly a matter of spelling things out.
    • :x: nixpkgs doesnā€™t even have type declarations for things like stdenv, let alone any sort of specification or hope for one. Iā€™m not sure it really could.

  • Rustā€™s teams can do most of their work while ā€œstaying in their own laneā€.

    • :white_check_mark: There is no reason for somebody working on cargo to need to change the borrow checker.
    • :x: The people who keep darwin and riscv/mips/ppc working need the ability to touch every package.[^1]

  • There is a clear upstream/downstream relationship between all four technical teams.

    • :white_check_mark: language < compiler < libraries < devtools
      • maybe a weak back-edge from a few libraries to the compiler.
    • :x: nixpkgs is a big huge fixpoint ā€“ a source of both pain and power.

You could adopt a Rust model making nixpkgs one monolithic team, but since 99% of the community spends 99% of their time working on nixpkgs this doesnā€™t really move the needle.

[1]: Iā€™d like to acknowledge @reckenrode as a great example of somebody who does this respectfully and carefully, avoids creating maintenance externalities, and makes sure he understands things before changing them. (I donā€™t think that providing counterexamples would be helpful so I wonā€™t do that).

7 Likes
7

@amjoseph I agree with your assessment fwiw. I do think it will help this community to look at and discuss other models. But I donā€™t think we should try to just adopt those other models. I think weā€™d be better off having the model for nixpkgs rationalized and structured by the people doing the work in nixpkgs, Nixos, and Nix, who will need to live with the outcome.

1 Like
8

Iā€™d say this is the smaller difference. The bigger difference is that Rust teams were always there, and the governance structure is grown around teams, rather then the teams being sprung into existence through change in governance.

Thereā€™s a very strong path-dependency, as teams are self-selected. That is, the current set of people on the teams was picked by the previous set of people on the teams. I donā€™t think itā€™s easy to create cohesive teams by fiat.

My interpretation is that, while there is, e.g., a nix team right now, it had a troubled start (it is the second nix team), and doesnā€™t quiet execute with full efficiency yet (the flakes issue is not resolved one way or another)

2 Likes