I’ve been struggling to find the time and energy to maintain null-ls, especially since I no longer use Neovim as my primary editor. I’m not confident about my ability to adapt the plugin to 0.10 and beyond, so rather than let the repo silently rot and give the false impression that it’s still under maintenance, I am instead choosing to archive it on August 11, 2023 (about one month from today).

Any user or organization who wants to fork the project and take over maintenance should feel free to do so (the majority of open issues / PRs are not actionable, so I don’t see value in transferring the repo).

I will be traveling for most of July and do not plan on reviewing issues or merging PRs between now and the archival date. If there’s community consensus on a fork, I will update the README to direct users there and mention it in the final archival notice commit to make users aware via their plugin managers, but otherwise, null-ls will remain as-is.

I want to mention a few challenges that anyone thinking of taking over maintenance of null-ls should be aware of:

1. Due to its architecture, the plugin is uniquely exposed to Neovim changes, both breaking and non-breaking. Almost any change to existing LSP-related code has a non-zero chance of breaking null-ls, and this is not likely to change unless core maintainers decide to open up APIs for code actions and formatting, similar to what was done for diagnostics in 0.6.
2. The null-ls repo contains both the core null-ls code and a large number of built-in sources (almost 300!), so exposure to upstream changes is high. There’s no easy solution here - I’ve thought about deprecating all built-in sources and urging interested parties to maintain bundles of null-ls sources for different languages / ecosystems, but for the most part, the willingness hasn’t been there. (To illustrate the scale of the problem: the closest analogue is ALE, which as of writing has 532 open issues dating back to 2017.)
3. Users have an infinite variety of configuration / environment needs, especially in complicated ecosystems like Python. As above, this doesn’t have an easy solution, but the issue helps illustrate why the current approach isn’t sustainable.
4. A large percentage (possibly a majority) of users use null-ls via a Neovim "distribution" (LunarVim, LazyVim, etc.) which adds indirection and makes issues harder to debug. I think this could be solved if I had had more discipline about directing users of these distributions to report issues upstream first and only come to the null-ls repo once they’re confident the issue can be reproduced independently, but it’s a constant source of friction.
5. I did not foresee that built-in sources would be far and away the most popular feature of the plugin, so many parts of the architecture are not as user-friendly or flexible as they should be. In particular, it should be easier for users to write, maintain, and customize sources, both on their own and to share, but it's hard to make significant changes now without breaking things.

Taken together, these issues may justify a total rewrite, similar to the jump from nvim-lsp-installer to mason.nvim. The current repo structure is especially hostile to semantic versioning, which I think is a big leap forward for users and maintainers. (For my part, I am agnostic about the "right path" for null-ls from here on out, but I’ll mention that I’m skeptical that feature parity and sustainability can be achieved without some level of buy-in from Neovim core.)