FOSDEM 2026: Observations and key takeaways If you missed FOSDEM 2026 — the largest conference dedicated to open-source software — you can still absorb some of the experience as shared by NLeSC RSEs Flavio Hafner*, Ole Mussmann and Faruk Diblen.*

Flavio Hafner on FOSDEM 2026: Security, LLMs, and Software Performance

This is a version of the original post by Flavio adapted for Medium.

My highlights from this year’s FOSDEM are in the areas of LLM/security/open source, in machine learning/software performance, and in databases/search.

Upcoming features in git

Patrick Steinhardt from GitLab, and git contributor, presented about some upcoming changes, planned for the major 3.0 release towards mid-2026.

Under the hood, git changes the hashing algorithm from SHA-1 to SHA-256

  • This is because SHA-1 is not secure — a paper from around 2017 showed that it does not create unique hashes.
  • While git itself does not rely on uniqueness of hashes, the ecosystem implicitly does — for instance, by pinning software dependencies to git hashes.
  • At the same time, large parts of the ecosystem (GitHub for instance) currently do not support SHA-256 hashes.
  • By moving the default in git, the contributors want to solve the chicken-and-egg problem of “no-one wanting to use the feature because no-one supports it” and vice versa.

New command: git history for easier rewriting of history

  • In git, rewriting history through an interactive rebase is cumbersome and takes several steps.
  • Another limitation is that it leads to orphaned branches because other branches depending on the changed commits are not updated. For instance, this makes is tedious to use workflows with stacked branches.
  • The new git history command, inspired by other version control systems such as Jujutsu and Mercurial, provides some functionality that makes such workflows easier. For instance, git history reword <commit> allows to amend the commit message of a specific commit; git history split <commit> allows to split a specific commit.
  • The new commands also rebase other branches that depend on respective commits.

Open Source, LLMs, and security

This was a major topic in this year’s conference and featured in two keynotes: Michael Leenaars (talk) from NLnet, and Daniel Stenberg, founder and lead developer of cURL (talk).

  • Both speakers highlighted that LLMs can help malicious actors find and exploit vulnerabilities in open-source code, and thus open-source will become more vulnerable to supply-chain attacks.
  • Stenberg further detailed how LLMs bring out the worst and best at the same time. On one hand, the cURL project is bombarded by AI-generated security reports. This has led cURL to stop their bug bounty program. On the other hand, they use LLMs selectively to find security issues and review code.

Several talks in the security devroom addressed the same problem.

Updated governance model for open-weight LLMs

  • A talk about LLMs and cyber risks argued for an updated governance model for open-source (and maybe open-weight) LLMs.
  • While closed LLMs are easily controllable, safeguards in open models can easily be fine-tuned away.
  • Therefore, open LLMs cannot be regulated like an API, and closed LLMs may even have an advantage because they are easier to regulate — a “mitigation gap”.
  • The proposed solution is to define fine-tuned models as “substantial modification”, and shift the liability burden from the issuer of the original model to the fine-tuner.

Auditing and securing supply chains

  • The Open Source Technology Improvement Fund (OSTIF) presented their work on providing security audits to open-source software (talk).
  • AboutCode presented their tool for detecting LLM-generated code (talk). If I understood correctly, the tool finds parts of a codebase that have been regurgitated from another source, and can pinpoint to the source. One challenge was that LLMs often create similar control flow, but different variable names from the original. In their scancode.io tool, they solve this problem with code stemming, a method also used by treesitter.

Data, Search and LLMs

Vector search

  • In a RAG pipeline, the hard part is data engineering: one has to understand the data and the context (talk). For instance, the chunking strategy is crucial for the retrieved the results.
  • Weaviate presented and demonstrated multi-vector retrieval. This is particularly useful for search on PDFs that include images. Their tool implements the MUVERA algorithm (paper).

Speeding up LLM inference

  • The vLLM project explained how they speed up LLM inference with quantization and speculative decoding.
  • Quantization compresses the network weights into buckets. This leads to a smaller footprint in memory and to faster transfer of the weights from the GPU’s high-bandwidth memory to the SRAM and Tensor cores that do the matrix multiplications.
  • Their benchmarks show that the ideal strategy (4-bit integer quantization vs. 8-bit integer quantization vs. no quantization) depends on the number of queries per second.
  • For speculative decoding, one trains a light-weight “speculator” model that generates tokens at inference time, and the main model approves or rejects the generated tokens.

Machine learning, performance, and observability

Performance engineering

  • Two talks discussed best practices for performance engineering: to reliably capture performance regressions, benchmarks should be repeatable and representative, and setting them up for this requires some thought. Challenges include isolating the benchmark environments and avoiding too many false positives.
  • The first talk outlined a statistical testing approach based on increasing the signal-to-noise ratio and deciding when to reject the null hypothesis of no performance regression. Further, running benchmarks in the cloud poses challenges, and they recommend avoiding virtualized environments. The slides of the talk are here.
  • The second talk focused on change point detection. I also liked the idea of using canaries to track the performance of the benchmark infrastructure itself — you want to know when the problem is with the infrastructure and when it is with your software.
  • Both talks argued for continuous performance monitoring and presented some tools for this.nyrkioprovides CI runners for change point detection; the runners are not free but according to the provider, they are of better quality than other runners (such as github-action-benchmark). hyperfine is a command-line benchmarking tool.

Performance monitoring of deep learning workloads on HPC

Two talks addressed performance monitoring for deep learning workloads on HPC systems.

  • The first talk highlighted the shortcomings of nvidia-smi compared to dcgmi. In short, the former only tells us whether the GPUs are busy, but not how efficiently they are being used (tensor cores, streaming multiprocessors, DRAM). One example was that using 32-bit and 16-bit precision on a H100 shows the same utilization on nvidia-smi, even though FP32 is less efficient because H100s do not support tensor core computations with this precision.
  • The same talk also suggested that running dcgmi incurs no overhead because it is reading data that is already being tracked. I found useful docs from SURF here, and they are more cautious, mentioning that dcgmi may slightly slow down your code. I guess one has to test and see it for themselves. The NVIDIA docs for dcgmi are here.
  • The second talk presented an open-source observability dashboard for deep learning on HPC. It covers hardware, workload, and model health (such as gradient tracking). The tool was just released during the conference. I’m curious to see how it evolves and how it compares to other tools.

Ole Mussmann on FOSDEM 2026: Nix, International OSS, Accessibility and Collaboration

Opening

A quote that hit hard:

If we lose our democracies, Open Source is irrelevant and goes away.

Nothing to add here.

Nix and NixOS

nix for Determinism

Bruce Gain discussed using nix for “deterministic distributed-system benchmarking”. Without special care, library versions and kernel versions will drift over time. The low-hanging fruit docker is not helping here. It solves packaging, not reproducibility, for two reasons:

  • docker uses the host’s kernel, and
  • it is really hard to make a container deterministic. apt-get update is not reproducible, any unpinned library will drift over time. You could distribute the images instead of Dockerfiles, but those are huge and not meant to be changed (only appended).

nix solves those issues by treating hashing and pinning every input of a project. Infrastructure is treated as a pure function. For identical inputs, the output must be identical as well.

Software Bill of Materials (SBOM) Tools for nix

What’s inside your software package? Which dependencies do you use, and what’s their dependencies? This surprisingly hard question is relevant for license compliance (did you obey the licenses of all libraries that you used?) as well as cybersecurity. If there’s a vulnerable package somewhere in the stack, you’d like to know, right? There’s a few tools that can help you out:

Determinate Systems seem to have their own tool as well, but it does not seem to be public (yet?).

Thanks for the heads up from Tristan “TheComputerGuy” Ross.

Sphinx Documentation for nix Code

Sphinx was originally created as a documentation tool for Python code, but it has since become a generic tool targeting all sorts of projects. [1] With Rémi “minijackson” project [sphinxcontrib-nixdomain](https://github.com/minijackson/sphinxcontrib-nixdomain) (rolls right off the tongue, doesn’t it?), one can document nix options, modules, functions, package sets…

This is the first time I see a structured approach to documenting a nix project. Well done!

International Open Source

Open Source in China

Open Source looks different in China, says Richard Lin. There are several factors at play:

  • FLOSS is seen as a market capture tool in three easy steps:

  • Turn standards into de facto rules,

  • Rules into monopoly, and

  • Monopoly into profits.

  1. Going global is not expansion, it’s survival.
  • The market in China is dry, so branching out is a necessity.
  1. FLOSS is a declaration, not procurement. The goal is to nurture industries that will enlarge future tax revenue, not buying a working product. The process for companies is:
  • Self-declare a directional FLOSS project,
  • Build it,
  • Pass inspection, and
  • Receive cash.
  1. Software development, even FLOSS, is a cathedral, not a bazaar.
  • Development is top-down.
  • Pressure from the FLOSS community is slowly changing that.

You might notice a lack of FLOSS culture. Instead of “software wants to be free”, this looks very market-driven. And yet, even through this lens, this flavor of open source looks better to me than closed source. It will be interesting to watch how FLOSS develops in China, and how the different viewpoints will evolve.

Accessibility

I arrived late to Mike Gifford’s talk “Accessible Sovereignty: Why the Four Freedoms Depend on Inclusion”, so I can’t say much about the actual content. What did impress me was that he had a live-transcription of his voice underneath the slides. That is not only terrific for the hard-of-hearing, but also a very comforting addition for everyone else.

Lessons at the eScience Center often use web slides made with [reveal.js](https://revealjs.com/). Modern browsers have a Web Speech API which can be used for speech recognition. Do you see where this is going…? Would it not be great to have a plugin for reveal.js presentations that display speech-to-text below the slides? Any volunteers to build this? Anyone?

Ok, fine. I’ll do it myself.

P.S.: Here it is: https://github.com/OleMussmann/RevealSubtitles

Collaboration

Thierry de Pauw makes an argument that pull requests are useful for open-source work, but are more of a hindrance in the corporate world. They were coaching a novice team of developers and, to make things simple, they introduced trunk-based development with Non-Blocking Continuous Code Reviews. This means:

  • Everything happens on the main branch, there are no other branches.
  • Changes are (automatically) tested before deployment.
  • Every morning, developers review some commits.
  • In the end, every commit will be reviewed, after* being deployed(!).
  • Fixes are applied, if needed, though this is rare.

Woah.

I can see this working for a very specific developer situation while having absolutely rock-solid tests. Distributed development? Difficult. Working on features, while keeping the main branch stable? Impossible. Troubleshooting bugs, bisecting a commit history? Tough.

This is probably not a good fit for research-software-engineering. But I have to say, kudos for trying something weird and making it work. And as a side effect, I realize that I have to be more flexible with my assumptions about how to develop software. That alone is already worthwhile.

Faruk Diblen on FOSDEM 2026: Sovereignty, Burnout, and the AI Reality Check

I hope that by providing this short summary, I can convince you to participate in the next FOSDEM. It remains the biggest and most awesome open-source conference in Europe — and it is still free. It is so large that it reminds me of certain free open-source software projects: it is full of a specific kind of chaos. This is not due to the organization, but rather the scale of the conference and the range of topics and talks happening simultaneously. I must give kudos to the organizers for doing an amazing job.

Reflections on AI and the Community

As I do every year, I was expecting amazing talks from people who are very passionate about open source and “geeky” topics. However, this time I also expected to hear more about how AI is supporting software development. Instead, most talks focused on how AI is dangerous and toxic for open source.

I think I partly agree with that sentiment, but it may still be useful for certain tasks as a supporting tool. There were many interesting talks and discussions regarding the cultural, ethical, legal, and technological effects of recent developments in AI.

The infamous xkcd comic about infrastructure was also compulsory for all speakers to show. Perhaps the organizers were checking presentations beforehand, and if you did not have this comic, they were not allowing you to present. Jokes aside, I also agree now that this comic represents the current reality; it is perhaps even too modest.

Networking and the Research Track

One of the other fun parts of FOSDEM is the chance to meet and have conversations with great minds, contributors, and initiators of very impactful open-source projects. Like previous years, I gathered new ideas and identified new potential collaboration opportunities. I should not skip the “fun stands”; you can talk to the amazing groups of people who made your favorite Linux distribution or who are working on drone development.

As a researcher, I also had a chance to follow some of the Open Research track. Although the research community was under-represented, it had a great variety of interesting topics, some of which are relevant to my own work. My positive experience has made me think about submitting a proposal for next year. For the other talks I followed or found interesting but could not attend in person, please see the Highlights** section below.

After leaving the conference, I had three things in my mind: sovereignty now, sovereignty in the near future, and sovereignty in the far future. I also deeply felt the messages of “AI is killing Open Source,” “Even if AI gets better, we, the developers, will be needed,” and “Everything will collapse if we do not support open source.” These messages were sometimes subliminal and sometimes mentioned openly.

Keynotes

  • FOSDEM 2026 — FOSS in times of war, scarcity and (adversarial) AI: Given by Michiel Leenaards, our neighbor next door. I was expecting him to talk about how NLnet supports open-source software, but he focused on the threats caused by geopolitics. Given the recent political changes in many countries, I think it was a wisely chosen topic that forces us to think about upcoming challenges.
  • FOSDEM 2026 — Free as in Burned Out: Who Really Pays for Open Source?: Marga Manterola, a long-time Debian developer, talked about why the “donations and sponsorships” model is failing maintainers. She listed common funding sources including a sort of “Open Source tax.” This talk may help us find solutions for software maintenance and sustainability funds.
  • Open Source Security in spite of AI: This was the most fun keynote, given by Daniel Stenberg. He told the story of the cURL project and his fight with issues and pull requests created by LLMs. Eventually, they decided to stop their Bug Bounty program. You can download the talk by using the curl command below:** curl https://ftp.belnet.be/mirror/FOSDEM/video/2026/janson/B7YKQ7-oss-in-spite-of-ai.av1.webm --output curl_keynote.webm

Highlights

(The talks I liked the most)

Other Notable Tracks and Talks

Research & Science

Main Track & Community

AI & Machine Learning

Security, Databases & Infrastructure

Booths and Extra Notes

After hearing about sovereignty everywhere, I had lengthy chats with the folks from GitLab, NextCloud, LibreOffice, Forgejo, and Codeberg to learn about open-source office solutions and infrastructure. I also talked to someone from Germany who explained the government migration to Linux (see: Yet another European government is ditching Microsoft for Linux).

I visited the Tor stand, where you could get fancy stickers if you donated to help them fight censorship. The Free Software Foundation Europe (FSFE) is also worth following closely as their goals are related to our own. Finally, I learned about funding.json, a format to declare financial needs of projects in a machine-readable format.