If a group of people with spare time want to create an alternate non-GitHub workflow, and it works well, we could do it. I would not invest my time or actively support such a project though, because of the significant time cost. If Microsoft becomes hostile, the switch will be more valuable and easier for everyone to accept. They aren't much of a risk to the project today or in the near future. The GitHub-based workflow should stay supported for the following reasons:

• Network effects
  • Virtually everyone has a GitHub account, so contributing is easy
  • Many thousands of automatic backlinks from upstream issues to ours
  • Visibility in GitHub's stats
• Free moderation. The moderation team is already short-staffed; let's not make them also responsible for handling low-level spam, etc, that's done by GitHub now.
• Redundancy. This actually lets the alternate forge setup iterate more freely.

Sponsorships are not merely donations; they entail benefits such as advertising and imply a form of partnership. Given the global nature of our community, we must commit to ethical sponsorship practices.

Therefore, we will reject sponsorships from entities that engage in harmful activities, including but not limited to military institutions, defense contractors, and companies involved in the production of weapons, surveillance equipment, or mass surveillance software. We should review and update this exclusion list to cover other harmful products and practices, with input from the community.

Note in particular the exclusion of military/affiliated organizations. This has been a topic of controversy before. We can't let such an affiliation create division in our community, which is global, and whose members some may find themselves on the other end of a conflict. (And I would recommend not to judge people for working in defense. Unfortunately, you can't have freedom without deterrence and defense, and the world needs good people inside the organizations that provide and/or control this dangerous power.)

We should not seek to exclude individuals from participating in the NixOS community based on their employment, except in cases where individuals explicitly promote or advertise their employer in a manner that contradicts our ethical guidelines.

EDIT: Forgot to explicitly conclude that I would answer yes - merge the PR.

Stabilization implies a long term promise that includes the stability of the hashes produced by Nix. This has wide ranging consequences that make it even harder to fix the numerous issues with Flakes.

As a member of the Nix team I would consider supporting a statement that Flakes are ok to adopt, but with a carve-out for minor changes to such things as CLI flags and changes for the sustainable stabilization of fetchTree, and limited forward compatibility for the lock file; e.g. you may have to update Nix within 7 months in order to accept lock files from newer Nix releases.

I question the technical value of such a statement, but it could help inform users' decisions.

If you want Flakes to stabilize sooner, and you don't mind getting into the nitty gritty of fetching, locking, or the CLI UX, please get in touch with the Nix team. ❤️

As said, it already does, in the form of Home Manager, and that's great.

Perhaps something could be optimized about the installation process and/or the CLIs, but putting the nix command between Home Manager and its users would only serve to stifle Home Manager's ability to improve its own command.

I don't know how Debian works anymore, but I don't think Debian users consider themselves primarily dpkg users, so then why should Home Manager users have to use it through nix?

Self hosting may be a good option, when we have a good plan. Funding a self-hosted replacement for the S3 part of the solution shouldn't be a problem, considering our large user base and perhaps even the EU's "digital sovereignty" goals.

As far as I know, we're still looking into multiple options, so I see no reason to take self-hosting off the table, but it does need a good plan.

We have sufficient means to better deal with the volume of packages, briefly:

• Add support support tiers in meta
• Update-automation and CI improvements
• RFC 92 dynamic derivations so that lock files can be FOD-fetched instead of copied into Nixpkgs, and fetched granularly - efficiently.
• S3 replacement

As far as I know, not spending enough is currently still a bigger issue than funding.

The community is already on a good trajectory; we have already started many good initiatives that improve the user experience and developer experience. Usually the problem is actually finishing such projects. This can be hard when everyone is half-responsible for too many things. This could be improved by encouraging contributors to limit themselves to fewer areas of interest and encouraging collaboration.

Over time I have documented many issues and proposals in GitHub issues for Nixpkgs and Nix. I'll list a few things that are on my mind, but more importantly, we should decide a roadmap together.

• Packages as a language level concept using derivation outputs instead of whole derivations
• Dynamic derivations (RFC 92) so we can stop adding lock files to Nixpkgs, and improve the granularity/incrementality of Nix builds, making Nix builds more suitable for development workflows (as @tomberek also suggests, Nix has great potential here and it should benefit everyone)
• Reduce the number of fixed points per package to resolve long standing tech debt, bugs and UX issues

However, more structural benefits will come from improving the development experience / contributor experience, testing and automation.

• Improve OfBorg to find tests more reliably for non-package changes such as modules
• Look into whether the build farm can be expanded (both OfBorg and Hydra)
• Improve the merge bot (e.g. something like meta.mergeCriteria so packages can opt in to fully automated updates)

Regarding the original topic of inaction, I would like to refer to Tom's above comment and agree.

Regarding activism

The Steering Committee is meant to represent the community, democratizing governance. Democracy isn't just one thing. Activism is a last resort of sorts, and we would be having this discussion if it wasn't for the activism of those opposed to the foundation's choices. I would encourage the Steering Committee to enter dialogue with their opponents, be respectful to them, and foster a respectful and truthful democratic culture. That said, in a sufficiently diverse community, we will have differences of opinion and activism every now and then. That is all part of the democratic process, and in some cases, the SC may have to carefully weigh the arguments and decide that it's best to decide, so that the community can move forward and not be hijacked by an issue that isn't important to the community at large.

In the worst case, the community gets another chance at the next election, possibly creating a majority for their issue within the year. That is again a last resort, but I am confident that the Steering Committee will do a better job at listening to the community than the previous leadership did. I wouldn't mind calling for a reelection if need be.

We have ~80 darwin team members. That's too much to ping all at once, but I'm sure they've joined to be pinged nonetheless. This smells like a tooling or communication problem. A low tech solution may be to add them to meta.maintainers when the opportunity arises?

maintainers = [
  roberth
  # darwin maintainers:
  getchoo
];

That doesn't solve all the annoyances, but it could start to streamline the packages that have it, just by making clear who can help.

I don't think the cost/benefit even make sense, besides the obvious privacy concerns and enterprise-ism.

I support the componentization of Nix. It solves unique problems in what's currently a fairly monolithic product, in a single repo, with somewhat of a single team and community responsible for maintenance and innovation. I would support further componentization of Nix, which would allow not just for better ownership and innovation in those components, but also allow those components to be reused in Nix-like implementations such as Guix. We shouldn't have to push Guix to adopt our libstore; we could make it excellent and then it's up them to make the call, and we should support them if they choose to adopt it.

I believe this is a good strategy regardless of what Guix wants, because it allows to grow a community of multiple tools that benefit from well maintained components, and it allows more radical innovation without having to fork everything.

Fragmentation could be beneficial when it leads to more choice, more participation, more innovation. However, it can also lead to division and worse interoperability.

I think this is a question for everyone who participates in these projects. We all want the best for our projects' users, so it should be logical to communicate and collaborate where possible. This can only be stimulated, not imposed.

Perhaps the formation of standards and specifications could be supported by the SC. This would provide many opportunities to collaborate.

Cross compilation works without virtualization: Nixpkgs configures the compilers to produce code for a different "host" platform than the "build" platform, which is where the compiler runs. Virtualization would only be "needed" when testing the output, which a cross-Nixpkgs does not do.

• Yet. NixOS/nixpkgs#347053

Cross outputs can then be tested by OfBorg when its build farm is configured to have remote builders.

I think it's amazing that Nix can take advantage of the speed of an alternate buildPlatform, but still test the execution of those build products on underresourced machines (such as slow hardware, rare/expensive hardware, or emulated VMs), making the best use of them, all within the same derivation graph, and even when building on platforms that don't have pluggable executable loaders like Linux binfmt_misc.

As a matter of practicality, the adoption of these cross changes should be a gradual process, just like the rollout of strictDeps - not an implement to whack our co-maintainers with, but something people who care about cross can help with.

From what I've heard the work to do this in Nix is basically done, but yet to be incorporated into Nixpkgs.

This seems like an "obviously good" improvement to me, and I don't think it would be controversial at all.

ca-derivations would be beneficial to resource use, and it is always good to complete a feature.

However, as a member of the Nix team, I have noticed little interest in actually completing this feature, whether that's me, the other team members or the community, though I may well be wrong about the latter, if they are actually interested in contributing to ca-derivations.

The progress of this feature is somewhat unclear to me, because the ca-derivations milestone is a recent addition to the issue tracker (not while the feature was initially developed), and it is still very very incomplete. A good first step would be to curate the issues. The Nix team could use your help with that; contact us if you're interested in this.

This thread already has good suggestions. I would be careful not to generate too large an amount of information for the community to consume. For instance, while I like the office hours idea, this runs a risk of "losing" information because it is either not recorded at all, or the recordings aren't worth listening/watching because they take too long.

I think it is important not just to record everything, but also to produce good notes and to document its decisions in a concise, up to date and accessible way.

In fact, this is the most important output of the SC, so I would encourage a culture that values this. I want this to be felt as the purpose of each meeting.

This is a rather technical matter, but I like it, and I believe this can and should be done when we have better CI and testing infrastructure to pick and choose NixOS module sets in more than the (more or less) one traditional way.

Perhaps the SC could serve a small role by polling interest and connecting people, but ideally we enable everyone to organize these things themselves instead; make that really easy.

Just throwing foundation money at maintainers runs a risk of bias, or even the distribution of this funding to be perceived as biased, so I would go about this very carefully. Perhaps a better angle is to improve the assignment of responsibilities, and letting companies sponsor maintenance (with employee time, contract like, or whatever works for them), in exchange for a badge they can put on their website "careers"/"about"/"giving back" page or wherever. Again, this kind of thing needs to be considered with diligence.

We do have areas where help is much wanted, in ways that are more "unbiased" or fair, such as the management of releases, staging, testing, infrastructure, etc. Investing here will show results that we can use to enable more funding, and it will free up volunteer time and energy in the other areas, such as specific packages.

We need to be very careful about forge integrations, because the built-in fetcher implementations must guarantee their own reproducibility, and fetching Git sources correctly is actually non-trivial because of the impure features. Especially git archive includes behaviors that are impure, and it tends to be the backend for forge-specific endpoints and fetchers. This is the main reason why the Nix team hasn't managed to complete the stabilization of fetchTree yet, because we haven't addressed all impurities yet.

With fetchTree stability being a prerequisite for Flakes stability, this is one of the reasons we still haven't delivered stable Flakes yet.

Hi @zeuner, I feel like this is a very broad question, or maybe I'm missing some context.

Nixpkgs is generally very accepting of various quirks, whether that's packaging unfree software, supporting niche platforms, etc. I would not support an overly strict removal policy, in favor of managing expectations with meta attributes.

I don't see any reason to lock out contributors other than moderation; socially unacceptable behavior. If you behave respectfully, I see no reason for trouble.

NixOS/rfcs#180 does introduce a policy for unmaintained packages and broken packages; conditions which are avoidable, so I don't think this would be a problem either.

How strongly do you align with copyleft and FLOSS (Free and Libre Open-Source Software) ideas/ethos? What are the key principles of these movements in your view, and how would you advocate for them in your role within the Nix community? I'm particularly interested in supporting candidates who share a strong commitment to these values.

Do you believe that the nix-community should be managed under the formal governance? If so, how would you propose integrating community management with governance?

If you had the opportunity to amend the constitution, what specific changes would you propose, and why do you believe these changes are necessary?

What kind of relationship should unofficial spaces (Reddit, Discord) have to the community? Should they be linked on the homepage? If so, should they be compelled to comply with the Foundation's code of conduct? Should we attempt to convert these communities into official spaces (if so, at what point)?

What specific measures will you advocate for and implement to ensure the safety and inclusion of minorities in the Nix community, and how will you ensure that their voices are actively heard and considered in the decision-making process?

If so, should NixOS strive to further minimize state and enhance its declarativity in the future?

Grafts are a way from Guix to bring fixes to packages that a lot of other packages depend on without having to rebuild the world basically.

What are your thoughs about bringing a equivalent feature to Nix?

[1] https://guix.gnu.org/blog/2020/grafts-continued/

What experience do you have with being responsible for making headline decisions about software used and depended upon by thousands of people? How many years have you held (or did you hold) that (or those) position(s) of responsibility?

(‘Depended upon’ is an important part of this question; a computer game might be played by thousands but of course that's nowhere near the same level of responsibility as making decisions about the Nix projects.)

What procedure would you implement to make community projects official? What benefits would those projects get once they are?

Related to #89

With the whole Wayland-protocols debate going on, one cannot skip the parallel to Nixpkgs. Some users have a good friend committer to have their PRs reviewed and merged. But the frustration even hits some committers that sometimes are caught self-merging.

Practical solutions to end the frustration would (and will) take the entire community participation. How can you, as a lead, help both to accommodate all the opinions and to speed the adoption of solutions, taking down the number while caring about the health (consider burnout) of those involved on applying those measures?

We all have opinions on the Nix UX, but I think we can agree that it needs improving. I've noticed that in many discussions, we talk about "the user" and our assumptions for what they would expect or understand, without really knowing.

We have no user journeys, no personas, no analytics about how people are actually using Nix which makes good decisions difficult.

Should we focus more on UX than we currently are? What actions would you take to do so?

AFAIK the most well known implementation is ipfs-nix from Obsidian systems that aim to integrate IPFS into Nix.

I, at least in the current state, am a bit skeptical about how the adoption would be. A full bump of my system would pull 10s of GBs of small artifacts, and if you have ever downloaded the closure of LaTeX packages you realized that lots of small operations == slow. I tried myself to make a RFC around exposing IPFS-compatible hashes in a narinfo so users could alternatively use IPFS to download stuff from binary caches but I basically abandoned the idea because I, myself, didn't think it would make much sense. The process would be so slow + the overhead of having to have stuff both in the nix store and IPFS store. I would only use something like this if I wouldn't need to duplicate stuff.

What are your thoughts about these projects and initiatives?

The cache is to big and it can't keep growing at the current rate. What is your opinion on how and what and if it should be garbage collected.

Currently, we seem to be promising compatibility for stable branches, but in new releases, we are allowed to break "if necessary". Where do you think the line of "if necessary" should fall?

How close do you think we can with long-term backwards compatibility - to the Clojure ideal [1] - given the scale of nixpkgs?

Can you answer specifically about NixOS module options, as well as generally for nix community projects?

[1] "There are only two ways to change software: growing it and breaking it. We don't break."

How would you ensure the long-term financial sustainability of the Nix project while preserving its open-source ethos and avoiding dependency on corporate sponsorships that may conflict with community values? What alternative funding models would you explore, and how would you engage the community in these decisions?

What do you believe is the most pressing technical issue currently facing Nix, and how would you prioritize addressing it to ensure the continued stability and advancement of the ecosystem?

How would you ensure that the Nix community stays engaged with the Steering Committee (SC), actively participates, and has a meaningful voice in the SC decision-making process to prevent a disconnect in values between the community and the SC?

Of the currently supported platforms, are there any you think should be promoted to a higher tier or demoted to a lower tier? Are there any currently entirely unsupported platforms which should gain some level of support?

(bit of overlap with #97 with re: darwin specifically)

If elected to the Steering Committee, which other candidates would you prefer to work with, and why?