At DB, we handle 100,000+ SBOMs per day. For our small, virtual Open Source Program Office (OSPO), the challenge is not to get lost in the data, but to cut through the jungle and identify real risks. Together with my OSPO colleague Cornelius Schumacher, I presented this challenge at the FOSS Backstage conference in Berlin. We explained how we gather data, generate insights, and take action.
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.
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?
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.