At FOSDEM 2026, I presented Deutsche Bahn’s journey from operational need to concrete implementation of large-scale SBOM collection and use. The scale is staggering: approximately 500,000 SBOMs across our software supply chain expected, covering 7,000+ IT applications, 100,000+ Open Source components, and diverse sourcing streams from software we build ourselves to what we buy and operate. The talk focused on how we moved from understanding that “we need to know, in real-time, which exact component is used where and how” to actually making this happen in an organization with 220,000+ employees and hundreds of subsidiaries.
At FOSDEM 2026, I presented Deutsche Bahn’s software supply chain strategy in the context of the EU Cyber Resilience Act (CRA), but made clear from the start that CRA was the context, not the trigger. We didn’t adopt SBOMs because of regulation – regulation validated the direction we were already taking based on operational needs. The presentation positioned our work at the intersection of CRA compliance requirements, IT operation best practices, and the practical realities of running IT infrastructure for an organization with 220,000+ employees, 7,000+ IT applications, and 100,000+ Open Source components.
In the 45th episode of the FSFE Software Freedom Podcast, I joined Alexander Sander and Bonnie Mehring to discuss what is hopefully the final chapter of the EU Radio Equipment Directive (RED). This was a fitting conversation on the way to FOSDEM 2026, reflecting on nearly a decade of work to protect Free Software on radio devices. The discussion traced the complete arc of this campaign, from my initial discovery of the problematic Article 3(3)(i) back in 2015 to the final stages of (non-)implementation in 2025.
At FOSS Backstage 2025 in Berlin, I explored a critical challenge facing OSPOs and development teams: as we increase analysis of our software supply chains, tools and scorecards reveal potential risks in Open Source projects like low maintenance, lack of community, or poor security practices. But this data alone doesn’t help if it merely points out potential problems without offering solutions. The question is: how should we handle this burden of knowledge? Through manual reviews? Questionnaires? Funding? Or should we look away?
I own and manage 30+ domains at INWX, a large and professional domain registrar. Although INWX has a somewhat decent web interface, it became a burden for me to keep an overview of each domain’s sometimes dozens of records. Especially when e.g. changing an IP address for more than one domain, it caused multiple error-prone clicks and copy/pastes that couldn’t be reverted in the worst case. This is why I created INWX DNS Recordmaster which I will shortly present here.
At Siemens Open Source 2024, I presented a narrative journey through the life of an Open Source maintainer, structured as a five-act drama with a happy ending. Through the story of “Alex”, a fictional developer, I explored what really drives maintainers, what they actually do beyond writing code, and the challenges they face when interacting with corporate structures. The talk moved from the initial motivation of creating a new tool driven by passion and intrinsic needs, through the growth into respected maintainership with community building responsibilities, to the eventual transition of passing on the role to ensure project sustainability.
