Deutsche Bahn

O Expresso InnerSource: impulsionando a colaboração em software na Deutsche Bahn

Resumo

Quando implementado de forma eficaz, o InnerSource pode gerar um enorme valor em uma empresa ao promover a colaboração, melhorar a transparência e aumentar a eficiência. O InnerSource não se limita ao código de software: pode ser aplicado a qualquer conteúdo ou processo em que a colaboração e a responsabilidade compartilhada sejam benéficas.

Na Deutsche Bahn (DB), o InnerSource desempenhou um papel fundamental na transformação do desenvolvimento de software em suas subsidiárias. Com mais de 50.000 repositórios Git ativos e 10.000 usuários do GitLab, a DB identificou uma oportunidade de fortalecer a colaboração entre equipes e subsidiárias. Ao introduzir o InnerSource, a DB:

• Criou uma cultura de colaboração entre unidades de negócio e equipes técnicas.
• Reduziu os custos ao permitir a reutilização de componentes de software e padronizar a infraestrutura.
• Melhorou a qualidade do software por meio de feedback coletivo e acompanhamento de problemas.
• Aumentou a transparência no desenvolvimento e na governança dos projetos.

Contexto

Como uma das maiores operadoras ferroviárias da Europa, a DB possui um ecossistema tecnológico amplo e complexo. A empresa gerencia o desenvolvimento de software em centenas de subsidiárias, cada uma funcionando como uma entidade independente, com sua própria infraestrutura, contratos e requisitos regulatórios. Historicamente, essa estrutura gerou ineficiências, duplicação de trabalho e dificuldades de colaboração entre equipes.

Reconhecendo o potencial do InnerSource para enfrentar esses desafios, a DB Systel, parceira de TI da DB, iniciou uma transformação InnerSource. Essa jornada envolveu soluções técnicas e também mudanças culturais e organizacionais significativas para incentivar a abertura, a reutilização e o compartilhamento de conhecimento.

A jornada InnerSource da DB começou ainda em 1999 com a introdução do Java, seguida pela criação de uma biblioteca compartilhada de componentes em 2002. Em 2006, a direção determinou a publicação dos projetos internos da DB Systel como InnerSource, marcando uma mudança formal rumo à colaboração aberta. A iniciativa ganhou força em 2011 com um workshop de seis semanas que resultou em avanços significativos no InnerSource. Em 2021, reconhecendo a necessidade de uma governança estruturada, foi criada uma equipe dedicada ao tema InnerSource dentro da Architecture Guild para promover sua adoção em toda a organização.

Problemas a resolver

1. Desenvolvimento em silos entre as empresas do grupo

Desafio: A DB é composta por aproximadamente 500 subsidiárias, cada uma funcionando como uma entidade jurídica própria. Isso dificultava o compartilhamento de código entre equipes da organização devido a barreiras regulatórias e contratuais.

Solução: A DB desenvolveu a DB Innersource License (DBISL), que permite legalmente o uso interno livre, a modificação e a redistribuição de software dentro da DB. Também foi introduzido um conjunto de ferramentas contratuais, permitindo integrar o InnerSource facilmente aos contratos de prestação de serviços.

Um exemplo de como a DBISL facilita a colaboração é seu papel na viabilização do projeto DBContainerLib. Como a DB reúne várias subsidiárias, cada uma com suas próprias práticas de desenvolvimento de software, antes era difícil compartilhar imagens Docker padronizadas e prontas para produção. Com a DBISL, equipes de diferentes subsidiárias puderam usar, modificar e contribuir livremente para o DBContainerLib, garantindo uma imagem base consistente e de alta qualidade para serviços em produção.

2. Financiamento e infraestrutura para projetos InnerSource

Desafio: Muitos projetos InnerSource surgiram organicamente a partir de iniciativas das próprias equipes, mas era difícil garantir infraestrutura e financiamento para esses projetos mantidos pela comunidade.

Solução: A DB criou o InnerSource Hub, uma plataforma com financiamento centralizado que oferece repositórios GitLab, pipelines de CI e repositórios de artefatos. Isso permitiu aos desenvolvedores contribuir para projetos InnerSource sem se preocupar com os custos de infraestrutura.

Na última atualização registrada, o InnerSource Hub hospeda vários projetos InnerSource mantidos pela comunidade, incluindo DBContainerLib, PipeShip e K8S Setup. O modelo de financiamento centralizado reduziu os custos de infraestrutura desses projetos, eliminando a necessidade de cada equipe obter seus próprios pipelines de CI/CD e repositórios de artefatos.

3. Incerteza e resistência cultural

Desafio: Apesar dos fundamentos técnicos e jurídicos, muitos desenvolvedores hesitavam em compartilhar seu código, questionando se a liderança realmente apoiava o InnerSource.

Solução: Para resolver isso, a Architecture Guild introduziu um princípio arquitetural de InnerSource, invertendo a expectativa padrão: agora as equipes precisam justificar por que não utilizam InnerSource. Esse modelo de governança deu aos desenvolvedores a segurança de que o InnerSource não era apenas permitido, mas ativamente incentivado.

Os desenvolvedores relataram maior confiança para compartilhar seu código desde a introdução do princípio arquitetural de InnerSource. Muitos hesitavam inicialmente por receio da análise de seu código, mas, com o InnerSource como padrão, mais equipes começaram a abrir seus repositórios. Um exemplo relevante é o Architecture Guild Microsite, no qual as equipes agora contribuem ativamente com melhorias na documentação, garantindo uma base de conhecimento em evolução contínua.

Fundamentos e implementação

Após resolver os desafios fundamentais, a DB Systel se concentrou em tornar o InnerSource acessível e sem obstáculos para as equipes. Isso incluiu:

• Estabelecer diretrizes claras de contribuição para garantir uma colaboração fluida.
• Oferecer infraestrutura e financiamento centralizados por meio do InnerSource Hub.
• Organizar ações de capacitação e divulgação do InnerSource para integrar as equipes e incentivar sua participação.
• Utilizar boas práticas de InnerSource da comunidade de código aberto para orientar a adoção.

InnerSource em ação: projetos principais

Várias iniciativas InnerSource de alto impacto na DB demonstram o sucesso dessa abordagem:

1. DBContainerLib

Uma coleção de imagens Docker prontas para produção, mantida pela comunidade.

Principais benefícios:

• Redução de custos: elimina a necessidade de cada equipe criar e manter suas próprias imagens.
• Melhoria da qualidade: contribuições de diversos especialistas aprimoram a segurança e a conformidade.
• Colaboração entre equipes: utilizado em várias subsidiárias, promove a colaboração.

O DBContainerLib se tornou um recurso essencial na Deutsche Bahn: somente suas imagens baseadas em Java chegam a aproximadamente 700.000 downloads por ano. O projeto foi amplamente adotado por diferentes equipes, garantindo aplicações em contêineres padronizadas e de alta qualidade em toda a organização.

2. PipeShip

Um framework modular de pipelines de CI/CD do GitLab mantido por uma equipe de plataforma.

Principais benefícios:

• Maior qualidade: o feedback dos usuários é incorporado diretamente por meio de solicitações de merge.
• Desenvolvimento mais rápido: as equipes podem corrigir problemas imediatamente e contribuir com melhorias.

3. K8S Setup

Um projeto de infraestrutura como código baseado em Helmfile que simplifica a configuração de namespaces do Kubernetes.

Principais benefícios:

• Economia de tempo: modelos padronizados aceleram a adoção do Kubernetes.
• Transparência: a criação de forks permite que as equipes personalizem as implantações mantendo a consistência.

Antes da introdução do K8S Setup, as equipes enfrentavam atrasos significativos na configuração de namespaces do Kubernetes, frequentemente precisando de dias para configurar a infraestrutura manualmente. Com a solução Helmfile baseada em InnerSource, novos namespaces agora podem ser implantados em poucas horas, melhorando consideravelmente a eficiência da integração para as equipes de DevOps.

4. Architecture Guild Microsite

Um repositório de documentação que segue a abordagem “Docs as Code”.

Principais benefícios:

• Transparência: as equipes podem acompanhar e contribuir para boas práticas arquiteturais em constante evolução.
• Colaboração: a participação aberta melhora a qualidade e a precisão da documentação.

Planos futuros

Para o futuro, a DB pretende:

• Ampliar a participação no InnerSource para além das equipes de software, incluindo processos de negócio e documentação.
• Continuar aprimorando as estruturas de governança para garantir um crescimento sustentável.
• Identificar outros projetos InnerSource que possam passar a ser de código aberto.

À medida que o InnerSource continua evoluindo na Deutsche Bahn, a empresa mantém seu compromisso de promover uma cultura de colaboração, transparência e inovação em escala.