Max Mehl (Ospo)

Getting Real with the Supply Chain: From SBOM Data to Action

Tue, 17 Mar 2026 00:00:00 +0000

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.

This talk was partly inspired by my earlier FOSDEM talks (here and there), where I focused on DB’s SBOM program and its tools. In this presentation, however, we highlighted what can be learned from it for professional Open Source management.

One topic stood out throughout the presentation: the need for an OSPO to balance between people, value, and risk. None of these should dominate, even though governance functions often tend to focus on risk. Instead, Cornelius and I advocated for a risk-based approach to managing Open Source.

Deutsche Bahn's Approach to Large-Scale SBOM Collection and Use

Sun, 01 Feb 2026 00:00:00 +0000

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.

I explained our approach to treating SBOMs as shared infrastructure rather than a goal in itself. SBOMs support multiple use cases: Open Source license compliance, security vulnerability checking, understanding component distribution, assessing quality, satisfying governance requirements, and supporting strategic decisions about ecosystem engagement. We heavily rely on FOSS tools enriched with our own logic to fit DB’s enterprise architecture. A key insight was the integration of VEX (Vulnerability Exploitability eXchange) with SBOMs – allowing us to track vulnerability status throughout processes and enabling manufacturers to communicate their assessments to us directly.

The presentation detailed our SBOM strategy and architecture built from scratch: starting with a small interdisciplinary volunteer group, iterating quickly with continuous feedback, focusing on existing organizational needs rather than abstract best practices, and documenting everything publicly. Our technical principles emphasized modularity, open standards, central SBOM storage with decentral sourcing and analysis. The SBOM Blueprint serves as our guiding star, implemented through prioritized increments. We started by focusing on Source/Build SBOMs for in-house developed software, creating low-threshold drop-in solutions for CI pipelines. But as I emphasized throughout: tools and clever ideas aren’t enough – we need people to integrate them, continuous quality monitoring, cooperation from related service operators, and support from governance stakeholders.

This presentation was a follow-up to my talk the day before on Deutsche Bahn’s overall software supply chain strategy in the context of the EU Cyber Resilience Act (CRA) – while that talk focused on the strategic rationale and high-level approach, this one dove into the technical architecture and practical lessons learned from our initial implementation. Together, they provided a comprehensive overview of how Deutsche Bahn is approaching software supply chain strategy in the context of CRA and beyond.

Software Supply Chain Strategy at Deutsche Bahn

Sat, 31 Jan 2026 00:00:00 +0000

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.

I outlined how we understand CRA as consisting of four activity areas: general principles of secure software (which we already do), professional handling of vulnerabilities (also already doing), transparency of software supply chains with SBOMs (the new challenge and focus of this talk), and information to users plus conformity assessments (out of scope but interesting). Deutsche Bahn’s challenge is particularly complex because we take on different roles – customer, manufacturer, and indirectly even steward – across our diverse operations. We build software for ourselves and external customers (ranging from operating systems in train displays to mobile apps), we buy software (local, on-premise, SaaS, bundled in hardware like trains), and we operate everything across multiple environments (on-premise, cloud, edge/embedded).

The strategy presentation emphasized how we created an SBOM architecture from scratch to handle this complexity. Working with a small interdisciplinary volunteer group, we focused on iterating quickly, gathering continuous feedback, and thinking in capabilities rather than specific tools. Our technical principles centered on modularity, open standards and interfaces, central SBOM storage with decentral sourcing and analysis – providing the flexibility needed to adapt to varying stakeholder needs and evolving regulations. The key message was that at DB’s scale and diversity, you cannot implement a one-size-fits-all solution overnight. Instead, we prioritize based on identified risks and external requirements, document everything publicly, and connect the concrete CRA compliance requirements with our broader effort to bring transparency to software supply chains. This transparency forms the basis not just for regulatory compliance, but for security processes, license compliance, and proactively shaping the Open Source ecosystems we depend on.

The day after, I gave a follow-up presentation on our large-scale SBOM collection and use, which dove deeper into the technical architecture and practical lessons learned from our initial implementation. The two talks together provided a comprehensive overview of how Deutsche Bahn is approaching software supply chain strategy in the context of CRA and beyond.

OSPOs as Sovereignty Engines

Fri, 30 Jan 2026 00:00:00 +0000

Delivering digital sovereignty requires more than regulation and investment – it depends on institutional capability. I’ve been invited to join a panel at the EU Open Source Policy Summit focusing on how large organisations, both public and private, are building the structures needed to adopt and sustain open approaches. We discussed the role of Open Source Programme Offices (OSPOs) as engines of institutional learning, collaboration, and governance, and the potential for a EU policy to accelerate this transformation. Drawing on examples from critical sectors – including energy, transport, and public administration – the discussion explored how organisational capacity can strengthen Europe’s digital resilience and enable openness at scale.

My main arguments were:

OSPOs are more than just a team for managing Open Source software – they are a strategic function that can drive cultural change, cross-functional collaboration, and ecosystem engagement across an organisation. They act as vertical and horizontal enablers.
In the debate around Digital Sovereignty, Open Source is a highly relevant option on the table, and goes far beyond “Buy European”. OSPOs can help organisations navigate the complex landscape of Open Source, build internal expertise, and foster partnerships that enhance sovereignty through openness.
OSPOs cannot drive this change alone. External support in the form of strategy, incentives and regulation is needed, especially for organizations under high regulatory pressure or with limited resources. This needs to be coherent vertically across the EU and horizontally across sectors.

It was a pleasure to elaborate this with my co-panelistzs Manuel Mateo Goyet (Acting Head of Unit CNECT.E.2, European Commission), Lucian Balea (Deputy Director of R&D and Open Source Director, RTE), Supriya Chitale (Open Source Program Office Manager, IKEA Group) and moderator Johan Linåker (Senior Researcher, Research Institutes of Sweden).

OpenRail Day 2025 Moderation

Wed, 17 Dec 2025 00:00:00 +0000

I had the pleasure to moderate the OpenRail Day 2025 in Paris, organised by the OpenRail Association to share knowledge and experiences about Open Source software in the railway industry. This event brought together railway operators, digital experts, and Open Source communities from across Europe for a day dedicated to showcasing concrete Open Source projects already at work in the railway sector. The conference featured demonstrations, presentations, and workshops around projects like OSRD (Open Source Railway Designer), RCM OSS, LibLRS, and the Netzgrafik-Editor, all hosted by the OpenRail Association.

The event created a space for dialogue between technical, institutional, and industrial stakeholders around key topics such as interoperability, open standards, and international collaboration. Speakers included leaders from major European railway companies like SBB, SNCF, Infrabel, and ONCF, as well as representatives from the European Commission’s Open Source Programme Office. This first edition laid the foundation for a format designed to evolve and establish itself over time, in service of a more open and collaborative digital railway ecosystem.

All session recordings, presentations, and photos are available in the event replay section.

The Burden of Knowledge: Dealing With Open Source Risks

Mon, 10 Mar 2025 00:00:00 +0000

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?

In this session, I focused on the strategic decisions organizations need to make when assessing risk in Open Source dependencies. Drawing from my experience at an organization using a six-digit number of Open Source packages, I explored the options between the extremes of “Let’s measure everything”, “Let’s avoid all risky Open Source”, and “Let’s not look at the data because it might scare off management”. I discussed how to decide whether to use a project, invest resources to support it, or move away from a dependency, and when it makes sense to actively engage with or withdraw from an Open Source project.

This talk provided an overview of feasible options and the foundation for a more informed discussion on managing Open Source risks strategically – without ignorance or fear.

The burden of knowledge: dealing with open-source risks (LWN.net)

Mon, 10 Mar 2025 00:00:00 +0000

My talk at FOSS Backstage (see earlier post) was also covered by LWN.net, in an article by Joe Brockmeier. It’s an extensive summary of the talk.

Organizations relying on open-source software have a wide range of tools, scorecards, and methodologies to try to assess security, legal, and other risks inherent in their so-called supply chain. However, Max Mehl argued recently in a short talk at FOSS Backstage in Berlin (and online) that all of this objective information and data is insufficient to truly understand and address risk. Worse, this information doesn’t provide options to improve the situation and encourages a passive mindset. Mehl, who works as part of the CTO group at DB Systel, encouraged better risk assessment using qualitative data and direct participation in Open Source.

[…]

You’re invited to read the full article.

Why DB Systel relies on Open Source for strategic collaboration

Sun, 01 Sep 2024 00:00:00 +0000

In this article, I explain why DB Systel relies on Open Source for strategic collaboration and how we approach Open Source at Deutsche Bahn. An essential tool for that is the OpenRail Association, a neutral platform for the railway industry to share and collaborate on Open Source software. The article also highlights the importance of community involvement and how DB Systel fosters a culture of openness and collaboration within the company.

Open Source software has become a must for any modern company. Anyone who operates a website, offers an app or even just uses servers is most likely using software components under Open Source licences. Many years ago, therefore, DB Systel decided to professionalise its use of Open Source.

You can read the full article on DB Systel’s website, see above.

Who are these Open Source maintainers, actually?

Tue, 14 May 2024 00:00:00 +0000

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.

The presentation highlighted the often-overlooked aspects of maintainership: responding to issues and pull requests, moderating discussions, ensuring code of conduct compliance, mentoring newcomers, designing roadmaps, and making strategic decisions. I also addressed the cultural and process differences between companies and Open Source communities – from hierarchical versus peer production models to the different resource availability and commitment structures. The key message: maintainers are not bosses but servants of their communities, and the true capital of an Open Source project lies not in the code, but in the people and community that keep it alive.

This talk emphasized that while maintainers differ in motivation, funding models, and governance structures, they share core characteristics: a high sense of responsibility, autonomous action, balance of interests, and servant leadership.

The Growing Importance of Software Bills of Materials (SBOM)

Wed, 29 Nov 2023 00:00:00 +0000

I have been invited to talk about Software Bills of Materials (SBOM) in SAP’s Open Source Way Podcast, hosted by Karsten Hohage and with SAP’s Sebastian Wolf as co-guest. We had an interesting conversation about the growing importance of SBOMs in the software industry and their role within Deutsche Bahn. We also discussed the limits of SBOMs and how they can be complemented with other approaches to better understand and manage risks.

In this episode, our host Karsten Hohage talks to Max Mehl and Sebastian Wolf about Software Bills of Materials or SBOMs. An SBOM is a detailed record of all components within a software application, including Open Source libraries, third-party dependencies and licenses. Max and Sebastian discuss the importance of SBOMs as well as some challenges and unanswered questions of the state of the art. They also speak with Karsten about SBOMs within SAP and Deutsche Bahn and the importance of SBOMs when it comes to Open Source.

You can listen to the episode on Apple Podcasts or on Spotify.

Freie Software bei der Deutschen Bahn

Wed, 15 Nov 2023 00:00:00 +0000

Im “Captain it’s Wednesday” Podcast von GNU/Linux.ch sprach ich mit Ralf Hersel über Freie Software bei der Deutschen Bahn. Das Gespräch fand rund ein Jahr nach meinem Wechsel von der FSFE zur DB Systel statt und bot eine gute Gelegenheit, über meine neue Rolle zu sprechen und zu reflektieren, wie ein großer Konzern wie die Deutsche Bahn mit Open Source umgeht. Der CIW-Podcast richtet sich an die deutschsprachige GNU/Linux- und Freie-Software-Community und behandelt regelmäßig technische und gesellschaftliche Themen rund um Freie Software.

Im Gespräch erzählte ich von meinem Werdegang – über 10 Jahre im FOSS-Umfeld, lange Zeit bei der FSFE mit politischer Arbeit, Öffentlichkeitskampagnen wie “Public Money, Public Code” und technischen Themen wie REUSE, und dann der Wechsel zur DB Systel im Herbst 2022. Ich beschrieb meine Rolle als Teil des virtuellen “Open Source Program Office” der Bahn, wo wir uns um alles rund um Open Source kümmern: von Einsatz und Contributions über Richtlinien und Beratung bis hin zur strategischen Ausrichtung mit dem Open Source Manifest der DB. Ein besonderer Schwerpunkt war die Gründung der OpenRail Association – eine Kollaboration mit anderen europäischen Bahnen zur gemeinsamen Entwicklung von Open Source für den Eisenbahnsektor.

Die Diskussion beleuchtete, wie die DB enorm viel Open Source einsetzt, in vielen Projekten als Contributor aktiv ist, eigene Software veröffentlicht und Mitglied in verschiedenen Foundations ist. Wir sprachen auch über die Herausforderungen eines so großen, föderierten Konzerns mit über 300.000 Mitarbeitenden und wie man versucht, Open-Source-Prinzipien in dieser Struktur zu verankern. Das Gespräch endete mit einem Aufruf an die Community: Contributions zu unseren Open-Source-Projekten sind willkommen, und wir suchen immer mehr Freie-Software-Enthusiasten, die bei der Bahn mitarbeiten möchten.

SBOMs – A Short Introduction

Tue, 10 Oct 2023 00:00:00 +0000

At OSPOlogy Live Frankfurt in October 2023, I gave an introduction to Software Bills of Materials (SBOMs) for the OSPO community. Everyone had heard of SBOMs by then – they seemed ubiquitous, with shiny tools sprouting up everywhere. But what were they actually all about? What were the real use cases? And what often caused practical applications to fail? This talk aimed to provide a common understanding without the marketing-speak.

The session covered the fundamental concepts of SBOMs, explored concrete use cases where they add value, and discussed the challenges organizations face when trying to implement them in practice. Drawing from my experience working with software supply chain transparency at Deutsche Bahn, I highlighted common pitfalls and offered practical insights for OSPOs looking to make sense of the SBOM landscape.

This was part of a two-day event hosted by SAP’s OSPO and co-organized with TODO Group, InnerSource Commons, LF Energy, OpenChain, SPDX, CHAOSS, and OpenSSF projects.

Was machen eigentlich Open-Source-Maintainer?

Wed, 27 Sep 2023 00:00:00 +0000

Auf dem 9. Bitkom Forum Open Source in Erfurt präsentierten Cornelius Schumacher und ich eine Erzählung über das Leben von Open-Source-Maintainern, strukturiert als Drama mit Happy End. Durch die Geschichte von “Alex”, einer fiktiven Entwicklerin, beleuchteten wir, was Maintainer wirklich antreibt, was sie jenseits des Programmierens tun und welchen Herausforderungen sie sich stellen müssen. Der Vortrag führte von der anfänglichen Motivation, ein neues Tool aus Leidenschaft und eigenem Bedarf zu schaffen, über das Wachstum zur respektierten Maintainerin mit Community-Building-Verantwortung bis hin zum Übergang der Rolle für die Nachhaltigkeit des Projekts.

Die Präsentation hob die oft übersehenen Aspekte der Maintainership hervor: Beantwortung von Issues und Pull Requests, Moderation von Diskussionen, Sicherstellung der Einhaltung des Code of Conduct, Mentoring von Neulingen, Gestaltung von Roadmaps und strategische Entscheidungen. Wir thematisierten auch die kulturellen und prozessualen Unterschiede zwischen Unternehmen und Open-Source-Communities – von hierarchischen versus Peer-Production-Modellen bis hin zu unterschiedlicher Ressourcenverfügbarkeit und Commitment-Strukturen. Die Kernbotschaft: Maintainer sind keine Chefs, sondern Diener ihrer Communities, und das wahre Kapital eines Open-Source-Projekts liegt nicht im Code, sondern in den Menschen und der Community, die es am Leben halten.

Der Vortrag betonte, dass Maintainer zwar in Motivation, Finanzierungsmodellen und Governance-Strukturen unterschiedlich sind, aber Kerncharakteristika teilen: hohes Verantwortungsbewusstsein, autonomes Handeln, Interessenausgleich und Servant Leadership.

Public Money, Public Code pushes for governments to switch to open-source software (Sharable)

Wed, 09 May 2018 00:00:00 +0000

In an extensive interview with Shareable, I explained the goals of the FSFE’s “Public Money, Public Code” campaign: All publicly funded software should be released under Free Software licenses so governments and citizens can use, study, share and improve it. Addressing technical challenges like proprietary document formats and interoperability, I emphasized:

The more Free Software there is, the easier it gets to create and use it. It’s just a matter of starting that process.

The benefits are manifold: saving time, reducing costs, more collaboration, transparency, interoperability, innovation, and independence from software vendors. On the often-cited security concerns, I explained:

It’s actually better for security if software is transparent and the source code is published, because it’s easier for security experts to see what’s going wrong in the software. Malicious people will figure it out anyway, but more people can review the code. We’ve seen this with Linux. It is stable, secure and transparent, and we don’t see a disadvantage in the fact that it’s Open Source.

I highlighted Barcelona as a role model, spending 70% of its software budget on Open Source and understanding it’s not just about using Free Software, but procuring it in ways that allow regional and smaller vendors to participate.

The full interview with more details on transparency, collaboration and international examples is available on Shareable.