What is NixOS

NixOS is an open source operating system that has been in active development since 2006. In the past decades it evolved from initial academic groundwork into a software destribution that is maintained by thousands of developers and provides more than 120.000 packages, which can be thought of as both the building blocks of the OS but also the applications that can be used by users. Its target audience are people that need their computers (be it desktop computers, laptops or servers) to have a high degree of reliability while being extremely customisable at the same time. This goal is achieved by a novel approach to software configuration that is called the Nix programming language.

In 2015 the NixOS foundation was founded to secure the long-term development of the project. For parts of my internship the foundation paid me to work on the Nix security tracker.

My role at NixOS before the internship

I've been using NixOS for the past 9 years as my personal operating system for my laptop and my servers. Due to it's unique approach to reproducibility, I was quickly able to contribute to the projects code. Back then it was relatively uncommon to just use the system without also contributing to its codebase.

Through the years I took over maintainership for ~80 packages in the distribution, which is a non-binding way to signify responsibility to keep a certain bit of software working in the future. Except for my participation in a 2021 student program called “Summer of Nix”, all this work was done unpaid. For me it was an opportunity to fix problems on my computer by myself and learn about software development. I can highly recommend this approach to anybody wanting to dive deep into how software is made, as distribution maintainers interact with a variety of different software ecosystems and development roles.

Then in June 2024 I started freelancing for NixOS to support in some high-priority packaging tasks. Relatively quickly it got clear that there would be funding to do my internship by working on the UX Design for the Nix security tracker.

My roles during the internship

During my internship I ended up working in two different teams. The first three months I worked with 2–3 others on the Nix security tracker, the remaining three months with the Nix@NGI team on the NGIpkgs distribution.

As NixOS doesn't have any office space (the foundation is registered in the Netherlands, my supervisor Valentin Gagarin lives in Hamburg) I worked from home all the time. Coordination worked through 2-3 meetings a week. Usually there would be a planning meeting on monday and a review meeting on friday. Inbetween we'd frequently meet to discuss specific issues or just pair to work on a problem. Besides that we'd heavily utilise the GitHub issue trackers of the corresponding projects (Nix security tracker, NGIpkgs) by writing down the knowledge we aquired as we moved forward. And of course, as this is a software project, the most important means of communication was code. We worked by the general rule “if it's not merged into the main Git branch, it doesn't exist”, which means we tried to pour ideas into deployable code early on.

An interesting side effect of all my internship work being open source is that anybody can actually understand what I did for pretty much every workday by browsing the issue tracker and the Git history.

The Nix security tracker

The Nix security tracker is a web-based tool that is currently being built to support the security efforts of the NixOS project.

Problem space

Software has a tendency to do unintended things and in some instances, these unintended behaviours pose a security threat to people or organisations. As NixOS consists of more than 120.000 packages, dealing with security vulnerabilities in these packages becomes a continuous effort.

The majority of security vulnerabilites is found by people outside of the NixOS project. To communicate their findings to all users of vulnerable software, a security researcher that found a vulnerability can use a well-established database called CVE (Common Vulnerabilities and Exposures). Once registered in the database, a vulnerability is given a CVE number like CVE-2025-32463 that can be used in various contexts to address the issue.

The package collection behind NixOS is called Nixpkgs (spoken Nix packages). Every package is backed by a data structure called derivation that essentially contains the recipe for how to build a package and what ingredients are required for it. The central question for people trying to fix security issues in the software contained in Nixpkgs is “Is this derivation x affected by this CVE y”.

This matching between derivations and CVEs is a process that is currently done in a mostly manual way. With currently around 100 CVEs being published every day, this is work-intensive and error prone. This is both especially bad, as time is a very valuable resource in a project mostly driven by volunteers, and the consequences of a false-negative match can be catastrophic, as this would result in a known security vulnerability that is not being fixed in NixOS.

Working with user stories

When working collectively on a tool that is supposed to support non-trivial workflows, it's difficult to arrive at a consistent idea that is ready to implement. To work iteratively on the project we used a popular technique called user stories. Each workflow a software is supposed to allow is formalised in a natural language description that usually starts in the form of “As a user x I want to be able to do y”.

See here an example of a user story that lays out a tiny feature: People should be able to compare version numbers with each other and we want to provide visual guides for that.

Applying this technique on an actual problem turned out to be a very nice experience for me, as it allowed me to direct my focus to the bits that matter: People being able to achieve certain things with our product.

Solution

For the three months I was mostly busy writing user stories to communicate requirements for the data structure to the other team members. After the internal representation was sufficient, I could start writing code for the frontend to enable the workflows described in the user story. At the end we had a product that we were able to demonstrate to members of the Nix security team, the working group that is handling the day-to-day operations of fixing security vulnerabilities in NixOS and that will eventually use the tool.

Hackathon in Zurich

In November 2024 I attended the ZHF Hackathon (which is a bi-annual event being done around the NixOS releases) and met my supervisor Valentin for the first time in person. This was a really nice opportunity to get in touch with the wider community and demo the state of the Nix security tracker to those community members that will likely use the software in the future.

Summer of Nix

Goals of NGI

The Next Generation Internet (NGI) initiative is a funding program run by the NLnet foundation that distributes EU industry subsidies to individual open-source projects. It fills an important gap, as usually open-source projects are too small to apply for the multi-million Euro grants giving out by the EU, even though many open-source projects provide important software infrastructure.

Currently around 1.400 grants were made to support hundreds of open-source projects.

On top of funding the sustained development of these projects, NLnet has an interest in distributing the software they fund. As the technology to achieve that they chose NixOS years ago. The effort to package all NGI-funded software and to make them available for NixOS is currently done in a program called Summer of Nix. The resulting package set is called NGIpkgs (spoken NGI packages).

Summer of Nix

Summer of Nix pays a varying amount of students each year for three months to package NGI funded software in Nix. January to March 2025 I worked on preparing the program and do UX Design work on NGIpkgs. The team had a size of 9–10 people, with me being one of two full-time developers.

The description of my role from the public announcement post:

Kerstin is here to make our jumble of software actually approachable for regular people. Our responsibility is to be available for her observation and interrogation, and to provide all the technical support possible so she can focus on serving our stakeholders’ needs instead of fighting implementation details.

Working with objectives and key results (OKR)

In the three months working on the Summer of Nix project we employed a technique called objectives and key results (OKR) to keep our goals aligned by working iteratively and collaboratively. OKR introduces a distinction between objectives that are idealistic goals to achieve for the organisation and key results that are verifiable outcomes that align with one of the objectives.

For example an objective we developed is “Make NGI funded software easy to discover and run”. One of many key results we assigned to this objective are “Users new to NixOS can deploy a chosen service in 30min”, which is something that can be verified in e.g. a user test. Another key result for this objective is “Users can find the right application for fulfilling a specified task in 10 min”.

Presenting a package set to users

In my assessment of what would be required to “make our jumble of software actually approachable to regular people” I found early on that improving the already existing overview page for NGIpkgs would be key. It wouldn't just allow users to engage with a presentation of the package set that is more suited for their perception than the GitHub page, but it would also provide an incentive to NGI project authors to have their project represented in NGIpkgs, as it could serve as a distribution page to point their users to. This way we hoped to include the project authors in the process of creating packages.

Here is a user story I worked on to let users try a service without having to deploy it to their infrastructure.

The resulting bit in the overview page looked like this:

How the internship worked out for me

In the end I'm really happy for the opportunity to do my internship at NixOS. I always felt that after finishing my degree I'll probably work in roles that are closer to software engineering than design work. Working in the kind of in-between allowed me to understand better what skillset I actually aquired in my design studies, while still being able to work on stuff the that I enjoy working on.

One experience I'm especially grateful for is the realisation of how working collaboratively doesn't just get things done faster, but actually enables to achieve things that are completely impossible to pull off alone. I knew about this rationally before, but to actually see it happening in front of me was nice to experience. Thanks!