Updates and clarifications to our roadmap

Hello auxolotls!

We’ve been on the forums for around a week and a half.

Over that time, it’s become clear that our initial roadmap wasn’t perfect. It was unclear, leading to confusion. It contained ideas which were unfeasible, ideas based on incomplete information, and knee-jerk responses to the situation.

As we’ve talked, we’ve seen the board’s response to the open letter, the launch of Lix and discussed how we plan to execute on making an alternative ecosystem to nixpkgs. Over time, we’ve been straying from the initial roadmap in places – however @committee_steering doesn’t see this as a cause for concern, we don’t do everything perfect the first time and the roadmap is no exception!

Therefore, we’re making the following changes to better align with the current situation and community consensus:

We’re archiving our nixpkgs fork

This has been suggested a little in the past. After the discussion in @getchoo’s “future of the fork” post we’ve had lots of excellent feedback and it seems clear that we need to update our direction.

Community plans are not currently to maintain and continue nixpkgs in its current form If we’re going to move over and drop dependence on nixpkgs without providing new updates in auxolotl/nixpkgs in the meantime, there’s little point in us having auxolotl/nixpkgs. We don’t want to put time, effort, experience and security on the line in order for a GitHub org name in your config.

If you’re using the fork, we suggest you switch back to the upstream nixos/nixpkgs.

If you’re using channels, you can re-add the NixOS channel:

nix-channel --add https://github.com/NixOS/nixpkgs/nixos-unstable nixpkgs

If you’re using flakes, you can change the organization name from auxolotl to NixOS:

- nixpkgs.url = "github:auxolotl/nixpkgs/nixos-unstable";
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

(In the above commands & code you can substitute nixos-unstable for whichever upstream release of nixpkgs you prefer)

We’re hoping that doing this will provide a clearer view of what we plan to do, as well as free up resources to do other things that matter to us - like getting you a minimal system that doesn’t depend on nixpkgs as soon as possible.

We’re moving to Forgejo

As a side-effect of dropping the nixpkgs fork, we believe that using alternative forges, such as Forgejo, is more achievable. As the initial discussion stalled on an unwilling result of GitHub due to the enormity of nixpkgs, but there were plans to switch to another platform when it became possible, we’re moving to Forgejo.

When we switch to Forgejo, we’re still interested in providing contributors an easy on-ramp, perhaps by doing something similar to Lix, where login is available using GitHub or a separate account. We’d love to hear your thoughts on this!

We’re removing things that would interfere with Lix from our roadmap

We’re excited about Lix, and we think you should be too. We don’t fancy competing with them on forking CppNix, because we believe they’ll do everything we could and more. From your discussions we believe you feel the same!

This means that some roadmap items, such as the path to a better flakesV2, will be left up to Lix.

We’re still interested in other polish, such as the Aux CLI or enabling flakes by default in our system images. For the time-being, we’ve left them on the roadmap.

We understand the contention of having technical details on the roadmap, which we have been historically unwilling to make broad changes to, but we still believe it’s important to signal what phase they could happen in. We’d love your feedback on the roadmap, and after your discussions are a lot more willing to modify it. Please let us know if you still think we’re making a misstep here.

We’re rewording for clarity, and editing to match project needs

We’ve renamed some phases to better match their intention, for example “organization” was changed to “solidification” – it’s very little about organizing and much more about updating and solidifying governance and technical structures.

We also merged and reworded some phases to better reflect the need for, e.g. CI much earlier in the project. These are discussions that are already happening, and we don’t want the roadmap to discourage you.

How can we do better?

We would love to hear your comments on the changes. We understand that many of you may have liked the current roadmap and may be concerned about some of the changes: that’s understandable! The new roadmap isn’t set in stone, and we want to hear your feedback.

That said, we’re sure many of you are glad about what we’ve announced here: we’re making these changes to better fit community consensus. We’d love your feedback on how we could do even better. Is there anything we missed? Any way we could communicate the roadmap better to you?

Thank you for your contributions, discussions, and advice,
The Auxolotl steering committee.


I’m quite excited about dropping Github! This is great. It feels like Aux is pulling the triggers NixOS was afraid to pull. Self-hosting a bunch of stuff, trying to set the tone of discussions, leaving Github, and considering flakes by default. I don’t use flakes, but that’s because it’s still considered experimental/unstable. However, considering going all in is a sign of possible real commitment and that’s what I need, not some half-in, half-out, “but what if we break an experimental feature” attitude.

Good on you guys. I’m actually motivated to bring in ideas without immediately getting shot down with “it’s always been this way, deal with it”. Once stuff is up and running I might actually start contributing to a nix ecosystem again.

The hope is welling up!


I love that the roadmap has received an update. I personally prefer to work in an iterative way, regularly reviewing where we are and what new knowledge we have learned - using those insights to adjust the proposed path ahead.

Thanks for doing this so early on Steering Committee


Let me add to that, I really like that each Roadmap Phase now has an indication when it is considered finished.


auxolotl/website PR23 shows the diff between old & new versions - in case you’re like me and prefer side-by-side comparisons


The roadmap still has elections at the very bottom (e.g. “after everything is done then we’ll have our first election”)

Feels weird that this ^ was, AFAIK, the one thing the community widely agreed on changing but it wasn’t changed and a bunch of other stuff was. Even just removing the phrase “then our first elections” would help IMO.


Yes. My memory is that we discussed it in at least two threads, although I can only find one:

1 Like

@jeff @heliobri, good catch, thanks! Pulling up my notes, it looks like we didn’t discuss moving votes around – that was an oversight

we did have discussion about whether things have to wait for the last stage, it was more in relation to technical processes but I think it could also apply to elections(?):

lots of this stuff could be done earlier… but they must be done by now

I will caution against elections being too early too. SIGDocs attempted to hold an election, but it ended up not happening because of a unanimous agreement that it was too early to do so, and we should wait until at least [what was then Hard Fork] … probably I would personally be accepting of elections as early as stage 2, and in favor of elections in stage 3. Let me know if you think this would be a good timeline

COMSteer has our next meeting on Wednesday, I’ll bring it up then and let you know of the results


Agreed. I think I was the first to say “how can we vote for a sig leader when we dont even know the responsibilities of the role”. That said, I see the “all tech done, then first election” issue as more of an order-of-operations problem. Its not saying vote-now but rather, prioritize solving pre-reqs of voting (like how we picked loomio, our discussion on Alternative vote and STV, then stuff like duration, then nomination formats, etc,) then do voting and tech stack stuff together. I agree some stuff (like SIG members) needs to happen-as-it-goes.

The roadmap could even say “the first steering committee election (after settling on an organizational structure – a structure that depended on the tech stack and iterative trial-and-error on the technical side)”. But just saying THE first election after the entire tech stack is done feels excessive. I think we all (including the steering members) want a more iterative process with a mix of voting and trying tech stuff. So it would be nice if the roadmap reflected that.


I second the order.

What if the speed of iterations slows down over time? As in we might question/ review/ adjust (maybe even vote) more frequently as we’re figuring out the sweetspot of our community structure.

And as we start stabilizing on our optimum, we can scale back the frequency of iteration to get us more stable and grounded. One question I like to ask:

Does the current process feel like overhead?

In my experience it will feel so whenever things are becoming less volatile aka more structured. That might be a good moment to scale frequency down a notch.


so just curious but what exactly is the project of aux now? Since we don’t have a nixpkgs fork nor a CppNix fork, so what exactly is is that we’re doing?

The same thing as before, minus having to handle Nix ourselves. We are still building an alternative to NixPkgs and other projects in the ecosystem.