Deutsche Bahn

The InnerSource Express: Driving Software Collaboration at Deutsche Bahn

Summary

When implemented effectively, InnerSource can unlock immense value within an enterprise by fostering collaboration, improving transparency, and increasing efficiency. InnerSource is not limited to software code, it can be applied to any content or process where collaboration and shared ownership are beneficial.

At Deutsche Bahn (DB), InnerSource has played a key role in transforming software development across its subsidiaries. With more than 50,000 active Git repositories and 10,000 GitLab users, DB recognized an opportunity to enhance collaboration across teams and subsidiaries. By introducing InnerSource, DB has:

Created a culture of collaboration across business units and technical teams.
Reduced costs by enabling the reuse of software components and standardizing infrastructure.
Improved software quality through collective feedback and issue tracking.
Increased transparency in project development and governance.

Background

As one of Europe’s largest railway operators, DB has a vast and complex technology ecosystem. The company manages software development across hundreds of subsidiaries, each operating as an independent entity with its own infrastructure, contracts, and regulatory considerations. Historically, this structure led to inefficiencies, duplication of work, and difficulties in cross-team collaboration.

Recognizing the potential of InnerSource to address these challenges, DB’s IT partner, DB Systel, initiated an InnerSource transformation. This journey involved not only technical solutions but also significant cultural and organizational changes to encourage openness, reuse, and knowledge sharing.

DB’s InnerSource journey began as early as 1999 with the introduction of Java, followed by the creation of a shared component library in 2002. In 2006, management issued an order to publish DB Systel’s internal projects as InnerSource, marking a formal shift towards open collaboration. The initiative gained momentum in 2011 with a six-week workshop that led to significant InnerSource development. By 2021, recognizing the need for structured governance, the InnerSource topic team was formed under the Architecture Guild to drive adoption across the organization.

Problems to Be Solved

1. Siloed Development Across Business Enterprises

Challenge: DB consists of approximately 500 subsidiaries, each functioning as its own legal entity. This made it difficult for teams to share code across the organization due to regulatory and contractual barriers.

Solution: DB developed the DB Innersource License (DBISL), which legally enables free internal use, modification, and redistribution of software within DB. Additionally, a contract toolkit was introduced, allowing InnerSource to be seamlessly integrated into service agreements.

One example of DBISL facilitating collaboration is its role in enabling the DBContainerLib project. Since DB consists of multiple subsidiaries, each with its own software development practices, sharing standardized, production-ready Docker images was previously difficult. With DBISL in place, teams across different subsidiaries could freely use, modify, and contribute to DBContainerLib, ensuring a consistent and high-quality base image for production services.

2. Funding and Infrastructure for InnerSource Projects

Challenge: Many InnerSource projects emerged organically from grassroots efforts, but securing infrastructure and funding for these community-maintained projects was difficult.

Solution: DB established the InnerSource Hub, a centrally funded platform providing GitLab repositories, CI pipelines, and artifact repositories. This allowed developers to contribute to InnerSource projects without worrying about infrastructure costs.

As of the last recorded update, the InnerSource Hub hosts multiple community-maintained InnerSource projects, including DBContainerLib, PipeShip, and K8S Setup. The centralized funding model has reduced infrastructure costs for these projects, eliminating the need for individual teams to secure their own CI/CD pipelines and artifact repositories.

3. Uncertainty and Cultural Resistance

Challenge: Despite the technical and legal foundations, many developers were hesitant to share their code, questioning whether InnerSource was truly supported by leadership.

Solution: To address this, the Architecture Guild introduced an InnerSource architectural principle, flipping the default expectation: teams must now justify why they are not using InnerSource. This governance model reassured developers that InnerSource was not just allowed but actively encouraged.

Developers have expressed increased confidence in sharing their code since the introduction of the InnerSource architectural principle. Many initially hesitated due to concerns over code scrutiny, but with InnerSource as the default, more teams have started opening their repositories. A notable example is the Architecture Guild Microsite, where teams now actively contribute documentation improvements, ensuring a continuously evolving knowledge base.

Foundations & Implementation

With the foundational challenges addressed, DB Systel focused on making InnerSource accessible and frictionless for teams. This included:

Establishing clear contribution guidelines to ensure smooth collaboration.
Providing centralized infrastructure and funding through the InnerSource Hub.
Organizing InnerSource training and advocacy efforts to onboard teams and encourage participation.
Leveraging InnerSource best practices from the open-source community to guide adoption.

InnerSource in Action: Key Projects

Several high-impact InnerSource initiatives at DB highlight the success of this approach:

1. DBContainerLib

A community-maintained collection of production-ready Docker images.

Key Benefits:

Cost Reduction: Eliminates the need for every team to build and maintain their own images.
Quality Improvement: Contributions from diverse experts enhance security and compliance.
Cross-Team Collaboration: Used across multiple subsidiaries, fostering collaboration.

DBContainerLib has become an essential resource within Deutsche Bahn, with its Java-based images alone reaching approximately 700,000 downloads per year. The project has seen broad adoption across different teams, ensuring standardized, high-quality containerized applications throughout the organization.

2. PipeShip

A modular GitLab CI/CD pipeline framework maintained by a platform team.

Key Benefits:

Increased Quality: User feedback is directly incorporated via merge requests.
Faster Development: Teams can immediately fix issues and contribute improvements.

3. K8S Setup

A Helmfile-based infrastructure-as-code project that simplifies Kubernetes namespace setup.

Key Benefits:

Time Savings: Standardized templates accelerate Kubernetes adoption.
Transparency: Forking enables teams to customize deployments while maintaining consistency.

Before the introduction of K8S Setup, teams faced significant delays in configuring Kubernetes namespaces, often requiring days to manually set up infrastructure. With the InnerSource-driven Helmfile solution, new namespaces can now be deployed in just a few hours, drastically improving onboarding efficiency for DevOps teams.

4. Architecture Guild Microsite

A documentation repository following the “Docs as Code” approach.

Key Benefits:

Transparency: Teams can track and contribute to evolving architectural best practices.
Collaboration: Open participation improves documentation quality and accuracy.

Future Plans

Looking ahead, DB aims to:

Expand InnerSource participation beyond software teams to include business processes and documentation.
Continue refining governance structures to ensure sustainable growth.
Identify additional InnerSource projects that could transition to Open Source.

As InnerSource continues to evolve at Deutsche Bahn, the company remains committed to fostering a culture of collaboration, transparency, and innovation at scale.