Nix deserves great governance

Development
1

I believe the time has come for Nix to adopt formal project governance rooted in trusted open source principles, to ensure a safe, open, and community led future for the project. In the past, governance has been approached with skepticism: we wanted to avoid a heavy bureaucracy to keep the agility that comes from being a small project. We aren’t a small project anymore, though, and thoughtful governance can help us ensure everyone thrives as Nix continues to grow.

Roots of community

Every person who participates in the project wants something different from the experience. Perhaps it solves a problem they have; maybe they started a company and leverage Nix to pay the bills; maybe they were hired into a job that uses Nix; or maybe they are just trying to scratch an itch or to make friends. Regardless of the reason they are here - all these people are community members and are welcome to be a part of it.

As the size of our community grows, so too does the number of different reasons to participate. That naturally leads to conflict. Healthy communities do not shy away from that conflict - they are up-front with one another about their needs, and they work to more deeply understand everyone’s self-interest. They start from that shared understanding to collaborate together to advance the common good. They build a culture of mutual respect and understanding. They create rules and guidelines for decision-making and adjudicating the inevitable disagreements. They learn how to thrive together.

Governance models

We don’t need to invent our own governance model completely. Plenty of examples of successful governance models built on solid and proven open-source principles exist. In fact, the current board has met with lots of projects to learn about what is out there.

I’m a fan of the Apache Software Foundation (ASF), personally. If you haven’t read it, The Apache Way outlines their community-led process. I recommend you read it, but as a quick primer, which is paraphrased somewhat directly:

  • Earned Authority: the influence someone has is based on what they publicly contribute to the project, and it doesn’t matter who they work for.
  • Community of Peers: people don’t represent organizations. They’re just an individual. Their votes are equal, and everyone is a volunteer even if they’re paid to do the work. And to quote: “Domain expertise is appreciated; Benevolent Dictators For Life are disallowed.”
  • Open Communications: all code communication and project decisions are made in public, with transparent records. ASF uses email lists, but we could use Discourse. Note there are a very few exceptions: https://www.apache.org/dev/pmc.html#mailing-list-private.
  • Consensus Decision Making: generally working towards consensus, with a backup of voting when necessary.
  • Responsible Oversight: To quote: “Rather than detailed rules and hierarchical structures, ASF governance is principles-based”. This part gets in-depth. I recommend you read it.
  • Independence: “no organization is able to gain special privileges or control a project’s direction, irrespective of [employment]”.
  • Community Over Code: a focus on collaboration and teamwork.

But there are others we could look at: Debian and Fedora have a long and successful history of great governance. The broader open-source community has wrestled with these issues for a long time, and we would do well to start by understanding what they already have learned.

Bootstrapping a governance model

We have three different assets to leverage in bootstrapping Nix’s governance model: the foundation, the board, and the community.

The NixOS Foundation originally existed to collect money to maintain Hydra and the infrastructure that costs money to keep Nix and NixOS going. Over time, it grew to support projects more directly with NLNet grants.

The Foundation must mature to meet the demands of today. For example, its current work on trademarks and copyright. The Foundation should absolutely own the names “Nix” and “NixOS” and the logo. It should create clear rules about their proper use. Nix, the brand, means something to its users and contributors. It should belong to the foundation, in trust for the community.

The Board in its current shape came together in an impromptu Netherlands meeting space last spring. Representatives from several companies met and convinced the existing board it was time to change, and a new board was formed from some of those present as the governance entity for the foundation.

The Community, as it exists today, gathers around the project. It discusses the project, makes suggestions, merges patches, and discusses RFCs. What it doesn’t have is a way to speak to membership more directly or any kind of reasonable democratic process for making decisions about its future.

For Nix to be a community project, we need the governance to be community-first, “from the roots to the leaves.” We should use the Foundation and the existing Board to bootstrap a democratic, community-led governance model. One that takes everyone’s interest into account and ensures that Nix remains, forever, a work by and for its community. With elected leaders, trusted values, and clear guidelines for behavior. That process should cover the entirety of Nix - from our technical decisions to the Foundation’s own governance.

Community-oriented decision-making

At the root of our current problem: who among us is really empowered to choose? In the past, either the community came to a consensus, somebody “just did it”, Eelco chose, or the question died on the vine.

We would need to answer many questions. Who can vote? How do people gain the ability to vote? Where? How? This is certainly large and daunting but a solvable problem - the good work of the Apache Foundation, Debian, and others can serve as guideposts. We can leverage the Foundation, the Board, and the Community to make those decisions together.

Going slowly together

In any project, there are times to go slowly together and quickly alone. I feel it is time we go slowly for a minute. We need to have the conversation together as a community and be clear about how we want to leverage our assets to create great community governance.

This means outlining

  • what voting looks like.
  • what our board and teams look like today.
  • how and when we transition to a new, community-elected board.
  • how we continue to maintain our governance structure over time.

This would cost real money and real time, but if it gets us to a transparent, equitable, and, most importantly, community-driven governance model, then it should be worth it to all of us. Getting help from external and impartial experts might be a good idea to help ensure this happens in a timely manner. We will have conflicts along the way. We will navigate it by being honest and clear with each other about our needs. We can come together for the common good of Nix today and into the future.

Notes:

  • I was at the meeting in the Netherlands.
  • I do own Determinate Systems, Inc., a venture-backed startup working to increase commercial adoption of Nix. We’re still figuring out the details, and our initial work has been a focused and opinionated way to get new users and stakeholders started.
  • I am not on the NixOS Foundation board, but my cofounder Eelco Dolstra is the president. I am a board observer, which means I get to attend and talk at the meetings, but I have no vote.
44 Likes
2

I think the rest of the text somewhat downplays this point.

The intersecting subcommunities we have today all turn and interact around the projects. Yes, plural, Nixpkgs is not Nix, there are very observable splits.

The level of impact a person has is very strongly tied to the involvement in the projects. Right now we have one «wide» circle per project with a clear border — committers. And maybe we are converging towards this being a kind of a cut-off on measured involvement.

In a way, this is a much more «Earned Authority» structure than «voices are equal» part of «Community of Peers».

And we already have «you are not even a true part of the community» arguments (… as if it were a community, singular) appear from time to time.

As far as I can tell, trying to learn from Debian’s experience is of course valuable, trying to follow them requires a 900° degree course change (well, maybe even more spinning in place before the turn-around).

You say «work slowly together».

Slow down here. Please.

This presupposes A Community. Singular, and an entity. Preferably with visible bounds.

But what is there, and what is given, there are projects.

I am not sure we should even say there is a single community. I am sure before even considering a discussion of what voting looks like we need a frank discussion who is even going to be represented by all this.

15 Likes
3

I like the initiative of starting a discussion about this, I fully agree that governance in the community is a weak point we should consider improving.

Firstly though, I want to say that you @grahamc are in a bit of a weird spot right now:

  • You’re the owner of Determinate Systems, which recently published Zero to Nix, prompting the doc team member @domenkozar to leave the team, and the previous doc team lead @lucperkins (also from Determinate Systems) to step down from the team too. For unrelated reasons another member @Mic92 also left the team at around the same time, leaving only me and @fricklerhandwerk in the team. While discouraging, we’re now building up the team again. Adding to that, I’m not impressed by the most recent (though first ever) Board statement trying to reconcile these events, especially given that you should’ve had insight into that post beforehand, since:
  • You’re also a NixOS Foundation board observer, therefore being able to participate in the Foundation Board meetings and having an influence on their decisions. However it seems like you didn’t inform the board about this post, which I discovered after talking to some board members. Therefore this initiative could be seen as you trying to take a leading part of such a new governance to replace the current Foundation board.

Whether that’s your intention or not, I don’t think the Foundation board needs to be replaced or changed, but we should reinforce where the Foundation fits:

  • The Foundation is there for administrative tasks like trademarks, finances, events, legal matters, copyrights, etc. There’s no need to decide Foundation board members using community votes, because this doesn’t influence the community.
  • The community governance structure in turn should hold authority, delegate permissions and make decisions over the homepage, repositories and community channels. It should work together with the Foundation when necessary. This structure is where we can benefit from the community voting on members, since it directly impacts the community.

But no matter the current events and your position, I fully agree with the idea that we need to improve governance. In that regard I think we should be more concrete about what existing problems we’re actually trying to solve, I’d like to mention these points:

  • Bluntly, @edolstra being the BDFL of Nix. While this has improved somewhat for the Nix codebase with the recent formation of the Nix team, I don’t think that’s the end of the story, there’s more than just the Nix codebase that @edolstra still holds absolute authority over, and there’s no path for others to take over. I appreciate @grahamc’s explicit mention of BDFL’s being disallowed in ASF’s model, despite Determinate Systems employing @edolstra.
  • Teams not truly owning the parts they’re trying to work on. For example the documentation team (which I’m part of) has barely any authority over Nixpkgs, NixOS and Nix documentation. It only has authority only over the on-its-way-to-be-official https://nix.dev/ (generously donated by @domenkozar!). Similarly the Nixpkgs Architecture Team (which I’m also part of) not having authority over the Nixpkgs architecture. Currently the RFC process is used instead, which somehow works (RFC 140 is going, needs shepherds though!), but it’s really slow and takes a lot of time.
  • No flow to give or take away permissions. The best thing right now is this Nixpkgs issue used for people to request commit access to Nixpkgs, and @domenkozar occasionally going through it and giving the bits. On the other hand, while there’s an RFC to remove inactive people again, I don’t think it’s been implemented yet. These processes barely work, but this is just Nixpkgs, there’s a lot more parts of the ecosystem.

Currently this is only a discussion though, to actually make this a reality a lot more is needed. I’m not sure if you had any plans for this already, but if not I’d like to start an open working group to discuss and work on this issue.

38 Likes
4

It was recently enacted here: Retire committers who haven't contributed since 2022-01-01 (RFC55) · Issue #216177 · NixOS/nixpkgs · GitHub

5 Likes
5

Very much so.

And even more so: Nix* has no need for great governance. We need governance making and implementing reliably reasonable decisions. Even better if these would be great decisions, at least from time to time.

So I fully agree that we need to know which kind of decisions on what topics we need to make. (And connecting to my point — in whose name / in the interests of what constituency).

6 Likes
6

I agree with what @infinisil said and would merely like to add: I’m not convinced that either Debian or Apache have effective technical leadership structures for TYOOL 2023. Debian, I mostly know for fights in the archive as a failure of process. It feels like a bunch of little fiefdoms of various different packages’ maintenance; likewise in Linux with subsystem maintenance.

Having one person as the gatekeeper for some area is quite troublesome because it leads to decision making bottlenecks and a lack of shared ownership/fear to change things to avoid criticism. In a better system, everything should be collectively owned by the community: everyone should feel empowered to make changes.

I think that if we want to talk about technical leadership structures, which is where I see the most difficulties in Nix, looking at the Rust project might be a better choice. There, too, the foundation (an entity not without criticism!) has no power in running the project and is there purely to support. There’s teams that each collectively own different parts of the project, and the “core team” is increasingly becoming deprecated in favour of decentralization of control (see recent activity regarding this: Add RFC on governance, establishing the Leadership Council by sophiajt · Pull Request #3392 · rust-lang/rfcs · GitHub).

10 Likes
7

TL;DR

All what matters is

  • if we talk about rules talk also about enforcement
  • if we talk about organs talk about about aditors
  • if we talk about community lets talk about how to become part of it
    • what is story for getting started with technology
    • what is a process of participating in community

The Flame

For what it’s worth I think talking about any sort of rule is worthless unless there is a clear will and plan how to enforce it. For instance:

The Foundation should absolutely own the names “Nix” and “NixOS” and the logo. It should create clear rules about their proper use. Nix, the brand, means something to its users and contributors. It should belong to the foundation, in trust for the community.

is foundation willing to enforce any of this? How?

I don’t have a slightest problem with foundation working on this if and only if the way this will be enforced is sensible.

What I feel are the most problematic issues community/project is currently facing are questions of on-boarding and management of contributors and documentation. When it comes to foundation I think the primary challenge there would be to maintain economic and legal independence from individual employers.

Personally what I would expect is:

  1. There should be absolute base line agreement everyone joining in any capacity should agree to. Nothing too politically polarizing but clearly enforcing equality. Just remember there are people of various political and other backgrounds and this document should fore most be inclusive. So this should be crafted with great care but also ensure all parties must agree to at least baseline rights of others.
  2. There should be better path to get new people in. Based on network of trust and under the rules by 1st point. Gatekeeping is root of many evils but so is protectionism. Just because I landed job at A doesn’t mean I will be committer but neither it should prevent it. Perhaps we don’t need hard rules as much as guiding principles we all agree to as part of 1
  3. People have right to do things and therefore decide. Documentation team should be able to decide the things that needs to be done internally and then work towards that. So could other teams.
  4. Any organ in power (being able to decide the direction) could be democratically vetted by community. If one member of some team feels it’s heading in the wrong direction they can then gather popular support to enforce reevaluation of decisions made there. No matter if it’s ill intent, mistake or incompatibility of goals.
  5. Every role that gives person right to manage any resource - fiances from contributions, enforce trademarks, approve or remove maintainers should have impartial auditor. Impartial should be defined in 1. but it could for instance even be to not be employed by the same company. Auditor doesn’t need to approve things. They just can raise alarm and enforce community vote on the issue.

This is nothing groundbreaking. Any sensible organization is based on similar guiding principles. The biggest challenge in FOSS communities is actually the 2nd. It’s hard to draw the clear line between member and non member. You become citizen by simply being born somewhere to someone. You become union member by applying and then being accepted as a member. So I think any type of governance plan proposal is most definitely undemocratic unless it concerns itself with this question as a pre-requirement. Community means nothing unless you define it - what it is and what rights it has. Once we have that the rest is easy.

4 Likes
8

I’ll probably write a more extensive comment when I’ve recovered from being sick, but there is one specific point that I want to address here right away.

This sounds an awful lot like a repackaged form of ‘meritocracy’ (in the sense that that term is generally interpreted within FOSS circles), with all of the issues that come with it. Such governance schemes frequently put marginalized folks at a disadvantage and, in the context of “regardless who they work for”, invites commercial conflicts of interest.

The ASF, too, is not a stranger to this issue - the issues of cultural appropriation with their branding have as of yet gone unresolved, for example.

The fundamental problem here is that this idea is based on the all-too-common assumption that FOSS is a level playing field, where everybody has equal opportunities, and so contributions are a good proxy for whether one has useful ideas. This is false.

In reality, privileged contributors are often in a significantly better financial situation, allowing them to contribute more unpaid work than marginalized people, generally from the same shared demographic. This grants them outsized influence over the project, whereas marginalized people who already have difficulty getting involved with the project would have their voices drowned in, to not beat around the bush, the opinions of well-paid overconfident white dudes.

A similar issue exists with treating companies as neutral parties who have no effect on contributors’ contributions; the fact that these companies can directly fund work on the project gives them outsized influence over the project - because it means that whoever they are funding will have more contributions, and therefore more influence, and an income to lose if they steer too far off their benefactors’ preference.

On top of this, even if opportunities were equal, a large amount of contributions does not mean that one has good ideas, or the interests of the community at heart, or the skills necessary for effective project governance. Toxic influencers are a typical example of this problem.

In short: I am strongly opposed to any model that directly ties influence over project governance to ‘measured contributions’ or financial ability (including by proxy), and am of the opinion that if NixOS as a project truly wishes to put the community first, it will have to actually do the corresponding work to get there - by detaching funding from governance, and where possible actively (financially) supporting marginalized contributors who cannot afford to do so in their spare time.

Edit: see also the various web standards bodies, to get an idea of what happens when governance access (explicitly or implicitly) becomes gated by having a commercial benefactor.

24 Likes
9

I trust in the constituency of the Teams.

And in a Board that helps them thrive.

My only vote.

1 Like
10

Oh yes… when talking to colleagues about NixOS, I’ve been made aware repeatedly that nixos dot com is a pornography site. Which is fine in itself, but it confuses people and spreads the image of NixOS not being in control of its brand.

10 Likes
11

I’ve been pondering if the “community” is actually in a position to do anything about this, if it came to some sort of conclusion. The burden here really isn’t on the community. Will the “board of competitors” (as I like to call the foundation board) actually open up in such situation? Are they even listening? Are they interested in these discussions? Do they read this?

5 Likes
12

Yes, thanks for reminding me. As a board observer, I created this ticket Reflect on "Nix deserves great governance" · Issue #41 · NixOS/foundation · GitHub. We had an internal conversation about it. Unfortunately, Graham wasn’t available at that time and the subject hasn’t been raised since. At the time we were also all a bit tapped out by the related conflict of interest. Overall the sentiment is that we were interested in finding ways to rotate the board members, but we also have a lot of practical things to put into place and it would be distracting.

Probably a good place to start would be to define what the community exactly is. What are the conditions to get in, and what are the conditions to get out? Do we have a single level or multiple levels? What does the voting system look like? What voting infrastructure do we need to deploy? It would also be nice to test it out on the RFC system. I believe that some RFCs would benefit from that, and it would help us test the maturity of the system. This would also help reduce some of the outsized influence that people with free/paid time currently have (as joepie91 noted), as you would be able to draft an RFC on your own, and then submit it for voting without going through the current lengthy vetting process.

One thing to take into consideration is that changing the registration of board members is also more expensive than an API call as it requires updating the founding document with the Netherland state. That’s why my thinking is that the foundation could mostly be an administrative body. It’s a vessel that interacts with the admin/commercial world. Most of the things that are happening are things like getting the trademark, filing to get VATMOSS registered, transferring the domains so they are held by the foundation, getting in contact with various sponsors and commercial entities, … And then building mechanisms so that the board is in service to the community. We already agree that the foundation should not lead the technical direction of the project as this should be delegated to the teams.

Anyways, that’s some of my views. There is much more to say about the big picture but I’m running out of time for today.

20 Likes