Alavancando Plataformas Internas Através do InnerSource

Autor: Arthur Fücher

Em grandes empresas, um desafio de desenvolvimento se destaca: equipes que trabalham isoladas, duplicando esforços e perdendo oportunidades de inovar juntas.

Uma pesquisa da McKinsey com as principais empresas de tecnologia reforça a necessidade de acabar com os silos de trabalho. O estudo mostrou que empresas de ponta têm mais que o dobro de chances de organizar suas equipes de engenharia em modelos de operação focados em produtos ou plataformas. Essa abordagem reduz o tempo de lançamento no mercado, diminui os custos das soluções de tecnologia e aumenta a responsabilidade compartilhada entre as áreas de negócio e tecnologia.

Esse cenário fica ainda mais evidente com a criação de plataformas e frameworks internos. Foi o caso do nosso Backend Driven Content (BDC) — uma plataforma sobre a qual temos um outro post no blog com mais detalhes — onde todo o desenvolvimento para celular passou a depender dela.

O que é InnerSource?

O termo foi criado por Tim O’Reilly, que o definiu como “o uso de técnicas de desenvolvimento de código aberto (“open source”) dentro de uma corporação, ou com um grupo de clientes chave — mesmo que eles não estejam prontos para liberar seu software como um projeto público de código aberto”.

Anos depois, em 2015, foi fundada a InnerSource Commons Foundation (ISC), dedicada a criar e compartilhar conhecimento sobre InnerSource: o uso das melhores práticas de código aberto para o desenvolvimento de software dentro dos limites de uma organização. No site, a definição de InnerSource é:

InnerSource aplica as lições aprendidas com o desenvolvimento de software de código aberto à forma como as empresas desenvolvem software internamente.

Vamos a um exemplo concreto: imagine que precisamos desenvolver uma nova tela de onboarding que exige um componente que ainda não foi implementado no framework interno da empresa.No modelo tradicional, você pediria para o time responsável pelo framework priorizar esse item no backlog e aguardaria até que fosse concluído.

Com InnerSource, o processo se transforma:

• O time responsável define o processo de contribuição.
• Desenvolvedores de outros times podem propor soluções e implementações.
• Revisões de código envolvem múltiplas perspectivas, melhorando a qualidade.
• Os componentes criados passam a estar disponíveis para reutilização em outros projetos.

Por que usar InnerSource?

O ISC faz uma pesquisa anual para entender o “Estado do InnerSource” (State of InnerSource). Em 2024, a pesquisa foi um questionário aberto por aproximadamente 12 semanas, entre novembro de 2023 e janeiro de 2024.

Segundo o relatório de 2024, cerca de 68% das organizações participam do InnerSource motivadas por: criar software reutilizável, eliminar silos e gargalos e/ou compartilhar conhecimento.

Para os indivíduos, os principais motivos são: compartilhar conhecimento (66% dos participantes), conhecer mais pessoas na organização (62%) e melhorar a qualidade do software em que trabalham (54%).

Como Estruturamos Nossa Abordagem

Ao construir a plataforma, mantivemos um dos valores principais do Nubank em mente: queremos que nossos clientes nos amem de forma fanática. Nesse caso, nossos “clientes” são os desenvolvedores internos. Essa distinção é importante — porque, embora não estejamos impactando diretamente os usuários finais do Nubank, a experiência que proporcionamos aos desenvolvedores permite que eles entreguem mais rápido, criem soluções melhores e proporcionem experiências incríveis para os nossos clientes.

Desde o começo, construímos essa plataforma em colaboração com nossas equipes internas. Ao tratá-las como verdadeiros parceiros — ouvindo o feedback e aprendendo com suas experiências — cultivamos um senso de comunidade e cocriação que moldou a solução em conjunto.

1. Processos de contribuição claros: Criamos fluxos padronizados para que qualquer pessoa pudesse propor melhorias, incluindo documentação, independente de sua equipe de origem. Isso reduziu a barreira entre uma ideia e sua implementação. Por exemplo, para migrar um componente Flutter para o BDC:

1. A pessoa que contribui precisa verificar se o componente realmente não existe.
2. Fornecemos uma ferramenta de linha de comando (CLI) para criar a maior parte do código padrão.
3. A pessoa faz as customizações finais.
4. Abre o Pull Request (PR) preenchendo o modelo.
5. Depois, abre um chamado (ticket) com os links dos PRs.

 Todos esses passos estão descritos no Guia de Contribuição na documentação oficial da plataforma BDC.

2. Senso de comunidade: Queremos que as pessoas se sintam à vontade para compartilhar suas ideias e feedback, ajudar umas às outras e contribuir para a plataforma.
3. Documentação aprimorada: As pessoas precisam poder aprender no seu próprio ritmo e ter autonomia para se aprofundar. Elas não podem depender apenas da equipe principal do projeto, pois isso não é escalável.
4. Funções dedicadas: A equipe, além das funções normais (Engenheiro de Software, Gerente de Equipe, Gerente de Produto), contava com uma Redatora Técnica e um Developer Advocate. Ter essas funções dedicadas ajudou a focar em diferentes áreas de forma especializada, como a promoção da cultura de InnerSource.

Resultados

Nossa comunidade interna de BDC já reúne cerca de mil desenvolvedores, com mais de 85% deles participando ativamente nas discussões. Além da atividade no canal, o impacto real aparece na forma como as equipes interagem com a plataforma.

Vimos uma adoção orgânica de mais de 90% entre as equipes, o que se traduz diretamente em mais contribuições e uma colaboração mais forte entre elas. Como resultado, os tempos de entrega melhoraram, já que os desenvolvedores não precisam esperar pela priorização da equipe principal para avançar.

Mais importante ainda, os dados dos chamados (tickets) destacam essa mudança: enquanto o número de contribuições aumentou de forma constante, os chamados para a equipe principal relacionados a bugs, falhas ou dúvidas diminuíram consistentemente ao longo do tempo. Essa tendência reforça como o InnerSource está reduzindo gargalos e impulsionando a autonomia.

O Que Vem Por Aí

O InnerSource provou seu valor, entregando os resultados que esperávamos e se consolidando como um padrão para projetos internos.

Hoje, nossa Plataforma de Experimentação também está usando o InnerSource para destravar projetos e funcionalidades, e diversas bibliotecas e projetos internos começaram a adotar a mesma abordagem.

Olhando para o futuro, estamos sempre aprimorando nossos processos, investindo em ferramentas que facilitam a colaboração e, o mais importante, cultivando uma cultura onde a troca de conhecimento é natural e valorizada.

Um dos próximos desafios é gerenciar o número crescente de contribuições. Um passo possível será adotar o padrão de “Trusted Committer”, dando a alguns colaboradores de fora da equipe principal a responsabilidade de aprovar ou rejeitar contribuições.