Hi, all.
This is another attempt to contributr, by suggesting ideas, which have been formatted below, by AI. Forgive me if I’ve misunderstood any of the items, below.
Cheers,
Chris
A community-facing analysis and forward-looking roadmap for the Auxolotl project.
Based on the project’s own stated values, goals, roadmap, and observed community activity.
Version 1.1 — April 2026
About This Document
This roadmap builds on the excellent foundation that the Auxolotl team has already laid. The project has made meaningful, real progress: governance structures exist, SIGs and committees are active, a documentation hub is live, community spaces are running, and a clear vision has been articulated. Labs is active and producing genuinely novel work. This is not a start-from-scratch plan.
Instead, this document identifies where the project currently sits within its own four-phase roadmap, surfaces specific gaps and opportunities, and suggests prioritised next steps — with success indicators and space to log related issues as they’re raised.
Given the small and volunteer-driven nature of the team, no timeline targets are set. Instead, milestones are used to mark meaningful progress. The spirit here is one of encouragement: you’ve built something genuinely promising, and this is about helping it grow sustainably.
Where Auxolotl Is Now
Based on publicly available resources (the main site, the wiki, the documentation hub, the community forum, and the Labs forum category), the project appears to be mid-way through Phase 2 (Implementation), with early Phase 3 (Solidification) elements already visible. In particular, Aux Labs is producing work that goes meaningfully beyond a simple fork — including a ground-up reimplementation of the Nix standard library (Aux Lib) with zero nixpkgs dependency, a foundation layer (Aux Foundation), and an experimental package set layer (Aux Tidepool). This is significant progress.
| Area | Status |
|---|---|
| Community spaces (Matrix, forum, Forgejo) |  Active |
| Core governance structure (SIGs, committees) | Defined and partially staffed |
| Documentation hub | Live and searchable |
| Code of Conduct | Published |
| Vision and MVP definition | Documented |
| Installation/migration guides | Present (early-stage) |
| Aux Lib (zero-dependency Nix library) | Built; adoption proposal in progress |
| Aux Foundation / Aux Tidepool | In Labs; proving the library in real use |
| CI infrastructure (nixpkgs sync) | Operational (teething issues resolved) |
| SIG charters |  Informal — not fully formalised |
| Binary cache | Funding-dependent; not yet public |
| Nixpkgs independence |  In progress via Labs architecture |
| Governance elections |  Not yet started |
| Stable OS release | Not yet achieved |
| Marketing committee | No current leaders listed |
| Lib-specific SIG | Suggested but not yet formed |
The project is doing well at the hard stuff — culture, governance foundations, and genuinely original technical work. The gaps are largely structural and infrastructural, and are solvable with focused effort.
Roadmap Areas
The following sections each represent an identified area of development. Each includes a brief rationale, a set of action points, success indicators, and a column to cross-reference any related issues raised subsequently.
Area 1: Aux Labs — Graduating Experiments Into the Ecosystem
Why it matters: Aux Labs is where the most exciting and original technical work is happening. Aux Lib — a full, zero-dependency reimplementation of the Nix standard library — has been proposed for adoption into SIG Core. Aux Foundation and Aux Tidepool build on it. The Labs forum also contains active discussion about a possible replacement for bash as a scripting language, runtime sandboxing, secret management, portable services, and module-system-driven documentation generation. These are not just maintenance tasks; they represent Auxolotl’s opportunity to genuinely advance the state of the Nix ecosystem.
The challenge is that “Labs” by design is experimental — but experiments need a clear graduation path so that valuable work doesn’t stall indefinitely.
Current state: Aux Lib adoption was proposed in September 2024 with broad community support. A dedicated Lib SIG was suggested as a better home than SIG Core. The Labs forum is active into early 2026 with substantive technical discussions. No formal graduation process appears to exist yet.
Milestones
- M1.1 — A formal graduation process for Labs projects is documented (criteria, review steps, new home allocation).
- M1.2 — Aux Lib is formally adopted, given a home (new SIG or SIG Core), and has a named maintainer team.
- M1.3 — Aux Foundation and Aux Tidepool have a clear public status (Labs, active development, or graduating).
- M1.4 — At least one further Labs experiment (e.g. testing framework, secret management, or documentation generation) has a formal proposal and named owners.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 1.1 | Document a Labs graduation process — criteria, steps, and who signs off | Steering Committee | |
| 1.2 | Resolve the Aux Lib adoption proposal: form a Lib SIG or assign to Core, and name maintainers | Steering Committee + SIG Core | |
| 1.3 | Publish a status page for all active Labs projects (what it is, current maturity, next step) | SIG Documentation + Labs contributors | |
| 1.4 | Encourage Labs contributors to write short forum posts summarising their experiments | All Labs contributors | |
| 1.5 | Prioritise the Aux Lib ↔ Nixpkgs Lib compatibility layer experiment, as it lowers the barrier to adoption for existing Nix users | Labs contributors | |
| 1.6 | Formalise the bash scripting language discussion into a tracked experiment with a named lead | Labs contributors + Steering |
Success Indicators
- A graduation process document exists and has been used at least once.
- Aux Lib has a named home, named maintainers, and a published changelog.
- All active Labs projects have a publicly visible status summary.
- Labs forum continues to see regular activity and discussion.
Area 2: Package Set Completeness and nixpkgs Independence
Why it matters: The stated MVP is a system that can boot to a desktop environment without depending on nixpkgs. This is the technical heart of the project and what will attract and retain users.
Current state: SIG Core is active. The Labs architecture (Lib → Foundation → Tidepool) provides a credible path toward nixpkgs independence. However, many language-specific SIGs (Go, Python, Rust, JavaScript, Haskell) have no named leaders, and several desktop-related SIGs (GNOME, KDE, Home) appear unstaffed. The MVP package surface has not been publicly tracked.
Milestones
- M2.1 — A tracked “MVP package checklist” is published, showing what is needed for a bare-metal boot to desktop without nixpkgs.
- M2.2 — All language SIGs have at least one named lead and a basic charter.
- M2.3 — A desktop environment (KDE or GNOME) is functional on Aux without nixpkgs dependency.
- M2.4 — The full MVP (bare metal boot to desktop) is achieved and announced.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 2.1 | Publish a tracked MVP package checklist in the Aux Labs repo or wiki | SIG Core | |
| 2.2 | Recruit leads for vacant SIGs (Go, Python, Rust, JavaScript, GNOME, KDE, Home) | Steering Committee | |
| 2.3 | Document the current nixpkgs dependency surface — what still depends on it and why | SIG Core | |
| 2.4 | Establish a regular (even if infrequent) SIG Core meeting cadence rather than purely ad-hoc | SIG Core | |
| 2.5 | Identify packages that are well-defined candidates for early migration and prioritise them | SIG Core + Language SIGs |
Success Indicators
- The MVP checklist exists and has measurable, visible progress tracked against it.
- No language or desktop SIG has been vacant (no named lead) for more than two months.
- At least one desktop environment boots on Aux without any nixpkgs dependency.
Area 3: Governance Formalisation
Why it matters: The project’s own roadmap calls for governance solidification in Phase 3. Several committees and SIGs lack charters, and the Marketing Committee has no listed leaders. Without formalised governance, decision-making can stall as the contributor base grows.
Current state: Steering, Security, and Code of Conduct committees are operational. The Marketing Committee has no members listed. Most SIGs exist but have informal structures. Community members have already asked where the roadmap is tracked in granular detail — a sign that structured project tracking would be welcome.
Milestones
- M3.1 — All active SIGs have a published charter defining responsibilities, membership, and decision-making process.
- M3.2 — The Marketing Committee has at least two named members and a clear brief.
- M3.3 — The first formal governance elections are planned and announced.
- M3.4 — An Aux Enhancement Proposal (AEP) process is documented and the first AEP is submitted.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 3.1 | Create a SIG charter template and ask each SIG to complete one | Steering Committee | |
| 3.2 | Actively recruit for the Marketing Committee via forum and Matrix | Steering Committee | |
| 3.3 | Draft the process for governance elections (eligibility, voting method, cadence) | Steering Committee | |
| 3.4 | Document the AEP (Aux Enhancement Proposal) process ahead of Phase 4 | Steering Committee | |
| 3.5 | Consider creating a dedicated Lib SIG to own Aux Lib and related foundational projects | Steering Committee | |
| 3.6 | Add per-SIG granular progress tracking (e.g. Forgejo project boards) so contributors can see what is being worked on and by whom | Steering Committee + each SIG |
Success Indicators
- Every SIG and committee has a published charter accessible from the wiki.
- The Marketing Committee has at least two active members.
- An elections process document exists, ready to be enacted at the appropriate phase transition.
- The AEP process is documented before the Phase 4 milestone is reached.
Area 4: Documentation and Onboarding
Why it matters: Auxolotl explicitly values accessibility and education. The documentation hub exists, but several areas are marked as TODO, and the installation and migration guides are early-stage. Poor documentation is one of the biggest barriers to adoption of Nix-based systems generally — Aux has an opportunity to do meaningfully better.
Forum activity shows that even engaged community members have struggled to find the SIG list, the roadmap, and where to record ideas — all within the first few weeks of the project. This signals a discoverability problem as much as a completeness problem. The Aux Lib adoption proposal also specifically called out documentation as a prerequisite for readiness.
Current state: The Documentation SIG is active with regular Saturday meetings. A centralised docs hub exists. There are guides for installation, migration, a glossary, and a contributing guide. Known TODOs remain outstanding.
Milestones
- M4.1 — All items listed in the public TODO are resolved or have assigned owners.
- M4.2 — A newcomer “Getting Started” pathway exists, covering installation through to a working system, without assumed prior Nix knowledge.
- M4.3 — Documentation covers all active SIG areas, not just those with active leads.
- M4.4 — Aux Lib has complete API documentation co-produced with SIG Documentation.
- M4.5 — A contributor guide exists that makes it easy to write and submit documentation improvements.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 4.1 | Triage and assign all items in the public TODO list | SIG Documentation | |
| 4.2 | Conduct a “newcomer walkthrough” — have someone unfamiliar with Nix attempt to follow the getting started guide and capture pain points | SIG Documentation | |
| 4.3 | Create a documentation roadmap/backlog that SIG members and contributors can pick tasks from | SIG Documentation | |
| 4.4 | Ensure all SIG areas have at least a stub page with a scope summary and links to related resources | SIG Documentation + each SIG | |
| 4.5 | Add a “How to contribute documentation” guide visible from the wiki home page | SIG Documentation | |
| 4.6 | Co-produce Aux Lib API documentation with Labs contributors | SIG Documentation + Labs | |
| 4.7 | Improve discoverability of the SIG list and roadmap from the main website and forum landing page | SIG Documentation + Marketing |
Success Indicators
- The public TODO list is empty or all items have named assignees.
- A newcomer with no Nix experience can follow documentation from a standing start to a working Aux system.
- Every SIG has at least a basic wiki presence.
- Aux Lib has published API documentation.
- Documentation contributions have increased month-on-month (tracked via commit history).
Area 5: Infrastructure — CI and Binary Cache
Why it matters: A Continuous Integration pipeline and Binary Cache are critical for development velocity and user experience. Without CI, package quality is hard to verify consistently. Without a binary cache, build times are prohibitive — a major usability barrier.
Current state: A CI pipeline is operational for nixpkgs sync. Several teething issues (fetch depth, token configuration, PR permissions) were identified and resolved. A binary cache is described as funding-dependent. The infrastructure is GitHub-hosted for now, with Forgejo as the self-hosted code repository.
Milestones
- M5.1 — A CI pipeline is operational for the core package set (not just nixpkgs sync).
- M5.2 — CI coverage extends to all active SIG package areas.
- M5.3 — A binary cache is available, even if limited in initial scope.
- M5.4 — The infrastructure stack is documented so it can be maintained and extended by multiple contributors.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 5.1 | Publish the current state of CI infrastructure — what exists, what’s planned, what’s blocked | SIG Core / Steering | |
| 5.2 | Explore funding options for hosting a binary cache (donations, sponsorship, open source hosting grants) | Steering Committee + Marketing Committee | |
| 5.3 | Document infrastructure decisions in the wiki (architecture, hosting, access control) | SIG Core | |
| 5.4 | Establish a clear owner or working group for infrastructure | Steering Committee | |
| 5.5 | Ensure no single person holds sole access to any critical infrastructure component | Steering Committee + SIG Core |
Success Indicators
- CI runs automatically on all pull requests to the core package set.
- A binary cache URL is publicly documented and available to users.
- Infrastructure documentation exists and is maintained.
- More than one person has access to and understanding of each critical infrastructure component.
Area 6: Community Growth and Sustainability
Why it matters: The project’s values include sustainability and kindness. Volunteer fatigue is real, particularly in small open source projects. Many SIGs have only one lead or none at all. The community needs to grow in a managed, welcoming way — and contributors need to feel valued and supported.
Current state: The forum is active, Matrix channels exist for all SIGs and committees, and the Code of Conduct is published. However, several SIGs have no named leaders, forum activity in the SIG category is low, and the Committees category has no public posts. The help forum shows users engaging and getting answers, but discoverability could be improved.
Milestones
- M6.1 — No SIG or committee has been without a named lead for more than 60 days.
- M6.2 — A contributor recognition mechanism exists (e.g. shout-outs in announcements, contributor listing in the wiki).
- M6.3 — A “good first issue” or “help wanted” pathway exists in the Forgejo repositories.
- M6.4 — Forum activity in SIG and committee categories increases, with at least monthly updates from each active SIG.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 6.1 | Identify and reach out to forum/Matrix community members who could lead vacant SIGs | Steering Committee | |
| 6.2 | Create a simple contributor onboarding flow (what to do on day one, how to find your first task) | SIG Documentation | |
| 6.3 | Ask each SIG to post a brief monthly update to the forum | Steering Committee | |
| 6.4 | Tag beginner-friendly issues in Forgejo repositories with a discoverable label | SIG Core + all SIGs | |
| 6.5 | Consider a periodic community newsletter or digest to keep the wider community informed | Marketing Committee | |
| 6.6 | Build a searchable or pinned FAQ in the Help forum from recurring questions | SIG Documentation |
Success Indicators
- All SIGs and committees have named, contactable leads.
- New contributors report feeling welcomed and clear on how to get started.
- Forum SIG categories see at least monthly activity.
- Contributor numbers are stable or growing.
Area 7: Marketing, Visibility, and Branding
Why it matters: Auxolotl was created partly as a response to governance problems in the Nix ecosystem. There is a potential audience of Nix users who are curious about alternatives. Community members have already raised ideas such as DistroWatch, LinuxTracker, Repology, and Wikipedia — all actionable and low-cost. The project has no active marketing leadership to pursue them.
Current state: Branding exists (logo, name, colour scheme). The main website is clean and informative. The Marketing Committee has a Matrix channel but no named members. Ideas for visibility-raising have been posted to the forum but have not been progressed.
Milestones
- M7.1 — The Marketing Committee has active membership and a published brief.
- M7.2 — Auxolotl has a presence on at least one public social or news platform (e.g. Mastodon/Fediverse).
- M7.3 — A project blog or announcements feed is maintained with at least quarterly updates.
- M7.4 — Auxolotl is listed on DistroWatch, Repology, and at least one other relevant FOSS directory.
Action Points
| # | Action | Owner (suggested) | Issue Ref |
|---|---|---|---|
| 7.1 | Recruit for the Marketing Committee via forum and Matrix | Steering Committee | |
| 7.2 | Create a simple communication plan — what to post, where, and how often | Marketing Committee | |
| 7.3 | Establish a project blog or news feed | Marketing Committee | |
| 7.4 | Submit Auxolotl to DistroWatch, Repology, LinuxTracker, and relevant alternative-to listings | Marketing Committee | |
| 7.5 | Ensure the main website clearly reflects current project status and links to getting started | Marketing Committee + SIG Documentation | |
| 7.6 | Consider a Wikipedia article once the project reaches a stable release milestone | Marketing Committee |
Success Indicators
- Marketing Committee has at least two active members.
- Auxolotl appears on DistroWatch and Repology.
- The project’s social/news presence has been updated within the last 60 days.
- Website clearly reflects current project phase and how to get involved.
Summary Table
| Area | Priority | Phase Alignment | Key Milestone |
|---|---|---|---|
| 1. Labs — Graduating Experiments |  High |
Phase 2 → 3 | Aux Lib adopted; graduation process documented |
| 2. Package Set & nixpkgs Independence | High |
Phase 2 → 3 | MVP: bare metal boot to desktop |
| 3. Governance Formalisation | High |
Phase 3 | All SIGs have charters; AEP process documented |
| 4. Documentation & Onboarding |  Medium-High |
Phase 2 → 3 | Newcomer pathway complete; Aux Lib documented |
| 5. CI and Binary Cache | High |
Phase 2 → 3 | CI operational for core; binary cache available |
| 6. Community Growth & Sustainability | Medium-High |
Ongoing | All SIGs have leads; contributor onboarding exists |
| 7. Marketing & Visibility |  Medium |
Phase 3 → 4 | Marketing Committee active; DistroWatch/Repology listed |
Reference Links
- Auxolotl main site
- Aux Documentation Hub
- Aux Wiki
- Vision and MVP
- Community Forum
- Labs forum category
- Aux Lib adoption proposal
- Experiment Ideas (Labs)
- Forgejo repositories
- Matrix channels
- SIGs overview
- Committees overview
This document was prepared as an external analysis and is offered in the spirit of Auxolotl’s own values: collaboration, kindness, and sustainability. It is intended as a contribution, not a criticism.