Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Project Eligibility Criteria

The AFNix association board decides whether a project can be onboarded on a case-by-case basis. This documentation page describes what minimal criteria need to be met for such a decision to be approved, as well as other optional elements that are desired and valued, positively influencing the board's decisions.

Meeting all these criteria is not a guarantee that onboarding will be accepted. External factors such as infrastructure capacity or concerns about the number of hosted projects also weigh in to the decisions.

If after reading this page you think that your project is a good fit for AFNix, don't hesitate to contact us.

Hard requirements

  • The Project needs to relate to Nix and its ecosystem. We take a very broad and open view of what the Nix ecosystem encompasses. Examples include: Nix language implementations, developer tooling for the Nix language, individual Nix packages or package sets, NixOS modules, Nix language libraries, software or infrastructure related to building Nix derivations, alternate Nix stores and caches implementations, and more.

  • The Project needs to be generally useful to the public. Things that are tailored to a specific individual's needs or a specific company's needs and that can't be easily generalized to other use cases are not a good fit for AFNix hosting.

  • The Project needs to agree to the relevant AFNix policies such as:

Valuable properties

Criteria in this list are not requirements but are desired for AFNix projects. None of them are blockers individually, but a lack of adherence to many of them raises questions as to whether the Project is a good fit for AFNix.

  • The Project should be community driven, not corporate driven. While corporate contributions are welcome, we prefer the Project leadership to be mostly free of conflicts of interest, and we prefer a variety of independent entities to be in control of technical and non-technical decisions rather than a single entity.

  • The Project should be undergoing active development. There are sometimes exceptions to that rule, e.g. mature projects that require long term, reliable hosting which AFNix may be able to provide. However, we do not want to be a graveyard of dead and inactive projects.

  • AFNix expects newer Projects to have thought about the goals they want to accomplish and the scope of their work. This would traditionally take the form of a roadmap document explaining what the desired features of the Project are and what are its differentiating factors with similar projects in the ecosystem. Other forms are also acceptable, for example a list of issues on a tracker, or a release announcement blog post describing the Project.

  • AFNix expects Projects that are forks of existing projects to use an alternative branding that clearly distinguishes the fork from its upstream. It should be clear to users that the fork is a separate Project, and ideally the differentiating factors are advertised upfront to avoid any confusion.