Como implementar o InnerSource na sua empresa: benefícios, desafios e melhores práticas.

Open Source é um modelo de trabalho importante na indústria de desenvolvimento de software hoje em dia. É muito ineficiente, se não impossível, desenvolver software sem ele. Existem alguns projetos de código aberto muito bem-sucedidos e muitas áreas tecnológicas são até dominadas pelo código aberto, como big data, aprendizado de máquina, Internet das coisas. Portanto, poderia fazer sentido analisar mais detalhadamente como as comunidades de código aberto trabalham e tentar aprender com as suas melhores práticas. É isso que o InnerSource faz.

InnerSource é a prática de aplicar o método e as melhores práticas de código aberto para o desenvolvimento de software interno. Seu objetivo é melhorar os processos de desenvolvimento internos com base nas aprendizagens do estilo de colaboração de código aberto.

Alguns dos benefícios deste estilo de trabalho, herdados do código aberto, são:

• Menor tempo de chegada ao mercado em características e correções de erros: os consumidores desempenham um papel mais ativo no desenvolvimento do software que lhes é fornecido através de contribuições. Com a capacidade adicional de contribuições, as características e correções de erros podem ser entregues mais cedo.


• Rastreabilidade: ao utilizar um rastreamento de erros e uma lista de tarefas públicos internos, a comunicação escrita é incentivada nesses sistemas. A comunicação escrita leva a uma documentação mais rastreável sobre o design do software e as decisões.


• Segurança através da transparência: o código fonte está aberto internamente para inspeção, o que significa que as vulnerabilidades podem ser detectadas mais cedo pela comunidade.

Neste post do blog, exploraremos mais detalhadamente o modelo de trabalho do InnerSource, bem como discutiremos seus desafios e as ações que estamos tomando para torná-lo bem-sucedido na SAP.

Como o InnerSource funciona

Em um modelo de desenvolvimento tradicional, uma equipe de desenvolvimento (chamada de "Fornecedor de Serviços" na imagem abaixo) desenvolve e fornece um componente ou serviço de reutilização aos seus consumidores, por exemplo, outras equipes de desenvolvimento que utilizam esse componente ou serviço para seus projetos.

Uma equipe consumidora envia relatórios de erros e solicitações de características para a equipe fornecedora. A equipe fornecedora desenvolve correções de erros e características em conformidade, que por sua vez são consumidas pela equipe consumidora.

Dado que tipicamente não há apenas uma equipe consumidora, mas muitas, a equipe fornecedora recebe muitas solicitações de características e relatórios de erros. Devido às suas limitações de recursos, as solicitações precisam ser priorizadas e nem todas podem ser entregues a tempo. Isso, por sua vez, cria desafios para os consumidores. Alguns deles podem decidir não usar o componente de reutilização das equipes fornecedoras, mas desenvolver uma funcionalidade similar por conta própria. Isso significa trabalho duplicado, competição desnecessária e projetos redundantes e, portanto, é o oposto da reutilização.

Em um modelo de InnerSource, a equipe fornecedora abriria o projeto de reutilização para contribuições das equipes consumidoras. Essas equipes poderiam contribuir com correções de erros e características por conta própria, em vez de apenas relatar erros e solicitar características.

Nesse modelo, não é necessário que as equipes consumidoras abandonem o componente de reutilização da equipe fornecedora para criar uma funcionalidade similar. Em vez disso, elas poderiam apoiar a equipe fornecedora contribuindo diretamente para as características solicitadas, o que seria mais econômico em termos de esforço para ambas as partes, e tornaria o componente de reutilização mais versátil e melhor reutilizável para outras equipes também.

Para as equipes consumidoras, essa abordagem geralmente leva a uma maior satisfação, pois estão ativamente envolvidas e a uma maior motivação, pois podem influenciar o projeto de reutilização. Também obtêm as características e correções de erros necessárias mais rapidamente.

Benefícios do InnerSource

Basicamente, InnerSource significa desenvolver mais em comunidades e de forma colaborativa do que em equipes de projetos dedicadas. Embora essas equipes também existam em uma abordagem de InnerSource e, dependendo da governança e do modelo de colaboração do projeto, ainda possam ter a responsabilidade geral do projeto, não são as únicas a contribuir para o projeto. Na verdade, há uma comunidade mais ampla de engenheiros desenvolvendo colaborativamente um projeto.

Esta abordagem tem certos benefícios. Alguns deles, como menor tempo de chegada ao mercado, colaboração mais estreita entre fornecedores e consumidores e maior segurança através da transparência, já foram mencionados, mas há mais.

A maior colaboração é um valor importante por si só. O conhecimento entre equipes e unidades de negócios (também conhecidas como "silos") é distribuído e a colaboração entre unidades é aumentada. De acordo com a lei de Conway (ver [9]), isso ajuda a construir um software melhor (integrado).

Tipicamente, os projetos de InnerSource também têm uma qualidade superior. Isso ocorre porque requer uma boa documentação para manter baixos os obstáculos para os contribuintes externos. Isso também facilita a integração de novos membros na equipe do projeto. Além disso, o alto grau de automação de testes exigido pelo InnerSource ajuda a melhorar a qualidade.