Help wanted: Planning for Summer of Nix 2025

Dear Nixpkgs and NixOS maintainers,

as a follow-up on a recent discussion on what the NixOS Foundation’s NGI0 funding is used for and why, I would like to ask for your input and advice on preparing the next years’ activities.


  • How can we reward more Nixpkgs contributors for their work?
  • How can we produce more useful and more visible results with less effort?
  • How can we cut down on management overhead?
  • How can we better support upstream authors in distributing their software with Nix?
  • How can we make it easier for users and developers to help themselves?

I’ve already heard some seemingly-obvious answers:

  • Ask regular contributors what they would like to work on, and match that with project requirements
  • Pay fewer people more to work longer towards a rounded product

This is definitely a good direction, and I wish it was that simple, since there are more constraints in practice than meet the eye. Therefore I’d like to have a more nuanced discussion. For anyone who wants to make informed suggestions, here’s some context:


Next year, we will again have ~140 000 EUR available to make supported free and open source projects more easily available through Nix and NixOS, and an additional ~35 000 EUR for operational expenses that do not contribute to implementation work. The broad goals are to support the open hardware ecosystem, self-hosting capacities, and the “fediverse” (federated social networks around ActivityPub and similar protocols), but also to show off success stories and flagship projects to a wider audience and the organisers of NGI. The overarching theme seems to be, in my understanding, to demonstrate that free, libre, open source, participatory technology can be made viable and sustainable for its users and producers across the entire stack. Apart from “just packaging”, this necessarily involves some work on user experience and developer experience. Eventually more software authors should be able to leverage Nix tools on their own, as the budget is finite and we can’t support everyone and everything forever.

Details and updates on what’s being worked on this year can be found in the Discourse thread for 2024. So far we’re using NGIpkgs as a staging area for projects that may not be a good fit for Nixpkgs – some of that software is still experimental, has very few users, and there’s no guarantee there will be someone available to maintain packages or modules in a year or two. We’re also experimenting with organising the code differently, and presenting the projects supported by NLnet in an overview.


Summer of Nix has a bit of a weird history, where originally the primary objective was to just make code appear, also in a last-minute attempt to show results and avoid never getting funding again. Communicating aspirations and results between NLnet, the project organisers, participants, and the community, tended to be notoriously hard and mired with vagueness and open questions. The reason is that everything – at least as it appears to me – was pretty much improvised on our end, effectively by volunteers in their lunch breaks, up to about a year ago. This was possible because public grants tend to be set up such that they leave room for interpretation. But at some point one is expected to produce something substantial that follows the spirit of the agreement.

To give you an idea of what we’re dealing with here, there is an 846 page manual on how to read the 160 page grant agreements, which are full of legalese on how money can or cannot be spent, endless minutiae about accounting and reporting, and maybe half a page of relevant information on what the project is even about – that part originally written by the proposing parties themselves. This means, there is a lot of talking involved to figure out what to do exactly. With guiding us there, NLnet has a challenging task; in the past years they have amassed over 1000 projects under their purview, but only 11 employees at the time of writing.

The first round of Summer of Nix, apart from being adventurous, was successful in the sense that impressive numbers were produced, showing that lots of stuff got done. And yet, only two packages from that time are still getting updates:

As @Kranzes, a former participant, pointed out on many occasions that many projects to be packaged were dead to begin with. Many were never worked on by upstream authors after their funding ran out. And for those ~60 projects not packaged otherwise but which may still be relevant (which @wamirez helped identify), the infrastructure to keep them updated wasn’t set up. At the same time, many packages and modules eventually ended up in Nixpkgs and NixOS, but there’s still no convenient overview of which NGI0 projects have Nix support. The reasons for that:

  • There’s just too much stuff (more than 400 projects collected by @mightyiam @getpsyched @sarcasticadmin @stepbrobd), and it takes a lot of time to even understand what’s going on
  • We always had to to balance efforts between figuring things out and producing code that works
  • Making anything meaningful always took much more time than was available
  • Historically, participants had a lot of freedom to choose what to work on, but no clear delivery goals

This was pretty much okay in the two first rounds, under the assumption that this sort of work was supposed to improve the overall environment and give people a chance to try things out, and less about particular outcomes. Yet, as a result, everything was quite unfocused.

Side note for comic relief: I was the first (or at least the loudest) to complain about that lack of focus and insufficient communication around the program, given its obvious potential for attracting contributors and financial supporters to the ecosystem. Clearly, I got what I deserved by inheriting responsibility for the program in June 2023. Apparently one cannot communicate enough, and whatever I do it still seems like to little or too unfocused.


Seriously trying to make the best of the situation for a year now, while maintaining some continuity, I’ve learned the hard way that certain things seem to be true:

  • 140 000 EUR per year sounds like a lot, but it’s not a lot.

    This pays for something between one and two full-time junior engineer salaries in rich countries. The combination of Nix peculiarities, research-grade software, variety of problem domains and levels of abstraction involved, and product goals, requires highly specialised skills to avoid spending most of the time learning on the job.

    Apart from the existing tradition to make Summer of Nix a group event, not only sounds finding people who fit these requirements just about impossible – it would also require a substantial amount of trust to let them be solely responsible for one of the few big things the NixOS Foundation has going. Especially given that the board’s capacity for doing supervision is near-zero. If such people existed, they’d likely be well-known already, but also would likely have much better-paid jobs anyway.

  • Getting enough qualified attention reliably is quite hard.

    We have lots of great people in the community who really know what they’re doing. But because that is so, one usually can’t buy them with money (at least not the amounts at our disposal), let alone tell them what to do.

    We’re stuck in a dilemma: Much of the work to be done is rather unexciting, otherwise it would have gotten done already by volunteers. It also requires, apart from expertise, quite a bit of focus time to produce useful results. People with the required qualification, again, tend to have well-paid jobs, or other forms of real life, and therefore not a lot of capacity or incentive to focus on tricky problems after hours. And while we could pay experts appropriately for a couple of hours here and there, we’d lose a lot of expensive time on coordination, onboarding, and generally figuring out what to do.

    So far, Summer of Nix was attractive for participants as an opportunity to get (more) into Nix and grow their professional network while working on open source, giving us lots of focus time by people learning on the job, for relatively little money. Often it’s just volunteering in disguise.

  • Apparently there is not that much low-hanging fruit.

    …and identifying it is a job on its own. I’m probably missing out on a lot of quick wins because I’m busy with operational details like writing this post, but many tasks seem to reveal a surprising amount of essential complexity when trying to deliver working code that is somewhat maintainable. Last year’s participants all have stories to tell about how finishing a package or service took weeks instead of hours, for the most obscure and surprising reasons.

    Putting a price tag on things merely reveals that, as far as I’ve observed. Software development being painfully expensive is an inconvenient truth we have to deal with here, we just don’t see it or talk about it in public most of the time.

  • Incentives are weird and sometimes perverse.

    None of that paid work would be possible without orders of magnitude more work getting done by volunteers. But adding money to the equation makes many assumptions break down. The compensation we can realistically pay can’t possibly reflect the value of past and present contributions. Some people can’t even take money for what they do or have done, for a variety of (often legal) reasons.

    Some volunteers rightfully hope the program may make things happen they didn’t get around to or don’t have the resources for. Summer of Nix participants have to hope that some volunteer will make something happen they can’t possibly spend their allocated time on because of other priorities. (This recently happened to @albertc working on Atomic Browser getting unblocked by pnpm.fetchDeps landing, thanks to @scrumplex and everyone involved in getting that merged!)

    What the NixOS Foundation can spend NGI0 money on is rather constrained. For instance, we can’t really do infrastructure work such as improving Nixpkgs documentation or maintaining Nixpkgs Hydra, even if we’d really need that for subsequent years, and even if that would help upstream and downstream developers a lot. That’s what we could use the operational budget for, but there are so many other important things we can do with that money, which one to pick? We also can’t do R&D, that’s what NLnet’s research grants are for (and I’d encourage anyone with ideas for solving well-known technical problems to apply). These are formal requirements by the grant agreements with the European Commission, we can’t do anything about that.

Call for help

Very probably I have blind spots here, and miss something obvious because I’m too closely involved in the details. For sure things can be improved, I’d be very disappointed if not. Please tell me what that could be, here or via direct message.

@drupol, @delroth, and others mentioned that the foundation’s NGI0 engagement should bring more benefit to the ecosystem and its maintainers and contributors. That would indeed be great, and I’m all for it. Please make suggestions how we can achieve that. To be clear, NLnet wants the broader Nix community to thrive and the ideas behind Nix to spread; it’s perfectly in scope for people who helped make all of this possible to benefit from the program in one way or another. One of the strategic goals is to make open source in general more self-reliant, and Nix is considered to play a vital role in that. See Michiel Leenaars’s 2022 talk recorded by @bjth for more details.

@Janik prompted me to get more Nixpkgs contributors involved. I certainly tried, with mixed success. Who should I talk to?

@RaitoBezarius suggested that volunteers may already be working on something that may be in scope, and that we could support them financially to get things over the finish line. Get in touch with me if you have something going, or if you’d be particularly interested in working with one of the NLnet-funded projects and need an excuse.

Maybe some of those constraints above don’t apply to you, and you want to spend serious time on making the collaboration between Nix and NGI0 a success, and hopefully enable more people (including yourself) to get paid to work on open source in the future?

And generally, how can we make the program more attractive, even if it’s still essentially volunteering with a stipend?

Please make proposals! Even proposals for what you’d like to work on. The more precise in terms of scope, time, and cost, the more likely you can start quickly.

And finally, maybe someone else would simply do a better job at running this next year? Don’t hesitate to propose a better candidate, including yourself, or ask me for details on what’s involved in doing what I do.


I’m not sure I understood - why can’t we use the money for that? See e.g unfinished effort.

Here are some easy to find low handing fruits: Use the 3.skill: sprintable GitHub issue label. As you can see these are mostly very old issues that those who opened them would be deeply satisfied to see them getting closed.

Additionally, it is easy to solve these issues without delving too deep into Nixpkgs details, which is exactly what I understood you were looking for - you don’t need a lot of skill to solve them, and IMO it is exciting to solve ~1 year old issues.

Because our concrete task for NGI0 is not to maintain NixOS or generally make the world a better place, but get the NLnet-funded projects to work reproducibly for their users and developers. The operational budget would be there for such support tasks, but there’s no process to decide what’s the best use of that money.

Reducing tech debt would be something for this year‘s Sovereign Tech Fund “general investment” grant, but that is very different in nature, and the foundation would have to apply for that first.

It might be nice to attract a group of people to work on mobile-nixos which is a NLnet project (although looking at the grant date it looks like it’s no longer funded):

I tried to do some work on it during my time during SoN 2022 but it proved too difficult to get up to speed for the feature I was working on. I know @samueldr was very helpful at the time with guiding me so maybe they could jot down a list of low hanging fruit to work on if willing. I know the documentation could probably be updated.

If the list of tasks were arranged ahead of time and a team of contributors were assigned, I bet this could cut down on the time needed to get familiar with the project. The mob programming setup seems particularly suited to helping with onboarding as well.

@samueldr Correct me if I’m out of date/wrong with any of the above.

1 Like

As hinted in a previous announcement, the future of Mobile NixOS as Mobile NixOS is in a state of flux. So it’s kind of an awkward moment to say anything about that.

I still need to figure out a resolution to this problem.

1 Like

Proposal: provide one high-level project that serves as a focus for the work. This should be something that helps NGI as well as provides benefits for Nix+Nixpkgs. This gives the Summer a goal, a “north star” which guides the efforts.

Small organization “in a box”

When a small company, non-profit, or any organization gets started, they often would like a variety of technical services. Sometimes they are built by a bootstrap team, or cobbled together from various vendors, or inherited from another organization (eg: a franchise model). This technical setup is often cumbersome and is a distraction from this organization’s main goals.

SoN can create a system whereby a small organization would be able to self-host many of their needs with minimal or limited developer support. Nix knowledge would allow for great customization, but not required to support an organization in their initial phases. Consider a small non-profit or business; they need to spend as much time as possible on their core mission without being held back by availability, dealing with multiple vendors, technological hurdles.

The services needed are not domain-specific. They support generic groups of people that need to use technology.

  • organizational management
  • video conferencing
  • chat/communication
  • knowledge base/Wiki
  • email/newsletters
  • website hosting
  • basic workflow support
  • budgeting

This project is well-served by Nixpkgs because many of the moving pieces exist, it matches our philosophy of self-hosting, and can turn into a great demonstration of the technology. This is not solving a large number of technical problems, but requires a dedicated team producing a focused product. They will leverage the vast amount of work that has gone into Nixpkgs into a final product that provides a great deal of value and is fun+easy to demonstrate.

The questions in order:

  • How can we reward more Nixpkgs contributors for their work?
    • SoN contributors to this effort can dedicate their focused time and be compensated.
    • Many Nixpkgs contributors will have their work reflected in the outcome and be credited.
    • The high visibility of the outcome provides more visibility to Nixpkgs contributors.
  • How can we produce more useful and more visible results with less effort?
    • This “org in a box” idea is meant to be specifically useful for NGI and be something that can be demonstrated, used, and relied upon by people doing serious work, thus bringing more visibility to the Nix ecosystem.
  • How can we cut down on management overhead?
    • Focus the SoN participation to be a smaller team and/or include management skillsets into the team.
    • Ask for participation from NGI or similar organization in the management.
  • How can we better support upstream authors in distributing their software with Nix?
    • A NixOS-based “org in a box” would enable easy access for upstream authors to expose non-techncial/non-Nix-afficianados to their software.
  • How can we make it easier for users and developers to help themselves?
    • The NGI focus on self-hosting already contains this concept. While not trivial, the idea will be allow usage by non-Nixers, but to allow experts to tinker with the outcome if necessary.

I like this idea. From NGI perspective we have been looking for a way to create more packages. Maybe not realistic, but with the goal to create (and maintain) a package for every NGI-project. This is a continuous effort, which is bigger than the Summer of Nix. Your proposal to create the (dev/support) infrastructure for a small team of “full-time”-packagers sounds good. They can really focus on the packaging, including communicating with project owners who have to help with domain knowledge.