Loving this. Honestly I keep encouraging folks to just TRY native Nix for dev environments. So easy to set up and get value on day 1 that you'd be shocked. Also models/LLMs have made lightyear strides in the last few months to help with everything around it. We've been building up Nix based skill systems into our Flox skill and it's been super meaningful both on adoption and when we need to scale it up. (disclaimer I do Flox.dev which is Nix based and we do cool Nix stuff)
For anyone reading this and jumping to a broader conclusion: the Nixpkgs core team disbanding does not mean Nixpkgs or Nix is dying.
It does mean that this particular structure was not sustainable, very important contributors burnt out and we need to do better, faster. We need to continue learning from this and continue building a stronger ecosystem that prioritizes the contributors who are the only reason any of this is possible.
Personally, I'm sorry and grateful. Sorry that it ended in core folks being burnt out. Grateful since they did some of the most amazing work, more than anyone can imagine two people doing.
The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.
That being said, I think it is still a concept worth pursuing.
I agree with the concept but the name is terrible. "Core team" gives one the impression that this is the most important team to the project. It's not! It could be called the "governance facilitator" team or admins or something.
Please name the next iteration something less spicy.
I'm sorry to say that this is a highly ignorant reaction to the situation. Nixpkgs was nowhere the size it is now in terms of contributors and packages, the growth in the past six years was enormous.
The amount of monthly contributions has doubled in the last four years alone, from ~7k to ~14k commits per month. Why did I take six years as a reference? Because 2020 is the year nixpkgs really started to pick up traction, and the growth has been almost linear ever since.
Your argument only holds if I were to say "it grew to its current amount of monthly contributions in 2020 and then stayed constant, without growing any further."
Packages were handled way before 2025 already, so it is strange that you insinuate they'd all only burn out within a year, and before that it was all cake and tea.
NixOS is dying, everyone sees this right now.
> but we've also functioned without one for ~20 years.
Then this is also a PR problem because why need a team when the 20 years before were allegedly so perfect?
I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!
While rollback takes away some fears, “fearless” is a stretch. LLMs are relatively quite bad at Nix choosing tightly-coupled, non-modular, non-scalable patterns with unnecessary dependencies/experimental features, while also choosing to reimplement pkgs.lib functions without good reason. Generating more code, pulling in more deps to get out of the mess isn’t the solution either & is usually what I have been seeing more now.
You are most certainly correct about this! And at the same time, I kind of cherish my ignorance on the proper ways of Nix. I have so many aspects of life where I practice perfectionism, and if Nix becomes another one of them, I shall have no spare time!
On the other hand, I just checked, and the domain ratemyflake.com is available. I think we should set it up, so that we can rate each other's nixings!
This is a massive part of the problem to be advocating for & adopting flakes. My config is much simpler: nixos-rebuild switch --file host/$HOSTNAME. This doesn’t require a properly evaluating, not-quite-Nix manifest file to just to build a system. If more folks understood the standard package format & overlays, they too would come to the conclusion that pointing to a file is simpler/uncoupled. packages are just derivations, as are apps, as are checks so there’s little value in separating them. Overlays, modules, configurations, these are all better as their own files too—instead of what I see more often which is coupling them to the flake so they can’t be consumed by stable nix. I have seen big corpos get totally boned by transitive dependency resolution exploding the lockfile too as input.follows does not offer the same power as overlays. The straw breaking camels’ backs to me is how restricted the input pinning options are to things being shipped by the C++ binary & the maintenance burden upstream now takes on trying to shove too many things into the binary instead of sticking to a few primitives.
You don’t need perfectionism—my config is a mess of some of my most beginner code—but the foundation folks are building on is not good & it ends up leaving very sour tastes in folks’ mouths and/or trying to build abstractions on abstractions to hide the underlying design (things built on ‘dendredic’ patterns, which itself is a questionable patterns, built on flake-parts which is questionable, all to hide limitations of flakes which is the core misstep which is hard to work with causing folks to want to overabstract).
The manpage for `nix build` & `nix shell` goes to `nix-build` & `nix-shell` the stable, non-experimental command which do not need a file as an arg since they are more developer-friendly. The `nix-command` experimental stuff is documented somewhere else—maybe https://nix.dev/manual/nix/2.35/command-ref/new-cli/nix.html... is good enough for the concept. `man nixos-rebuild`, `man nix profile` have `--file, -F` documented.
Huh? Based on what? The packages I use keep getting updated, so clearly nixpkgs is alive. The OS I use keep getting updated, so clearly NixOS is alive to. Who exactly is dying, and what makes you believe that?
Isn't nixpkgs still a pretty bad state? I know there used to be a lot of "abandoned" packages that went years without updating to the new versions provided by upstream, that a lot of packages were copying binaries around instead of building open source software from the source, etc.
Nixpkgs is one of, if not the largest, package managers by # of packages. I think naturally that will result in more abandoned packages than others. What is the % of abandoned packages relative to total I can't say.
Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, you can adopt an abandoned package more easily. That has pros and cons (the AUR has recently suffered multiple supply-chain attacks due to packages being adopted and infected).
> Nixpkgs is one of, if not the largest, package managers by # of packages.
I'm fairly certain that the graph you're thinking of is complete bullshit. It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality.
Correct, but it's another domino in a broader trend that appears to have a common root. It was only a year ago that the moderation team mass resigned pointing the finger at the steering committee [1]. It's not been the same people for the last two years, but clearly there must be systemic issues in the people getting elected to this board for there to be so many persistent problems.
Also see roberth's resignation [2], and Gabriella439's retrospective [3], and then there's Jon Ringer's thing, the list goes on.
I don't know if the moderation team's collapse is indicative of anything. The first blog post complains about the Steering Committee for doing, well, steering. The moderators complaining that the Steering Committee is "interfering" points to a bigger issue where the moderation team didn't understand their role.
The second blog post is from someone on the steering committee who complains about Gabriella439 (the author of the 3rd blog post) "turning on" them after they tried to work with the moderation team, whatever that means.
The third blog post complains that the moderation team was too large, had a lot of absenteeism problems, and tried to do everything by consensus which didn't work with the large size combined with the absenteeism problems.
The last post is most revealing. It's also the least dramatic. It looks to me like they tried to form a way too large group of people who treated this as a low priority, then tried to do everything by heavy procedures and consensus with half the team not showing up. That's a common mistake in community organization that leads to collapse.
EDIT: I looked up the conversation about the NixOS moderation team resigning. Apparently the moderation team was causing a lot of their own problems within the community. I'm not going to read it all, but this looks like familiar overzealous moderator drama
I think the elephant in the room is that many tech nerds are just famously terrible at working with others and social skills in general, even if they have a long history of excellent work. Especially so if that experience was not gained from traditional careers where it wasn't possible to get by without people skills.
> but clearly there must be systemic issues in the people getting elected to this board for there to be so many persistent problems.
First time dealing with a committee? It is routine for every community to be shrouded in an ongoing cloud of drama and that doesn't indicate anything at all. There certainly could be problems and if there are it'll generate chatter, but the problems have to be dealt with individually. People resigning and complaining about a steering committee is normal.
The moderation team stuff was largely unrelated to tech stuff, and was specifically involved with politics and ideological HR-style cancellation discourse.
One of the most notable actions of the team was managing a protest against defense companies assisting the project.
Its disbanding was just another instance of the well documented, and statistically supported, end of the cancellation committee trend that rapidly took off in 2021, peaked in 2023, and has nearly fully receded into oblivion since then.
The backlash against that trend, while not communicated publicly by most (far-right folks excluded...), has been massive, but handled tactfully, behind the scenes. Always important to remember that the equity-left is only about 20% of Americans, and the US is the global stronghold for such ideals. (That 20% makes quite a bit of noise, which gives many the impression that there are many more than there actually are. The reality is just that most people are polite, and don't want to get involved in discourse where their opinions could lead to them facing dramatic negative consequences.)
The global community has not been supportive of the continuing of the trend. So it's not just pushback from the (largely polite) majority of those in the English-speaking world that gave the whole situation a fair shake.
Anyway, to reiterate: the moderation team's disbanding had just about nothing to do with technical aspects of the project, and it could be argued that its disbanding was potentially a positive sign for stability.
> Always important to remember that the equity-left is only about 20% of Americans, and the US is the global stronghold for such ideals
What ? The U.S main ideological exports of the last 50 years are neoliberalism, alt-right and techno-feudalism. Its 2 party would register as far right and center right in basically any other country.
> The U.S main ideological exports of the last 50 years are neoliberalism, alt-right and techno-feudalism
U.S.A is responsible for the pervasiveness of social liberalism in the centre-left of Western countries, and more specifically the topics of its American version (the so called "wokeness"). It's distinct from neoliberalism, although academic left, and its pundits, like to use that misnomer for anything liberal they want to put down.
And I want to point out that all of the terms you used are generally poorly defined.
> Its 2 party would register as far right and center right in basically any other country.
That's also wrong, just look at the current European landscape. American Democrats are not like CDU in Germany, Conservative Party in UK, PiS in Poland, etc. , but rather closer to the centre-left counterparts in the respective countries.
I agree with you. If you look at its biggest sponsors, it’s apparent that social liberalism is an attempt to shore up the position of neoliberal capitalism by redirecting ire away from capital and corporations. By elevating the individual above all else, and promoting identity groups secondly, it also implicitly directs people away from class-based politics (which is furthermore framed as a form of supremacy/oppression). Finally, the lowest classes in the West are divided evenly between whites and oppressed minorities, so keeping them at odds prevents intra-class cooperation.
there are two distinct usesn of team/committee/council/etc in the software world, though they often get conflated. one is a formal structure to help with things like coordination and governance when many people are working on something, and it does seem a little silly to have one consist of just two people.
but the other usage is to create an entity, and say "this entity is responsible for so and so problem", and humans then sign up to be part of the entity as a formal indication that they are working on this problem. and in this sense of the word it's perfectly fine for a core team to be two people, and for it to officially disband when those people no longer want to be working on the problem for whatever reason. note that they did try to recruit new people to the effort, and if they had succeeded then the "core team" entity would have provided some sort of continuity to the project despite the original people moving on.
It was 4 people originally a year ago. One left because too much drama. Another joined another committee and was ineligible to continue. The remaining two wanted to recruit new people, but no one wanted anywhere near that dumpster fire. So they got burnt out and disbanded the whole thing.
Sharing something I'm personally excited about that's made possible with a lot of Nix/NixOS (nixpkgs) in the background by the Flox eng team. Was initially built for devX but is having a lot of pull for establishing agent infra!
We've been working quite a bit on bringing in Nix/Nixpkg/Nixos based architecture into the space of bringing in determinism to the baseline infrastructure of our AI stacks. This also leans into the conversation around sovereign AI and how Nix is letting us own more of that stack.
Asking this with a bias since I work on Nixos.org and Flox.dev - How is the team thinking about the infra layers underneath these models? Any priority or reason to imbed determinism/reproducibility at the bottom of the stack?
What's the best practice right now for setting these up? We've been primarily using Nix/Flox to set up the models pretty quickly and at least with minimized amount of commands(biased Nix/Floxer) here and found it useful
A small note of amazement from Nix/Flox person here. Incredible to see this release and congrats! Mike, you're an allstar for so many years of contributions!
Ron from Flox here. We recently wrote this piece on how Nix can address the emerging CVE remediation problem. We are curious to hear any feedback on our approach.
