How to contribute#
The Nix ecosystem is developed by many volunteers and a few paid developers, maintaining one of the largest open source software distributions in the world. Keeping it working and up to date – and improving it continuously – would not be possible without your support.
If you cannot contribute time, consider donating to the NixOS Foundation on Open Collective.
Currently the focus is on funding in-person events to share knowledge and grow the community of developers proficient with Nix. With enough budget, it would be possible to pay for ongoing maintenance and development of critical infrastructure and code – demanding work that we cannot expect to be done by volunteers indefinitely.
Start with asking informed questions, after reading reference documentation and the code relevant to what you care about.
All the source code and documentation is on GitHub, and you need a GitHub account to propose changes. Technical discussions happen in issue and pull request comments.
If you are new to Nix, consider contributing documentation first.
This is where we need the most help and where it is the easiest to begin.
Documentation and contribution guides are often incomplete or outdated, much as we would like them to be otherwise. We’re working on it. You can help and improve the situation for everyone by immediately solving problems with the contribution workflow as you encounter them. This may slow you down with addressing your original concern. But it will make it a lot easier for anyone to make meaningful contributions in the future. And it will lead to better code and documentation in the long run.
Report an issue#
We can only fix issues that we know of, so please report any issue you encounter.
Make sure that there is not already an open issue for your problem. Please follow the issue template and fill in all requested information.
Take particular care to provide a minimal, easy-to-understand example to reproduce the problem you are facing. You should also show what you have found in attempts to solve the problem yourself. This makes it much more likely for the issue to be resolved eventually, and is important for multiple reasons:
A reproducible sample is concise and unambiguous.
This helps with triaging issues, understanding the problem, finding the root cause, and developing a solution. Preliminary research further helps with analysis.
It allows anyone to determine if the issue is still relevant.
Issues can remain unaddressed for a long time. Deciding what to do with them, even after months or years have passed, requires checking if the underlying problem persists or was resolved. This has to be easy to do: then anyone can help out with triaging, and notify maintainers to close or re-prioritise issues.
The sample can be used for a regression test when solving the problem.
Ideally you would also propose or sketch a solution. The perfect issue is, in fact, a pull request that solves the problem directly and ensures with tests that it cannot occur again.
Please use our community communication platforms for asking questions about the code or how to do things. Open GitHub issues to state problems and propose solutions, and close them when the problem is resolved or invalidated.
Please open issues to request new features (such as packages, modules, commands, …) only if your are willing and able to implement them yourself. Then the issue can be used to gauge user interest, to determine if the feature fits into the project, and to discuss implementation strategies.
Contribute to Nix#
Nix is the cornerstone of the ecosystem, and is mostly written in C++.
If you want to help with development, check the contributing guide in the Nix repository on GitHub.
Contribute to Nixpkgs#
If you want to help, start with the contributing guide in the Nixpkgs repository on GitHub to get an overview of the code and the contribution process. There are also programming-language-specific instructions for adding packages.
Contribute to NixOS#
NixOS is a collectively developed Linux distribution that can be configured conveniently in a highly flexible way through declarative programming interfaces.
The code for modules and default configurations is in the
nixos directory of the
nixpkgs GitHub repository.
See the NixOS manual’s development section to get started with making improvements. Contributor documentation specific to NixOS is still lacking, but most conventions for Nixpkgs contributions apply. Help with improving that is greatly appreciated.