NixCon Governance Workshop

Announcements
1

Following recent community discussion about challenges in the Nix ecosystem, a room was opened on the Matrix to gather comments and organize decision-making.

Two meetings in the past few weeks, with several questions and ideas shared; notes available here:

The first outcome of this effort is a planned workshop during this year’s NixCon, to explore topics around Nix governance, particularly concerning addressing existing pain-points and ensuring sustainable long-term operations.

The workshop will be spread out, with sessions held from 13:30 to 14:15 on the days of the conference, and a longer session starting at 08:30 in the morning on the hackday.

7 Likes
2 
@fricklerhandwerk: How to involve people not at NixCon?

    @infinisil: Goal is not to make decisions there, only initiate the conversation
    @domen: It’s very efficient to make decisions when together, have to cut the line at some point
    @infinisil: Do-ocracy again, people helping out with making governance work
    @zimbatm: Can experiment with changes too

I’d encourage the group to explore ways for community input into both these changes and moving forward. There are a number of reasons people can’t make it to NixCon, and that doesn’t negate their interest in helping with governance or providing input into the future of the ecosystem.

Also I would challenge the sentiment from these notes that just because someone is willing or able to “do” work, it’s necessarily the best thing for them to spend their time on. In many cases it may be, but this do-ocracy idea seems it could also be at odds with improvements in governance and community decision making.

4 Likes
3

I won’t be at NixCon (across the ocean, third week of classes), but I did want to float one potential discussion point that’s fresh in my mind. In RFC101 (Nix formatting), I’ve noticed that we struggle with the minutiae of technical details in the RFC process. This specific RFC, because of the subject matter, lends towards incredible amounts of bike shedding that will ultimately stall the RFC indefinitely. Some of the most recent discussions are asking the questions of if we can use the RFC to delegate responsibility and decision making of those details to the group who will maintain the formatting tool, and how that would work in practice. As a community can we find the right balance of delegation and accountability to allow such a critically important tool to move forward into the ecosystem?

3 Likes
4

I’d encourage the group to explore ways for community input into both these changes and moving forward. There are a number of reasons people can’t make it to NixCon, and that doesn’t negate their interest in helping with governance or providing input into the future of the ecosystem.

Indeed. We’re a globally-distributed project with nearly all work done online, but somehow there’s still seems to be a quite widespread belief* that in-person collaboration is more effective. I don’t share that view, but in case it is true, more effort should be dedicated to improving the online workflows where we spend the majority of the working time. Whatever results from this will have powerful impacts on contribution activity, and on the sustainability of the project as a whole.

In any case, it’s an accessibility problem in several ways (physical ability to travel, visa concerns, financial costs, scheduling), as well as having significant ecological impacts.

(*This echoes a similar sentiment held by many in the wider software industry and elsewhere, which, while usually benign on an individual level, only serves narratives that ignore or downplay multiple ongoing global public health crises. It’s worth considering who benefits from this, how, and at what/whose expense.)

Also I would challenge the sentiment from these notes that just because someone is willing or able to “do” work, it’s necessarily the best thing for them to spend their time on. In many cases it may be, but this do-ocracy idea seems it could also be at odds with improvements in governance and community decision making.

I agree here too; the spirit of praxicracy is great for day-to-day operations, because things tend to just get done rather than languish under committee review, but this can sometimes be a bit like launching a rocket before computing its intended trajectory – it will probably fly, but course-correction is expensive, often difficult, and there are limited chances to get it right.

Part of the motivation behind the push for better governance is the realization that the projects are evolving without much (documented, discussed, evaluated) high-level cohesive vision, which is not an unexpected outcome of do-first maximalism.

The good news: we can do better, we’re trying to do better, and more people are engaged than ever!

4 Likes
5

Posting the meeting notes here for posterity.

Nix Platform Governance Workshop Preparation Meeting #1

Date: 2023-08-23
Participants: @raitobezarius, @infinisil, @zimbatm, @lheckemann (mainly listening), @tomberek, @ron, @fricklerhandwerk (later)
Notes: @infinisil

Agenda

  • @zimbatm: what are top 3 action points we can gather from Where did you get stuck in the Nix ecosystem? Tell me your story ?
    • @infinisil: Issues like that should resolve itself if we fix the more fundamental problems of governance, we should start at the root
  • @raitobezarius: focusing on ensuring complete redundancy of access to community, especially towards unblocking community members in the future.
  • @fricklerhandwerk: ensure all vital functions are staffed and funded, and the ones responsible have authority over their domain and can be held accountable
  • @ron: Prioritize items to maximize focus and chance for progress during the few hours we have together on this
    • define goals for the session - ideally actionable outcome even if it’s small at first

Organization

  • Who leads the workshop? Who takes notes?
  • When does it happen? On which days and times? Nixcon time plan?
    • Split up across 2/3 days, good to process information overnight
    • Do it during beginner talks?
    • Could do it partly during lunch (there’s a longer break), maximum taking up time from one talk
    • On hackday before the hacking starts in the morning
    • Decision: 13:30 - ~14:15 on the conference days, morning on the hackday longer (08:30am)
  • Should it be publicly streamed or be private?
    • Decision: Not streamed/recorded
  • How will it be advertised publicly? What’s the description @zimbatm submitted to the NixCon proposal? (@ron: It’s currently a proposal that we can add as an agenda item if we’d like)
    • Decision:
      • Let’s write down who will be there in the meeting, people can challenge/ask if they don’t feel represented
      • Include a description for each person joining, affiliation
      • Witnesses allowed, but limited
    • Witnesses could take notes
  • How do we make sure all the people that should be there are actually there (if there at Nixcon) and participating in the discussion?
    • We can bunch them together there?
    • PM them ahead of time, confirm individually
    • 1 person per “component”, don’t have too many representatives of the same part
    • Diverse viewpoints
    • Whose viewpoint could be missed?
    • The people doing a lot in the community should be there
    • Team leads
    • Potentially missing:
      • New-comers to Nix
        • They don’t know enough about Nix to know the context
        • Not important for now
      • Genders diversity
      • People burned out from Nix
      • People that aren’t involved but have an interest, aka silent users
        • They might not be silent on forums, but not investing a lot of time
      • The people we don’t know, isn’t in the circle (yet)
    • Could write down these missing viewpoints in the public announcement
    • Even if we can’t represent them, we should keep them in mind
    • @fricklerhandwerk: Who to invite? What about people not there?
      • I have a list of the most frequent contributors, could publish it
      • @raitobezarius: Only active people (we don’t want to ping burnt-out people)
    • Decision: Mention that people are welcome to fill gaps in viewpoints
  • How to we ensure that the effort continues async/remotely past NixCon?
    • @fricklerhandwerk: can pick up the subject in the Zurich workshop, date is already known
      • (general disagreement on this idea, that would be too localized)
    • Continue online
    • Could have changing themes, invite different people depending on that
    • People often just want to be heard
    • @raitobezarius: Publicly address common concerns of people.
    • Collect concerns of people, then publicly write how it’s getting addressed
    • Listen, don’t let people write into the void
    • @infinisil: To continue, just offline, same structure as NixCon
    • @zimbatm: Idea: People come up with proposals that will be discussed.
      • Could be governance proposals too
      • Board of people with permissions
    • @ron: make sure it’s on our agenda to put a structure/plan for how this proceeds async/remotely

Next steps

  • anything to address right now?
    • @raitobezarius: We can’t talk about everything in these meetings
    • There are a lot of permissions that are difficult to unlock
    • We should unlock all permissions held by single people
    • Is access shared between people?
    • proposal: shared accesses to critical resources
    • proposal: establish team lead responsibilities
    • proposal: Allow people to point out where they’re blocked on permissions, then we can implement that
    • @zimbatm has root access to a lot of things, is willing to hand out permissions
    • @zimbatm can ask @edolstra/@grahamc/others for permissions

Next Meeting

  • 15:00 CEST 2023-08-31, @infinisil will send invites

Async tasks

  • @infinisil will send invites for the next meeting
  • @zimbatm sketch public address, send it for review to the Matrix channel
    • Will includes who will be there and what they’re representing
    • Send the draft early, then we can all help out
  • @raitobezarius ensure that we have a place for it, and how much space
    • @ron: Ideally circle arrangement
  • @raitobezarius/@ron: Guarantee the schedule
  • @fricklerhandwerk: Share list of most active contributors
2 Likes
6

Nix Platform Governance Workshop Preparation Meeting #2

Date: 2023-08-31
Notes: @infinisil
Participants:

Agenda

Notes on the Governance Track proposal

  • @zimbatm: main concern is how to get people a voice who’d have trouble speaking up in a hectic situation
  • @infinisil: currently first item is flakes, but don’t think it’s productive to discuss it
  • @zimbatm: Not how to stabilise it, only why not stable
    • @fricklerhandwerk: Could propose a statement about status-quo and agree on it
    • Could start off with Flakes — nix.dev documentation
    • The Nix team is considering a flakes milestone list: Start a Flakes milestone list · Issue #8870 · NixOS/nix · GitHub
    • @infinisil: Flakes doesn’t seem very productive to discuss with everyone there
    • @asymmetric: How to solve underlying causes?
    • @infinisil: Figuring out how to make large decisions in the Nix Platform and over what decisions can be made
    • @zimbatm: Idea of RFCs or something else needed
    • @fricklerhandwerk: Community teams should be empowered; provide structure
    • @raitobezarius: What is the objective of the Nix maintenance team. E.g. what if somebody creates a Flakes v2, how to propose such changes. Can we make decisions when the Nix team doesn’t entirely agree with it?
      • @fricklerhandwerk: @edolstra said in the beginning that even if the community thinks something should be done, it won’t necessarily be implemented. These things should be discussed with the Nix team directly.
      • @thufschmitt: Can the Nix team deny community decisions? RFC process? We shouldn’t be the single decision maker, but also be able to reject some ideas, shouldn’t be gate-keepers. Balance is needed, there is some tension of interests that we’re aware of
      • @domenkozar: How to make experiments in Nix? Even if there’s good intensions, can lead to problems. Define process for introducing backwards-incompatible changes.
        • Usually some company or other independent entity will present something and say that many people are using it
        • @infinisil: Have some ideas on this, and we could discuss it.
      • @domenkozar: I my opinion, in open source, features don’t get removed, hard to reverse things
    • @ron: Two macro things:
      • Towards praxicracy/do-ocracy, unblocking people that do work
      • How to do more complex decision-making
    • @ron: Process in both directions, unofficial ↔ official
      • @fricklerhandwerk: Yes, have to establish and maintain resource and priorities hygene
    • @zimbatm: How to create a culture that gets things done, how to structure things, technically too
    • @ron: Do-ocracy of empowering the community to get things done; what to do when the community can’t proceed on something, needs a decision
      • @fricklerhandwerk: Small decision making can be solved by allocating resources. Funding people. We don’t have such a structure right now, no global coherent vision.
    • @asymmetric: Clear examples of what problems to address. For each pain point, how what we do will help with those.
    • @raitobezarius: Dealing with Nixpkgs daily, CI is a mess, Darwin machines are weak, few Darwin experts. A lot of Nix contributor problems, weak security structure. Infra team problems, no email addresses. A lot of problems. Generally, no strategic views.
    • @tomberek: Proposal regarding allocation of resources, how to empower teams: Allocated budget for teams. Makes teams accountable. Clearer responsibility.
    • @infinisil: One problem I see that many things in Nixpkgs need a lot of experience to deal with. Still struggling with many things myself. Throwing money at things alone won’t help.
      • @tomberek: Handing out money anyway would make some things possible regardless
      • @infinisil: Agreed, might work well
      • @fricklerhandwerk: Agreed, Need to attract more experts and a diverse skill set into the community.
    • @tomberek:
      WHEREAS, Things need to get done
WHEREAS, empower people
WHEREAS, distribute decision making
WHEREAS, need stable allocation of resources
THEREFORE BE IT ENACTED that the Board allocate a budget for each official team to be managed by the team lead.
    • @fricklerhandwerk: Who will make the strategic decisions? For now whoever happens to collect money (or spend their own time) and put it somewhere can decide things
      • With some important exceptions that need influence and permissions
    • @infinisil: Good to discuss as a proposal at NixCon
  • @ron: What can we make the most progress on? Recap:
    • Macro item: Empowering decision-making, maximise praxicracy
      • @fricklerhandwerk: Who would be empowered for decision-making? We have trusted community members, so far they appeared organically. Putting money into the game will change the dynamics.
    • Creating structure and having a process for making larger decisions
    • Budget, accountability, allocating resources, formalising resources
  • @zimbatm: Large PRs don’t get merged, people burn out
  • @domenkozar: How to incentivise companies to help out the official project? What can people and organisations contribute, what can they get back?
  • @fricklerhandwerk: How to involve people not at NixCon?
    • @infinisil: Goal is not to make decisions there, only initiate the conversation
    • @domen: It’s very efficient to make decisions when together, have to cut the line at some point
    • @infinisil: Do-ocracy again, people helping out with making governance work
    • @zimbatm: Can experiment with changes too

Action items

  • Share discussion topics in the channel to prioritise what to talk about at NixCon
  • Pick top three topics to be prepare a pre-read by two people (lead and support)
4 Likes
7

Nix Governance Workshop Nixcon 2023

Time: Monday 2023-09-08 13:30
Notes: @infinisil
Lead: @zimbatm @RaitoBezarius
Participants: Lots in a chair circle, maybe ~30

Note:

  • We also have today and tomorrow, but let’s hack more on following days
  • Let’s keep arguments short

Line between community and companies

Domen Kozar:

  • Nix has been very community oriented before commercial entities came in
  • Still in the process on how to integrate these entities, which boundaries
  • I’d like companies to work together on projects
  • Questions:
    • How can the community keep thriving
    • How do companies feel welcome?
    • Where’s the line between officially endorsed projects
  • @graham: Don’t see a line between community and companies.
    • Companies need to make money, but everybody in the community has goals
    • Where’s the line between different goals, why such a dichotomy
    • Matthias: Makes sense to look at them differently, different mechanism
    • Public funding is notably different
    • (anon): We have the overall community which includes companies, but we shouldn’t underestimate the differences. E.g. the Rust foundation has been taken over by Amazon. It’s a spectrum
    • Guillaume: Not sure what the concerns are yet
    • Ron: Short term agree with Graham, everybody is based on Nix.
    • Are we okay taking a lot of support from Amazon
    • @alyssais: On an individual level, each contributor, everybody has their own motivation.
    • Danger is in grouping, if we take all companies invested into Nix, those different groups have distinct motivations.
    • E.g. when we make decisions about who should sponsor Nixcon, interests will differ between companies and individuals. Companies want a ROI.
    • Companies have a lot of resources, feeling like taking on a lot of decision making because of that.
    • E.g. foundation doesn’t have any individuals on it.
    • If we leave this unchecked, it’s easy to corporate ?? by accident.
    • Majority of work is still volunteer work.
    • Need to make sure all the contributors are okay with it.
    • (anon3): Agree vs Meh vs No good signals in community.
    • Conflicting interests: Different culture, hard to see, a lot of small companies. But what if e.g. Google starts sending people. Need to protect what we have.
    • Valentin: How do we represent ourselves to the outside world and newcomers. Has been monopolized, small set of official resources to put this. Need to find an agreement, we need to find what our values are as a community.
    • Need to come to a conclusion to put on the website and anywhere else people see Nix from.
    • Graham: E.g. as a contributor to an Apache project, etc. you’re always contributing as an individual. If people leave jobs, they keep their position in the project as an individual. I value that aspect very much. Might be hard but sounds doable if we have sufficient transparency
    • Tom: Proposal: Use this to draw a line, community contributions are from individuals.
      • @zmitchell: What should we do or not do regarding companies
      • @tomberek: If you’re participating on a board, you’re there as an individual, not as a company
      • (anon4): There’s a recent company team using “Github teams” in the NixOS organization that maintains packages in Nixpkgsb
    • @mat: Underestimating the power companies can have over people, people from companies could swarm the boards and vote in favor of their companies opinions.
    • Companies have very different mechanism to get organized. Important to keep a balance between the entities. People who don’t have such means should also be heard
    • @tomberek:
    • Ron: Two topics:
      • Company influence, what influence should individuals have
      • Could be unaware of companies sending a lot of individuals
    • (anon5): The Nix team can make large decisions. Can be influenced by their companies to add things to the codebase, things that are mainly just beneficial to companies. The Nix team should work on things that are most important for the community.
    • Martin: Regarding risks: Companies working around Nix share the same ?? as community members. No company wants to destroy the smooth goings of the Nix platform. More collaboration between companies and the community
    • @alyssais: Need to worry about Corporate capture: If somebody writes a product on top of Nix, hiding Nix as an implementation detail. Lots of people could be using Nix, but everybody thinks they’re getting a product from the company. People don’t feel inclined to contribute, won’t be doing free work for the community. It’s not bad to hide Nix as an implementation detail, but it has to be done carefully. Easier to do it in a bad way.
    • @ronef: Being in flox, we wouldn’t exist if Nix didn’t. Say some big company comes in, builds a big thing, it could detract from contributions, they could rewrite it, take over
    • @alyssais: Can’t stop people using Nix, can stop handing out controlling permissions. Companies could end up with needs contrary to the communities needs. Need to make decisions for the better of the entire community, not for the company getting most value out of it.

Action items?

  • Guillaume: Risk for major changes not being from community but enterprises. Which processes have the biggest impact on Nix? Maybe RFCs. Make sure such processes aren’t overtaken by single entities. RFCs are done by shepherds, community.

  • @ronef: How to make sure critical things aren’t compromised. Not to have too many individuals from the same companies in deciding positions.

  • Graham: Note: If “contributing as individuals” proposal, this would then not align with that

  • Valentin: Regarding interests of stakeholders. What is the criteria to become a stakeholder. Do-ocracy/Praxiacy. Companies with capacity to do things puts them into power. Can we formalise this to be more predictable? I’m an example regarding the docs team and being sponsored

  • Raito: Proposal:

    • Having companies in the space is fine.
    • Vision of Nixpkgs: Benefit from various people
    • Would like to have the same relationship from companies.
    • Companies should contribute their fair share from their use.
    • Balancing putting things in vs getting things out
    • How to make this concrete?

  • (anon7): Everyone is a stakeholder, do-ocracy, having a formalised criteria would be sad

  • Graham: Different topic: Should have a trademark policy

  • Matthias: Companies as entities, separately from individuals

  • Kranzes: Limitation could be for RFC’s, any single entity can’t have any majority. Otherwise there would be artificial acceptance

  • @alyssais: We have that in the RFC steering committee. That’s good. Need a bit of a compromise, even people contributing as individuals are always a bit influenced by companies. It can be hard to keep this separate as individuals.

  • Additional rule proposal for positions of power: A maximum number of members with any company affiliation at all. Would make sure volunteers are represented and diverse

  • Valentin: Agreed, burning questions: How to make sure they’re on par regarding resources → Community fund

  • @alyssais: My work is full time funded by NLNet, not really a company. Lot of people do work in that way, a lot more aligned to the non-company side of things

  • (anon): Can we pay salaries to board members?

  • @ronef: No. Creates a conflict of interest. Doesn’t mean team leads can’t be paid

  • Matthias: Three catogeries [@infinisil: I didn’t quite hear it]

    • individuals
    • public
    • companies?
      Nix strives to have a balance between the three to take a good direction.

  • (meta) We don’t have to make decisions here

  • (anon): Regarding maximum number of company affiliations. Tricky to implement, sometimes not a big company, solo devs can also have a Gmbh for tax benefits. Need to differentiate between these. In most successful technologies there’s a lot of good influence by companies

  • @asymmetric: Extending the proposal: Fourth group, not commercial, but people. Agree that it should be a balance

  • @edef: Few concrete things came up, RFCs, board seats. This conversation is very abstract though. Not clear what concrete things are in conflict between corporate and individual users. If we make Nix good, that’s what everybody wants

  • Raito: Some communities say “Avoid success at all costs!” xD. Corporate users want some success. Motivation by companies to push for RFCs. E.g. Flakes. For these features, are there situations where individuals and companies disagree

  • @edef: Not a big flakes fan. General consensus seems to be that other people want it.

  • Raito: Not about a precise feature

  • @edef: Seeing a push to label it as unpopular. It seems very popular to me

  • @ronef: (meta) how could this be productive?

  • Raito: (meta) Finish this topic, satisfied, was this good?

  • @alyssais: We all want a good package manager, but what this exactly is can vary regarding different interests, could conflict. What worries me is a conflict in how the community works. A culture defined by volunteers vs corporate interests is very different.

  • Bringing it up again: Who should sponsor Nixcon? From my experience working in companies. Motivation there is to have as many connections as possible.

  • In contrast, volunteers are a lot more picky about this, care a lot more about values. They need to be onboard with others, otherwise they can just stop contributing

  • Concrete concern regarding company interest in Nixpkgs: Will be too easy to design something internally for specific for uses in a company and then push it through. Only works when the company has some power via committers on seats.

  • E.g. some people want Flakes, some don’t, they didn’t get a lot of community input. Has been mostly stuck, community input hasn’t been as accepted as it needed to be, didn’t feel like a community decision.

  • We’re probably gonna keep running into this, it’s hard to design something as a single person, much easier in a company. Seen this a lot in communities, a lot of work needs to get done.

  • tomberek: (meta) Time for proposals

Proposal:

  • (anon): Try to avoid having synchronous meetings, some people can’t attend

  • Domen: Conferences like FOSDEM have a lot of open source contributors, little companies. Do we allow companies to go? Should sponsor talks be allowed?

    • I started nix.dev (official now). Regarding trade-mark, who can use the Nix trademark. Can projects label themselves as official currently, that could stop if we have a proper trade-mark.
    • Second part: Public things like the cache. What makes an official project, what are the rules under that project. E.g. has to contain contributors from different companies or individuals.
    • Need to create incentive for companies to donate to this.
    • @ronef: Two parts:
        1. Practical implications of what it means to have companies work with the community
        1. Trademark regarding Nix

  • @ronef: (meta) Most of this should ideally happen asynchronously

  • Guillaume: We should have a threat model created by the community and lead by the people who can do it

  • Matthias: Establish the three different types of entities. Clear path how they can contribute. Sponsors should exactly know what happens when they sponsor

  • @alyssays: Avoid teamification, parts shouldn’t be owned by teams, shouldn’t require approval by team or to join it. Meetings make it hard to drop in.

Meta

  • @ronef: (meta) Who helps with running it asynchronously? How to do that?
    • @ra33it0 volunteers to help (joined the Matrix room)
  • @tomberek: Working group to make it concrete
  • @ronef: Don’t want to drop it after this
  • Raito: Are we missing something important?
    • (anon): Examples of risk of influence
    • @asymmetric: Better process for deciding order of people
    • Raito: We don’t want just a conversation between two people
  • Tomorrow probably tackling the next subject, anything else to discuss?
  • Graham: Trademark discussed before?
    • @ronef/Raito: Good idea, let’s discuss
    • Graham: Proper trademark policy can solve a lot of problems
    • Raito: Can have this on Discourse
  • Tomorrow: Resource allocation
  • Later: What is official
  • @ronef: Regarding trademark, want to be transparent about it. Difficult is the policy. Where to draw the line. E.g. can flox put a Nix logo on their website
  • Raito: On the hackday we start at 5:30!!! No, look at the schedule :slight_smile:
  • If we don’t have enough time, we can spill into the hack day
  • Try to find ways to make the discussion continue after Nixcon, so that people who aren’t here can also participate

clap clap

(we didn’t get to these topics):

How to allocate resources predictable

How to communicate what is officially endorsed

9 Likes
8

thanks for the report, this is very interesting to read and the style of short statements makes me feels like I was there :smiley:

3 Likes
9

NixCon Governance track: resource allocation (discussion draft)

Goal

The goal of this discussion is to address a core issue affecting the long-term sustainability, scalability and effectiveness of the NixOS community: the allocation of resources. As we grow, we can clearly see the benefits of having a predictable model for resource allocation. The teams are effective in principle, but constrained by the lack of stable, ongoing funding and available time that is provided by the community at large.

Status quo

There are numerous efforts running across the community with varying degrees of impact, funding, and resources. While some work has been started to enable allocating more structured resources across the community, there is still a lot of room for improvement.
There are many areas, teams, and initiatives that are widely viewed as needed (and uncontroversial). With the proper funding and accountibility they could greatly amplify their positive impact on the commmunity and ecosystem.

Key Pain Points

  • Inconsistent Funding: Some teams have some budget, but it’s not predictable or sustainable.
  • Time constraints: Many maintainers and contributors are juggling multiple roles and cannot dedicate focused time to any particular project, hindering progress.
  • The capacity and authority of individuals who take on particular responsibilities are not always aligned or unclear, resulting in friction and frustration
  • Lack of strategic allocation: Resources are not always allocated in line with the community’s strategic goals, where they are known.
  • (Brought up this week) Funding criteria for donors and sponsors

Considerations

  • There are many uncontroversial improvements that just need the work getting done.
    • Contributions are welcome, but there is no guarantee that they will be reviewed or accepted.
  • One scarce resource is maintainers’ attention. Therefore:
    • Maintainers should be consulted when planning significant contributions.
    • Maintainer effort required to guide contributions should be accounted for when raising funds for larger projects
  • Another scarce resource is dedicated time to solve hard problems.
  • Maintainer time is limited even when paid for. Therefore:
    • Allocate part of each budget for knowledge transfer and onboarding potential successors
  • There is great potential for conflict of interest with paying for privileged access to maintainers’ attention. Therefore:
  • Priorities differ among stakeholders. End users have different needs than ecosystem developers.
  • Currently anyone who has the time or money can direct effort according to their priorities.
    • The most prolific contributors are on some company’s payroll, self-employed working on things related to Nix, or have a lot of free time on their hands.
  • Some work is very likely to get done by volunteers, some is hard to even get paid talent for; some requires extensive onboarding because it’s specific to the ecosystem
  • There is a spectrum of involvement and degrees of availability required for different activities.
  • Some activities demand attention once, some repeatedly. Some increase the amount of available attention. There is an economics to that, with long-term investments and ongoing liabilities.
  • There are foundational, long-term needs that have to be addressed to ensure sustainable operations, but they are very hard to get funding for

Proposals

  • Provide easily discoverable documentation, knowledge sharing, and active support for specifying projects or bounties, organising fundraisers, or applying for funding
    • This is likely to have the longest leverage. Anyone who is demonstrably knowledgeable should be able to request resources from external sponsors and receive practical support for that.
    • Needs continuous funding for collecting and maintaining documentation, office hours, work sessions for writing
  • Provide teams that meet certain conditions with a fixed annual budget at their disposal
    • This primarily allows distributing chores, which can serve as first steps for potential maintainers
    • It raises awareness of accountability and encourages effective use of time
    • Possible requirements:
      • Time commitment by the person responsible for the budget (e.g. team lead)
      • A project plan to measure results against
      • See Empowering Community Teams for first attempts at clarification
    • It is more lightweight than paid maintainers, but likely won’t help addressing hard problems or deep issues; also additional overhead
  • Pay at least one full-time developer per problem domain
    • It will likely help solve the hard problems in the mid-term as opposed to indefinitely postponing them
    • This is the most expensive option, and requires the greatest accountability
      • The amount of funding required translates to another full-time job
    • There is a risk for individuals to stall out or getting bogged down in concurrent tasks due to the pacing we observe in globally distributed development where many activities see spurious progress

We propose to implement these measures in sequence in order to alleviate the most pressing short-term problems given the current constraints. We expect early success stories to enable us to scale up and invest strategically to aim at long-term benefits.

Assessment

Teams already work in principle, but need stable, sustainable funding, ideally for at least one person doing at least part-time ongoing work: guide contributions, take care of administrative tasks, keep coherence.

We need to supply those resources at the strategic level and allocate them according to an explicit agenda in a predictable manner. We have to align the good ideas that are out there with the means to implement them and the people to do the work required.

Examples:

  • Documentation team made significant progress with 5h/week leadership, 17kEUR of budget and countless volunteer hours
  • Nixpkgs Architecure Team designed and implemented a large change within a year, essentially carried by @infinisil alone and supported by various volunteers
  • Nix maintainers do part-time work to keep the pipeline running, but are clearly constrained with actually implementing things by neither having more time allocated nor a budget to spend
  • Summer of Nix is capable of delivering tangible results with 90kEUR within a few months, having a proper set of goals and oversight and administrative support

We’re collectively quite good at making localised technical decisions, but lack effective tactical and, most importantly, strategic leadership with the trust, authority, and capacity to set agendas, allocate resources, break ties, and follow through with execution.

A proposal for a similar role has been signed off by the foundation board in February 2023. These tasks could be added to its responsibilities.

Next steps

  • Sketch basic guidelines for the funding and spending lifecycle
  • Request community feedback
  • Initiate pilot program to raise money
  • Initiate pilot program to deploy existing resources
  • Raise money: The foundation board should invest foundation money to ramp up developing bounties or project proposals and run fundraisers
  • Spend money: The foundation board should install an executive to develop programs or agendas, to allocate available funds accordingly, and oversee implementation

Examples of uncontroversial proposals

There are more, rather foundational, ideas that seem to have broad consensus but are not far evolved, well-documented, or widely communicated. Examples include allowing secret handling in the Nix language and the store, formalising the Nix remote builder protocol, making the module system more performant, native Windows support, and others.

Examples of successfully funded initiatives

Conflict of interest disclosure:

This discussion draft was developed by @fricklerhandwerk, assisted by @tomberek, @proofconstruction, and @ron.

@proofconstruction is a volunteer member of the Nix documentation team.
@tomberek works at flox, and is a member of the Nix maintainer team.
@ron is CEO of flox, and member of the NixOS Foundation board.

I, @fricklerhandwerk, participated in or developed many the examples provided here. I am currently working part-time at Tweag and part-time self-employed for the NixOS Foundation. I lead the Nix documentation team and am a member of the Nix maintainer team, and I collaborate closely with some Nixpkgs maintainers and Nix contributors, many of which work at Tweag or flox. I am certainly biased by my experiences and social circle.
Developing this proposal was sponsored by Tweag’s OSPO that also runs the Tweag Nix Technical Group. Opinions are my own. My motivation is to make the Nix ecosystem more useful for myself and everyone, and keep doing that for a living.

4 Likes
10

2023-09-09 NixCon Governance Workshop Session #2

Lead: @zimbatm @RaitoBezarius
Participants: Chair circle, ca. 40 people
Notes: @fricklerhandwerk

Introduction

Questions and considerations

  • @peterhoeg: before we start talking about where money goes, define what we’re trying to achieve in the first place
    • @ron: should abstract it away as that will take a lot of time
      • assume we already know what’s important
    • @peterhoeg: disagree, have to say what the goal is
  • @RaitoBezarius: reminder of ground rules:
    • make short, down-to-earth claims
    • 2-3 min max.
    • use hand signals for approval and requsting direct reactions
  • @ctheune: would caution against clear explicit goals
    • the community is diverse
    • rather make statments like “we want more of that kind” and a few “we definitely don’t want that”
  • @ron: propose to have pilot programs to test out the things we find
  • @qyliss: in some juristdictions you have a lot of bureaucracy to be able to accept even smallish amounts of money
  • @kirelagin: Can/do sponsors place restrictions on how their funds are spent (e.g. “funding should only go to a European entity”)?
    • @ron: we’re talking about money flowing through the foundation. anyone is free to raise their own funds, we can’t and don’t want to control this
  • @janik: how do we determine who can run “official” projects?
  • @ctheune: made good experience with other associations, that to have continuous operations negotiate with companies to hire people and reimburse them with foundation money
    • there are some bureaucratic hoops, but in general it’s an option
    • @ron: is there precedent with foundations working with consultancies? (paying people full time)
    • @fricklerhandwerk: the Haskell Foundation pays consultants to implement things from their budget
    • @ctheune: there are companies that can e.g. share a few hours of accountant time per week
  • (anon): if the NixOS foundation gets a charitable branch in the US, we’ll have to figure out how the influx of money and the spending is handled
    • @ron: clarifications
      • the NixOS Foundation is a non-profit in the Netherlands, not charitable
      • there are tax considerations, etc.
      • one could have bylaws that the US foundations’ board must be the exact same as the original one
      • it’s possible to transfer funds between those with no or low tax implications as long as they have the same cause
  • @asymmetric: how is it decided which rates we pay for implementors?
  • @zimbatm: if we inject money into the community, which side effects will it have?
    • @ron: yes, that’s a key concern
    • (anon): we could put that on the website to be very clear about it
  • @ctheune: currently these aspects are not cared about. from a commercial perspective, we’d love to know who to pay to accept our contributions
  • (anon): do we already classify whether grants are continuos or one-off? do we have any insights into this?
    • @ron: almost all the recurrent funding flows into the foundation, everything else is one-off
      • other continuous things are in-kind donations such as hosting, cache
        • but this is not a contractural agreement
      • everything else is pretty young still
  • @ron: another topic: fundraising
    • what do we consider okay in terms of fundraising?
    • what about sponsoring at the foundation level?
    • we want to make sure we’re not relying on a single entity
    • @tomberek: who does the fundraising?
      • it’s one of the things you can’t let just anyone do
      • is someone assigned?
      • who is putting in the work?
      • @ron: yes, it should be someone associated with the foundation
    • @edef: are we tracking the replacement price of in-kind donations?
      • @ron: we only recently started getting an overview of that
      • @raitobezarius: because funding is intermittent, it’s easier to rely on immediate in-kind support than to think about how to maintain e.g. infrastructure for the next 10 years
    • @janik: is the foundation publishing how much money is in the bank and how much goes in and out?
      • @ron: we published the results for next year a while ago, prepared 2023Q1/Q2 for NixCon
    • @qyliss: can use Open Collective to publish transactions
      • @ron: Open Collective charges fees to be a fiscal host, we’d probably want to avoid that where possible
        • @domenkozar: that may be worth the price, since automating that task ourselves is impractical
        • @qyliss: we don’t need them to be a fiscal host to use them as a convenient place to publish transactions
    • @qyliss: we could use OC as sole fiscal host for simplicity
  • @raitobezarius: sometimes we have an excess of sponsorship money after NixCon. that usually goes to the foundation. what do we do about funds that pile up?
    • @ctheune: are there restrictions about how much money the foundation can accumulate?
      • @edolstra: there is a restriction concerning corporate tax
      • @domenkozar: there are also limitations on the size of a donation
        • @edolstra: you can donate as much as you want, but that will have tax implications
      • @zimbatm: could we create a culture where companies can donate to the foundation directly?
        • what would that mean, what are the implications?
      • Tom: is this charitable issue resolved?
        • @ron: we have put some effort into it, it’s currently on pause, will pick it up again
    • @ron: distinction donation vs. sponsorship
      • donation does not expect anything in return
      • @zimbatm: propose some pre-determined structure that makes donations easier
      • @ron: example: Google using IDX could impact our running costs, should we ask them to compensate?
        • if we had a good relationship they don’t have to pay money but would instead collaborate
        • @tomberek: this is not a hypothetical problem. it’s not critical but we’re seeing a traffic increase
    • @domenkozar: if we have a culture where we have “strategical” sprints (e.g. one for stabilising flakes), that would give a very strong signal to companies and a point of contact where they can support the project
      • it may be expensive to donate 10kEUR to the foundation, but this is something that would produce a tangible result
      • Tom: agreed. also companies have Nix issues and would benefit from supporting hackathons to address them
        • that would also not be a direct donation to the foundation, sidestepping the tax issue
        • @ron: we talked to a few foundations that do bounty programs. there are concerns with who controls the money
      • @domenkozar: the foundation could step in to resolve conflicts
        • the point is not to make strategic decisions but to facilitate them
      • @ron: we could make clear that we’re open to doing such a thing and ask people to get in touch
    • (???): bounty programs are good, they provide some gamification and give some structure to the problems.
      • doesn’t have to be money, could be tokens
    • @adisbladis: using excess sponsorship money could actually incentivise companies to give a lot more

Proposals

  • @raitobezarius: a NixOS cooperative where people can work on Nix for money, a one-stop shop to get paid services
    • @ron: that could be the foundation
      • @qyliss: the foundation decided not to make technical decisions
      • @ron: but we could still employ people
    • @flokli: companies could also do the employment part
    • @asymmetric: a cooperative is employee-owned, would be interested to explore this
    • @qyliss: commercial employers are usually not equipped legally to employ open source workers (IP issues, etc.)
    • @domenkozar: it’s a great initiative but would fall into the commercial realm. anyone can just do that
  • @domenkozar: let the foundation introduce the concept of strategic sprints
    • sponsors could propose things but not decide on agendas. it would still be an agenda
    • the foundation wouldn’t organise directly, but approve budgets to provide the environment
    • @raitobezarius: to expand: there are a lot of Nixpkgs issues that can be taken on by individuals, but some things are only possible in a sprint setup
      • would be interesting to see how we could make those topics evident to everyone
      • selecting a topic for a focused group would be easier
  • @ctheune: we’re looking for ways to get into the community with things that are quite boring, such as merging hotfixes that resolve production show-stoppers
    • it would be interesting to have a somewhat neutral person to accept such contributions even if they are not perfect yet, and resolve discussions more quickly or follow up on long-term solutions
    • the two important parts are
      1. continuity, we’ll have to figure out the funding for that
      2. an avenue for commercial users to get certain kinds of reliable support
    • @zimbatm: security is an important topic for companies. propose to fund a person 50-100% to run the security team
      • have to gauge how much effort is actually required to do this in the long run
    • @qyliss: a lot of commercial users would like to have a security tracker
      • (???): the company I work for would love to give money to get commerial support
      • @peterhoeg: not having a security framework is a show-stopper for many potential commercial users
      • @ctheune: we did the Vulnix thing back then; the problem is it’s a huge chunk of work to see results
        • someone working at 30% didn’t see any reasonable progress, it’s overwhelming
      • @janik: the main concern for customers of RedHad or OpenSuse is whether older releases get security updates
        • @ctheune: had that with NixOS, were doing a huge amounts of backports to old releases, it was untenable
          • we should really focus on smooth upgrades; we have data on how fast rollouts can go
          • @qyliss: we effectively have a policy of discouraging backports because it would create the impression we’re supporting releases that we actually don’t
        • @hexa: this is work that has to be paid for
    • @fricklerhandwerk: there seems to be broad consensus that we just need someone getting paid to work on security
  • (???): very concerned with paying people to work on Nixpkgs, as that would make an impression of having authority on particular topics just because they’re paid by the foundation
    • @ctheune: that could actually improve the volunteer experience as such paid maintainers would take on chores volunteers wouldn’t like to do
      • it also needs some authority in certain situations
      • we shouldn’t create strict rules that prevent us from exploring that space
    • @qyliss: most volunteers just don’t do stuff they don’t like to do
      • sometimes people do things out of a sense of responsibility, but this is self-regulating as they tend to burn out
    • (???): it’s much better to pay people for things they were already doing and have experience with
      • there are some examples of this happening
      • it makes a better atmosphere than paying people who just arrived
    • (???): propose the foundation hires a resident developer to facilitate contributions
      • that role wouldn’t be to implement anything but make sure things can run smoothly
  • @fricklerhandwerk: (presents the proposal from the discussion draft)

Meta discussion

  • @asymmetric: maintainers employed at companies are not doing it as their job description, this is not “a role”
  • (???): we have to install a good policy on transparency
    • should be clear who is working for whom and where the money comes from
    • ideally in a central place
    • @zimbatm: simple fix: make sure all teams on GitHub are mapped to actual teams and linked to their teams page
    • (???): in this room we may know who are stakeholders in the community, but newcomers have no chance. would be great to have that public somehow
  • (???): don’t think that people paid by their employer actually count, as they will usually put in much more hours that they’re paid for
  • @qyliss: the line between volunteer and paid work is hard to draw
    • I do things in Nixpkgs to do things I care about, have many small-time supporters that don’t set my agenda
    • @ctheune: people have fractured identities, they act with different hats on in different situations, sometimes even at the same time
      • GitHub profiles cannot reflect that
    • (???): donations can be considered volunteer work, because you’re not paid per project but support you as a person for doing meaningful work
    • @janik: many people contribute packages, but that has to be reviewed by someone
      • reviewers are volunteers, but that capacity is very limited
      • but sometimes multiple people working at the same company may push things much faster because they have financial incentives
        • @qyliss: agreed, from first-hand experience it’s hard to balance those interests
        • @embr: as former manager, if you’re in that situation the company has a strong incentive to get changes through no matter what
          • it’s not their job to think about what that does to the community
        • @ctheune: companies may have more urgent and immediate needs, even if they’re committed to making a better thing tomorrow and not run away
          • this can also be valuable input for the community as well
          • there is a tension between a “generative” aspect of making new things and a “moderating” aspect to prevent things from getting out of hand
      • @piegames: another view is personal relationships; one just has to know who to talk to to get things merged
        • beginners struggle with this a lot
        • we already started actively working against this by marking first-time-contributor’s PRs
    • (???) on the flip side, having two engineers from a company maintain a component is valuable, as it’s maintained
      • even better would be having people from different companies do that

Meta

  • @raitobezarius: did we address the topic in a meaningful way?
    • @qyliss: trying to make concrete proposals is good, but these things can’t be solved by talking about them
      • things like accepting sponsorships are too large for such meetings
      • for future workshops (if we want them at all), adjust the format for making proposals
      • @raitobezarius: we can only touch on surface-level problems, and deeper issues need focused groups
        • the point is to meet and talk to each other before going into detail
        • also we want to continue online to avoid locking out people who are not present in person
        • the next step is to go into detail
    • @fricklerhandwerk: 2023-11-25–26 there will be a workshop in Zurich to pick up on some of these topics
      • everyone is warmly invited to join, make sure to book early so accommodation is affordable
    • @asymmetric: of the people present only a few spoke at all
      • the outcome of this workshop should be working groups to address the particular issues of interest
    • Arian: would like to collect information how to get into the position to accept money, e.g. setting up legal things
5 Likes
11

NixCon Governance track: offical projects (discussion draft)

Goal

Beginners have a hard time to evaluate what they can rely on in the Nix ecosystem, while stability and maturity is one of the major reasons to choose Nix. The goal of this discussion is to decide on measures to significantly reduce the cognitive overhead for new and existing users.

There are many ways to approach this:

  • A branding policy that defines what’s “official”
  • Having dedicated code owners with clear authority, responsibilities, obligations
  • Recommending particular projects in documentation
  • Simply saying to figure it out for yourself because this is how it works

Open issue on the foundation board’s tracker:

Proposal

Tiers

  1. Mentioned (third party)
  • Code that works and solves a known problem
  1. Endorsed (third party)
  • Significant user base
  • Software is usable and approachable
  • You don’t have to read the code to work with it
  1. Recommended (community project)
  • Large user base
  • Maintained and accepting contributions
  1. Official
  • Vital to the ecosystem
  • Actively developed by at least two people and with enough resources in the long run
  • High standards of code quality, collaboration, and documentation

The nix-community GitHub organisation can be an “incubator”, a staging area from which potential official projects can graduate.

Implementation

  1. Decide on criteria
  2. Define processes for state transitions
  3. Determine responsibilities for implementing the policy
  4. Take inventory
  5. Update status of existing projects

Given this is a significant undertaking with substantial impact on outward perception of the ecosystem, we need a trusted community member with dedicated time to drive the design process and implement it.

We propose to install an Executive Director for the NixOS Foundation (following the example of the Haskell Foundation). A proposal for a similar role has been signed off by the board in February 2023. Add to the role’s responsibilities:

  • Creating a plan to be signed off by the board
  • Incremental implementation, communicating with project owners, maintainers, community, …
  • Driving the decision-making process on controversial items to conclusion

Examples

  • Make Home Manager official
    • It is widely relied upon and actively maintained
  • Make NixOps a community project
    • It has one maintainer but is not actively developed
  • Make Hydra third-party
    • It is effectively unmaintained
  • Make the experimental installer a community project
    • It’s actively developed but not widely agreed-upon
  • Make npm2nix a community project and archive it
    • It’s unmaintained for years and should not pollute the top-level

General idea: The NixOS GitHub org should have at most a page worth of projects total that all clearly signal “this is what you should know and care about”. Everything else goes somewhere else.

Alternatives

  • Some other (e.g. more limited role) is created to implement the proposal
    • We are short on trusted community members who can make new long-term commitments
  • The foundation board delegates subtasks to particular teams
    • Teams are already busy with their own scope
    • Team-leads would have to be empowered to make the necessary changes
    • Still someone has to break down the full problem and see it through to the end
  • A new team is formed for this and similar purposes
    • This has been discussed repeatedly in the past
    • We are still short on trusted community members who can invest the amount of time required
    • Teams tend to discuss a lot if no one is driving the process
  • The foundation board makes case-by-case decisions
    • Infeasible due to time constraints. We recommend delegation.
  • Some combination of the above
    • Example: the foundation executive develops a plan, runs a to revise it and sign it off, with the foundation board prepared to break ties, then delegates and supervises implementation by people responsible.

Next steps

The common part of the proposal and each alternative is that the foundation board needs to make a decision how to proceed. The board must:

  • Delegate to someone who is empowered to make the decisions and is expected to carry them out, and provide them with the necessary resources and permissions.
  • Clarify that the board will oversee the activity, serving as a final recourse.

This discussion draft was developed by @fricklerhandwerk and @tomberek, and proofread by @proofconstruction.

Conflict of interest disclosure: as above

2023-09-10 NixCon Governance Workshop Session #3

Lead: @ron
Participants: Chair circle, starting out with 8 people, ending up with 14
Notes: @fricklerhandwerk

Introduction

Questions and considerations

  • @garbas: Hydra is unmaintained but crucial
    • @edolstra: it’s just not actively developed
    • have to maintain it or figure out something for the future
    • something that helps us maintain the cache, which is a common good, must be official
    • definitely agree on having an “official” brand
      • certain projects may need some funding to make it happen though
    • @janik: we should consider spending money on Hydra, refactoring or replacing it or whatever
      • we need to figure out a solution for the future
      • there are many companies who have their own Hydra clone because it’s untenable
  • @ron: we may want to minimise the number of tiers to keep it simple to figure out what goes where
    • it’s not just about having maintainers, but also public image
    • last year’s survey showed 50% had <3y experience, now we have 70%
      • new people should expect things to work as promised
  • Hippie Hacker: we use a tool called devstats that we use to gauge project health
    • there is also more than just the person, also the release cycle
    • is there a process, is there governance structure?
    • we use: sandbox, incubated, graduaded, archived
    • @adisbladis: we have nix-community that was originally intended for that, but no project has ever graduaded because there are no criteria
  • @garbas: we can learn a lot from the Rust community. they have a problem graduating things
    • if a third-party project becomes very successful and the maintainer doesn’t want to put it under the brand, there will be tension
  • @ron: should also talk about de-officialising
  • @janik: what if more than one project does the same thing?
    • e.g. sops-nix, agenix
    • @ron: that’s what distinguishes open source from a company, we can’t necessarily choose one
    • Hippie Hacker: we in fact fund multiple implementations to see how it goes
    • @phaer: that should be part of onboarding to make reasonable overview and comparison
    • @ron: this becomes a documentation challenge
  • @Mic92: NixOps is dead
    • @adisbladis: on life support
    • @edolstra: @roberth may disagree
    • Hippie Hacker: we had etcd going down to one maintainer, and ended up having companies donating to maintain critical software
      • but it has taken 2 years to get back to 4 developers, only one of them having 5 years of experience with the project
    • @garbas: the problem with NixOps is that there are a number of contenders, each very opinionated
    • Hippie Hacker: have been thinking about Hydra
      • must figure out the surface area, what is there to take care of?
  • @garbas: who would want to write a CI?
    • @janik: @lilly actually would, but doesn’t have time
    • @fricklerhandwerk: how do we make sure it ends up replacing Hydra instead of ending up on the pile of good ideas
      • @brianmcgee: it has to be blessed
        • choice overload is a real problem for beginners
      • @tomberek: it also has to be used
        • needs a dry run before graduating
      • @adisbladis: we could launch it in the nix-community org as a testbed
  • @0x4A6F: we also have widely used community services such as @lassulus’ pad or the wiki, how would we integrate that?
    • put it under the official domain or host it on foundation infrastructure
    • @ron: good point, we had the same kind of issues with nix.dev
    • @janik: the same goes for GitHub
      • comments on RFCs got obliterated when user accounts were disappeared
      • we should mirror everything we have to hedge against such things
    • Hippie Hacker: there needs to be a working group to figure these things out, make decisions, and implement it
      • @ron: this ties into discussions we had about code ownership
  • @fricklerhandwerk: how do we determine the state transition? who decides?
    • @bmg: could do it like the Apache Foundation, who have a process, but don’t know what that is

Proposals

  • @adisbladis: use nix-community org as a staging area
    • @fricklerhandwerk: actually need to follow the rules once set up
    • @tomberek: this is the role nix-community can serve and we want it to be, but we have to start and do it
  • @ron: ideally it would be an objectively verifiable checklist a workgroup could propose in an RFC
    • @garbas: we should run a test with one project for each part of the process:
      • it should follow the structure of an RFC process
        • someone has to suggest it, someone to second it
          • should talk to the project author first; they should be one of those
      • @adisbladis: it can happen that project authors might not agree with making their project official
        • @phaer: there may be projects we want official but are not maintained
        • @tomberek: this came up in RFC 101, there is some precedence
  • @janik: projects that have to be demoted from official may even go outside of nix-community if they don’t fit the criteria
  • @ron: need an initial working group to go through the process
    • should start before formalising any roles
    • @tomberek: yes, just get started and wait for veto
  • @fricklerhandwerk: the problem is not making design decisions, because we have enough people capable of doing this in a limited amount of time, but with implementing them
    • a lot of these discussions really boil down to people having the time to make things
    • @garbas: the person doing it should also decide what to do
      • @fricklerhandwerk: how to have them have more time?
      • @tomberek: teams needs their own budget
      • @ron: if proposals come in, and there are no alternative proposals and we have the funds, this is what we’re going to support
  • @tomberek: another approach is by delegation
    • e.g. “hey infra team, we need that resolved”
    • @janik: getting people on the infra team is difficult because they need access to secrets
      • also we’ve seen that the deployment process was broken for months
    • the request should come from some governing body, so it can’t be ignored
  • @ron: volunteers for the working group?
    • @0x4A6F: whoever is driving this would need permissions for both repositories
      • @ron: would like to remove the requirement of getting blessing every time. if you’re on that working group that means you have the power to decide things
        • unless there is some outcry of strong objections
      • @adisbladis: a working group will have the gravitas that people with permission will follow suit
  • @fricklerhandwerk: proposal to balance against the committee idea:
    • one person drives the process and does the bulk of the work, including carrying out execution, getting feedback or conflict resolution by a group
    • @garbas: how is this different from the RFC?
      • @tomberek: there are more decision-oriented and action-oriented RFC shepherd groups
        • this proposal is distinct from that though
  • @tomberek: there is the proposal for a community program manager to facilitate and implement such things
    • @ron: convinced that would help a lot
      • this is largely a budget and bootstrap issue
    • @janik: we can start fundraising with Open Collective and people can buy others the time to make things
      • @ron: this is how we ran the documentation project, but for eventually we need more like 500k-1M EUR overall
      • @janik: there is also NLnet grants
        • @ron: we should support people doing fundraising as well
        • @adisbladis: we should not focus on greenfield projects for the official parts though
      • @tomberek offers to support fundraising efforts
      • also Google Summer of Code for smaller projects
  • @ron: provide regular fundraising training or office hours
    • can bring in professional fundraisers to share knowledge

Action items

  • @tomberek will write Discourse post with call to action
  • @tomberek and @fricklerhandwerk will compile a list of funding avenues for different types of projects
    • find a place to publish that information
    • provide contact details where people can ask for help and get mentoring
5 Likes
12

Thank you so much for organizing such an open debate & document it so throughly! :rocket: I believe this is a key-effort to keep the ecosystem thriving and approachable at the same time.

Quick comments on the notes

  • @adisbladi: it can happen that project authors might not agree with making their project official
    • @phaer: there may be projects we want official but are not maintained
    • @tomberek: this came up in RFC 101, there is some precedence

I think what i was trying to add to the discussion here was that it might be useful to have a definition of what “maintained” means in this context, i.e. how responsive authors are expected to be.

Projects which are “unmaintained” over a longer period of time (?) should most probably find a new maintainer before becoming official.

3 Likes
13

Then start maintaining it, it is clearly a critical piece of the infrastructure.

Considering making hydra a second tier project even makes me wonder again where priorities are.

And also, what would it mean for the projects being labeled “official” or “third party”? Is it just the position on some website? Would there be any requirements for the maintainers to be met? Are ownership transfers required? What happens when a project gets demoted again? Will an official project receive any benefits like free hydra time, or some money from the foundation?

“widely agreed upon” does mean what exactly? Who is asked here? Would recognition or agreement of the “not widely agreed upon” things change if they were advertised more aggressively? So far I was unaware of an experimental installer under the NixOS org, I was only aware of the “regular official” installer and the detsys one.

And coming back to hydra. How do we deal with those projects that are basically crucial to the nixpkgs workflow, but not or barely maintained? Why are we thinking about a demotion, instead of raising funds to help them overcome the issues they have? What are the issues? Is hydra perhaps maintained but complete?

5 Likes
14

without commenting on anything too much else, I think what you call “demotion” is maybe more about reflecting the current reality, rather than reflecting its importance.

I think this has value – My perception is that “it works and is critical”, but also that “no one is in love with it” and “no one wants to [deeply] invest in it”.

Making it clear that it is in a different tier than nixpkgs, could allow folks to:

  1. see it as an opportunity to contribute, take ownership, etc.
  2. see it as an opportunity to augment the ecosystem with an alternative, etc.
  3. generally avoid misplaced expectations, where they might otherwise mistake it as being under more active development than it is.

Separate, but relatedly, I think going with “tiers” of support might be better than “third-party” which is more of a term I think of when I think of projects that are primarily “owned” by external organizations to the “nix community” at large. I perceive Hydra as being a “community property” though not necessarily actively developed the way nixpkgs, nixos, etc are.

4 Likes
15

I guess people will fix it if it breaks badly in production one day. It may be in a poor state of affair, but if it’s working in production and no one cares, it’s likely to stay like this until it break.

2 Likes
16

Thank you for clarrifying.

“Official”, “Community”, and “3rd Party” indeed appear like “ownership” labels to me, thats why I appreciate your clarification and the use of the word “support tiers” which make much more sense. And I think some classification in that regard is indeed important.

Though instead of using words that might imply ownership, lets just agree on the fact that we have a lot of official projects under the “nixos” org in GitHub. All of them appear to be official, as long as the primary fork lives in the org. Regardless of what a list on the homepage might say.

Those needs to be categorized into support tiers and/or activity levels.

Yes, it is fine for the website to link to HM, NixOps or other 3rd party projects (where I consider the nix-community org a 3rd party!) to give some overview over related projects.

It should though by no way try to do any claims about any activity or maintainership or support level to be expected from that third party projects.

17

Wanted to add that in regard to funding in order to support critical areas I fully agree. This was one of the topics that was discussed in one of the tracks with key questions revolving around both raising funds and granting funds.
Plan to follow up on that topic with whoever is interested as many of the dilemmas there are quite critical. (Do we raise via pure donations? How do we prioritize allocation? How does one decide “salary” bands? as a few examples)

2 Likes
18

That was an example idea from before the public discussion, which clearly indicates we should somehow pick up maintenance again. But really my intention was to reflect current reality, as @colemickens pointed out.

It should be both, in my opinion, as the idea is to signal to users and contributors what to expect in terms of code quality, support, and maintenance activity.

This was never brought up as far as I know, and I wouldn’t know why. If someone wrote code is maintaining it, and the proposed working group wants to elevate that project in status, the first step would be asking the code owner if they’re interested in that kind of attention. More visibility often translates to more support requests and contributions to handle.

I think that should simply amount to finding a place for it to live, and that would depend on whether someone is still maintaining it at all.

Benefits would make a lot of sense given that so far more official status only adds responsibilities, and compute time on community infrastructure seems a very reasonable one. I’d support some kind of material benefits as well, and while direct funding through the foundation is probably a long shot at this moment, we could take an example from how the NGI Zero consortium supports their projects with various services to raise overall product quality and success probability. We’ve already been experimenting with and discussed more direct support with grant applications, as a concrete example.

This is a subjective statement of course, but for me it’s things where there’s no evidence of someone involved objecting to the current course taken.

There’s potential for some shifts, and I’d appreciate if there was higher probability that active community members had a higher chance to be aware of all the things they would care about. But I don’t think advertisement would make a substantial difference, because the number of people we’d consider stakeholders will still be limited. The real problem is that for many issues we don’t have a clear definition of who should be asked, and no boundary who should be listened to, so there is always uncertainty, which I think sometimes leads to decisions not being taken although they could be.

Yes, the terminology needs a bit more clarification. Ownership and support are orthogonal concepts, and we need measurable definitions for both in order to set realistic expectations.

Right now there are the NixOS and nix-community GitHub organisations, which are already well-known and are already the best approximation we have to what’s really going on in terms of ownership and support. All I’d like to do is improve that approximation in order to reduce the time and effort required to make best use of the Nix ecosystem and participate in its development effectively.

2 Likes