Forks and Governance Splits¶
Overview¶
The Nix language and store model are shared ideas; the implementations and project structures around them are not a single monolith. The widely used C++ lineage lives primarily as CppNix (NixOS/nix), the reference implementation shipped with NixOS. Lix is a documented community fork of that lineage (last shared release: CppNix 2.18), with its own releases, hosting, and governance.
This page is a high-level map of that fork and of how governance is organized on each side—drawn from first-party project statements, not chat lore. For chronology and Foundation structure, see Timeline and NixOS Foundation. For evaluator behavior and install details, prefer the implementation pages over this summary.
Details¶
Two C++-lineage implementations¶
| CppNix | Lix | |
|---|---|---|
| Upstream | NixOS/nix | lix.systems (community variant) |
| Lineage | Reference C++ Nix | Fork of CppNix; last shared release 2.18 (About Lix) |
| Compatibility (stated) | Baseline for “stock Nix” | Designed to stay compatible with existing Nix expressions while evolving tooling |
| Typical role | Default on NixOS; most tutorials assume this binary | Drop-in alternative daemon/CLI when deliberately installed |
Lix’s first-party positioning (About Lix, homepage): correctness, usability, selective stability guarantees, community-owned infrastructure, and language/tooling evolution without sacrificing backwards compatibility for valid clients. Documented technical deltas versus CppNix (lazy trees, CA derivations stance, build system, etc.) belong on the Lix page—verify against current Lix docs before relying on any single difference.
Other evaluators (Tvix, Snix) are separate implementation efforts, not CppNix forks in the same sense. Compare them on the implementations index.
Governance: separate projects, separate rules¶
Nix / NixOS community side. Official community structure—Foundation board, Steering Committee, specialized teams (Nix, Nixpkgs, moderation, releases, and others)—is described on the NixOS community page. Technical direction for shared ecosystem changes also runs through the RFC process. Legal and operational support for shared infrastructure sits with the NixOS Foundation.
Lix side. Lix publishes its own binding governance document: overlapping core team (technical stewardship, strategy, conflict resolution), community team (moderation, culture, public presence), and committers (day-to-day merge authority). Decision-making defaults to consensus where possible; the document defines voting and escalation when consensus fails. Hosting and sponsorship posture are stated by Lix (community-owned infrastructure; open conflict-of-interest statements)—see About Lix.
These are parallel governance surfaces. Choosing an implementation does not automatically change which Foundation or Lix bodies govern the other project’s repositories, caches, or moderation spaces.
Documented tensions (stick to project text)¶
Treat secondary retellings as non-authoritative. First-party Lix materials state, among other things:
- Lix exists partly as an alternative to “commercial interests that have long plagued both upstream CppNix and corporate-authored forks,” and emphasizes volunteer governance and published conflict-of-interest posture (About Lix).
- Lix cites significant regressions in upstream CppNix in recent years and notes that Nixpkgs has repeatedly opted not to default stable-channel users to the latest CppNix release; Lix’s “Lix on main” program is framed as keeping releases close to daily drivers (About Lix).
- Lix and Snix are described as similar goals, different approaches (evolve the C++ lineage vs greenfield Rust), with possible future component sharing (About Lix).
CppNix / NixOS community docs do not need to “answer” every Lix claim on this page; they define their own teams, moderation, and RFC path on nixos.org/community. For a neutral reading path: implementation facts → implementation leaf; org structure → Foundation / community / Lix governance docs; dated events → Timeline.
Examples¶
Which binary is on PATH? Fork vs upstream is an install choice; version output differs:
CppNix typically reports as nix (Nix) …. Lix documents output containing Lix (exact wording changes by release)—see Lix.
Where to look next (by question):
| Question | Prefer |
|---|---|
| CLI flags, experimental features, NixOS default | CppNix |
| Lix install, deltas, Flakes stance | Lix |
| Shared community teams / Foundation | nixos.org/community, NixOS Foundation |
| Lix decision-making | Lix governance |
| Dated history of splits | Timeline |
References¶
- Lix homepage — project positioning and ecosystem overview
- About Lix — fork from CppNix 2.18; stated goals, community posture, technical differences
- Lix governance — core team, community team, committers
- NixOS/nix — official CppNix source
- NixOS community — Foundation, Steering Committee, teams, moderation
See also¶
- Timeline — chronological history of the ecosystem
- NixOS Foundation — Foundation role and infrastructure support
- RFC process — shared proposal path for Nix / Nixpkgs / NixOS
- CppNix — reference C++ implementation
- Lix — CppNix-lineage fork
- Nix evaluator implementations — CppNix, Lix, Tvix, Snix index