FOSDEM 2024 - Summary and Reflections
Tags: fosdem, sbom, cra, opensource
Published: 2024-02-05 11:22:11

Back home from another visit to FOSDEM (the 8th, the 10th? - I'm getting old), and I thought I'd make a short summary with personal reflections.

So, what is [FOSDEM](https://fosdem.org/2024/), in case you don't know? It is one of Europe's biggest developer-focused conferences, mixing everything low-level and high-level in tech in a casual style. From the old obscure and up to the latest trends, you will find them all here. The common pillar is, as the name implies, Free and Open Source projects, with a healthy mix of hobbyists, NGOs, policymakers, and commercial organizations in a relaxed conference setting. Usually, there are also related events (Fringe events), before and after FOSDEM itself. With 900+ speakers, and talks available online for free there is something for everyone. Have a look here to grasp the size and diversity: [Schedule](https://fosdem.org/2024/schedule/).

Regarding the Fringes, some examples this year were: EU Open Source Policy Summit 2024, Workshop on FOSS license and security compliance tools, The joint 2024 Hackathon of the European Commission and PEReN, and a lot more. The Fringes are a great way to network and have fun in casual settings.

Usually, I try to attend before the actual FOSDEM event, like the license compliance and SBOM event, but this year, it was pure FOSDEM only. I also went "privately" this year, so that meant a bit more focus on just doing what I felt for at the moment. Anyway, that means these are all personal opinions, not those of my employer!

Everyone's FOSDEM experience will be different, but here are the topics where I attended during the two days (a healthy mix) with links to the FOSDEM videos and presentations.

## General Reflections - the TL;DR

First, it is still the same old FOSDEM experience - lots of t-shirts and swag, beards, and the smell of GNU in overcrowded presentation halls:) - but it is really noticeable how the FOSS community has matured and is tackling new challenges on a more mature and abstract policy-related level. There are a lot of focus on regulations, laws, compliance, vulnerabilities, community funding, and how to collaborate to solve all these challenges. Surely, these issues have always been, in different forms, important - Open Source is the pillar on which modern digitalization work. But, most of the developer rooms handling these topics were jam-packed this year! So this is telling, and a good sign - the wide Open Source Challenges are of a broader interest in the developer communities also - it is not only about tech details.

## Security, Policy, and Lawmaking - The Cyber Resilience ACT and the Product Liability Directive (PLD)

There were many chances to dig into the EU Cyber Resilience Act. Simplified, the CRA will regulate software as done today with hardware from a Security perspective, which means that any software on the market will fall under regulation and security demands. And of course, as every software project today mostly consists of Open Source Software (70%-90%), it will have effects on Open Source Software consumers (and producers). In the first drafts, there were many potential problems, but the Security and Open Source Community has together reworked the wordings, so it will (could be) even something beneficial to Open Source, as projects relying on releasing products to the market will also be responsible to report and avoid (fix?) vulnerabilities. This will not be the responsibility of the Open Source projects themselves. But if you are a commercial actor, this will apply.

But, as of yet, there are many things that will be interesting to see how it plays out in practice here - how will a vendor commercial product make the Open Source project they are using make the project fix the vulnerabilities? Will the vendor fund a fix for the Open Source project? Will they submit a patch? If the project maintainer does not want to fix any issues regardless, will the vendor and maintain, rewrite or what? In my simplified take, I can see that the CRA is a tough and expensive coming-of-age regulation regarding security responsibility for software for commercial vendors and commercial producers. But, as a potentially good thing for Open Source Security and trust, funding and maintenance in the long term. There will be learning pains as such, but in the end, I'm quite positive for what this might mean for Open Source. We will see.

So, For us as citizens and end consumers, I believe this is a good thing.

CRA is one example of where policymakers and the real-world communities have worked together to improve the policies, and all parts have done a great job in the end. I applaud unsung heroes here, thanks! Now there will be other up-and-coming policies - like the Interoperable Act - where it is very important to have these discussions and feedback loops between policymakers and communities/producers as we go along. With parts of the EU Commission OSPO in place and other important key players, with the lessons learned from the CRA, and the open discussions, I feel trust in that coming policies will be open to being beneficial to both the EU's digital strategy as a whole and the Open Source community's ecosystem in specific. And where it really counts, for us as citizens and end consumers - us the citizens - as intended.

See a presentation and overview about CRA [here](https://fosdem.org/2024/schedule/event/fosdem-2024-3683-the-regulators-are-coming-one-year-on/) and deep dive into EU Open Source Policy details [here](https://fosdem.org/2024/schedule/track/eu-policy/).

## SBOMS, Vulnerabilities Handling, and License Compliance

In recent years, we have been talking about Software Bill of Materials - this is in demand by the industry, will be even more in demand by upcoming regulations like CRA, among others. Roughly, it is a component catalog that can be automated and used to check vulnerabilities and license compliance - if the product is the sum of its parts, then this is mostly about declaring the parts in an automated way and, by that way, handle vulnerabilities and license compliance. While it might seem like a simple problem at first, it is not - in fact, a complicated matter, with many interesting real-world challenges to solve. Even if a lot of work has been done, and a lot of effort has gone into creating Open Source tooling and practices, it will take time to get this right.

Producing an SBOM is in no way a magical security ticket; - How do we get organizations to handle the vulnerabilities quickly, what vulnerabilities should be handled, and what SBOMs are you talking about when you say SBOM - the build, runtime, the container SBOM or what? How far the transient dependency tree should we walk, how do we handle that package managers handle dependencies differently, how do we handle that different tools report different SBOMs, what do we do we all the SBOMS and so on, and so on.

Have a look at some of the talks (there are videos for most) [here](https://fosdem.org/2024/schedule/track/software-bill-of-materials/).

## Public Code and Digital Public Goods

Another fully packed room - yet again, glad to see this - was the talks about Public Code - in brief, code that implements public policy, used for the public good, and by public organizations like governments, public administrations, etc.

I like the notation of Digital public goods (DPGs) - an umbrella term for open-source software, open standards, open data, open AI systems, and open content collections. This helps us focus on fewer silos, and see that Open-topics are siblings.

I listened to updates about how Public Code is both heading along and meeting new challenges in Germany, and especially Germany's [Sovereign Tech Fund](https://www.sovereigntechfund.de/) should be an inspiration for other member states. Basically, it is Germany funding important Open Source Projects. Here is the [Public Code in Germany talk](https://fosdem.org/2024/schedule/event/fosdem-2024-2818-some-updates-on-public-code-in-germany/).

[Other Public Code And DPG Talks (video stream)](https://fosdem.org/2024/schedule/track/public-code-and-digital-public-goods/).

## Communities

The community for a product is an important part - for what use is a dead piece of undocumented code repository if it does not solve someone's problem in an easy to understand way (answer: worthless)? So even if community building is not where my own heart lies at in Open Source, (My heart is in making it easy to release, contribute and comply with sec and licensing, knowledge sharing) and truly and fully understand the importance of it.

I was only briefly in here to feel the positive collaboration spirit, but one of the aspects lifted was funding - it is as important as ever, and still an unsolved issue in Open Source - and a great inspiration has been the work of Germany as mentioned above in the Public Code room, a work more states should follow.

[Other Community Talks](https://fosdem.org/2024/schedule/track/community/).

## Java

With the recent releases of Java, the Java world is getting exciting again, that has been my opinion for the latest years. I went to a few Java talks, an overview of Quarkus and GraalVM to build native binaries (without JVM) and to a deep dive into Virtual Threads. While Native Java is exciting I would currently not offer it as the main release artifact of my system, but as an experimental side artifact and a companion to the main artifact.

Virtual Threads are basically lightweight threads, instead of system threads. Something other languages have had for quite a time, think async/await in JS, coroutines in Kotlin, and so on for inspiration. Brian Goetz (Architect for the Java Language at Oracle, and master of concurrency in Java) a while ago said "I think Project Loom (virtual threads) is going to kill Reactive Programming". And I do think I agree with him. Reactive has always felt like forcing in a different paradigm in Java with a shoehorn, and from our real-life experiment with it in my last organization, it was easy to create hard-to-catch bugs in production, which ultimately led us to abandoning it for a Keep-it-simple-practice instead (and also, we headed for Kotlin and Coroutines at the time). Virtual Threads solve roughly the same async problem space in a much elegant and maintainable way. I would recommend anyone on the Reactive train in the Java world to start looking at Virtual Threads instead.

[Other Java talks](https://fosdem.org/2024/schedule/track/free-java/).

## Go

Recently, I have dug into the Go-lang world and will soon hopefully have one or two tools to release, written in Go-lang. "Soon":) Actually, I'm a bit obsessed with Go-lang at the moment.
So I hung around on a few Go-lang talks.

News in Golang 1.2x - and here, as promised - Go-lang evolves slowly. So while no revolutionary additions, but minor good things like min, max etc [here](https://antonz.org/go-1-22/).

I also got my eyes  on [GoReleaser](https://goreleaser.com/), which I will use in my (Go) projects.

[Other Go talks](https://fosdem.org/2024/schedule/track/go/).

## What I Missed

A lot of talks, talking to you, and filter coffee! 

Besides that, I said hi to some old and some new faces, had a couple of Belgian beers and mussels, and just had a great time. As always at FOSDEM!

So that's all. Today, I'm just processing the whole experience and loading up the batteries.