Topics Version control O que é Inner Source?

O que é Inner Source?


Inner Source é uma estratégia de desenvolvimento de software na qual as empresas adotam uma abordagem e cultura de código aberto para colaborar de forma mais eficaz.

O que significa Inner Source?

Inner Source é uma tendência crescente encontrada em equipes de desenvolvimento e engenharia de alto desempenho que adotam processos de código aberto para trabalhar e colaborar de forma mais eficaz. Quando as equipes usam o Inner Source, elas desenvolvem software proprietário e abrem o trabalho internamente entre as equipes para que todas as pessoas envolvidas, de desenvolvedores a gerentes de produto, possam contribuir para o código-fonte.

Inner Source é uma estratégia de desenvolvimento de software que aplica práticas de código aberto ao código proprietário. O Inner Source pode ajudar a estabelecer uma cultura de código aberto dentro de uma empresa, mantendo o software para uso interno. As equipes usam o Inner Source para aumentar a visibilidade, fortalecer a colaboração e eliminar silos.

Ao definir o padrão como aberto em projetos internos dentro de uma empresa, as equipes podem permitir a reutilização de soluções atuais e minimizar a redundância, promover a [colaboração entre equipes]/topics/version-control/software-team-collaboration/){data-ga-name="team collaboration" data-galocation="body"} e aproveitar os talentos de toda a força de trabalho. Empresas de qualquer porte se beneficiam do Inner Source e podem incorporar continuamente práticas modernas de desenvolvimento de software, aprendendo com projetos de código aberto em grande escala.

Em empresas de grande porte, as equipes de desenvolvimento geralmente estão distribuídas entre diferentes departamentos ou fusos horários. Vários desenvolvedores podem nunca se encontrar ou ter acesso às mesmas estratégias departamentais. No entanto, com o Inner Source, eles podem se alinhar ao mesmo modelo de fluxo de trabalho, que tem se mostrado bem-sucedido em projetos de código aberto.

O caso do PayPal mostra como as práticas de desenvolvimento de código aberto tornam as empresas mais eficientes e lucrativas, mesmo que o componente "aberto" do "código aberto" varie dependendo do tamanho da equipe envolvida. Outras empresas pioneiras que escolheram a estratégia do Inner Source, como Bosch, Autodesk, Bloomberg e SanDisk, podem concluir projetos complexos e criar produtos inovadores por meio da implementação do mesmo sistema simples e de baixo custo utilizado no código aberto.

Por que as empresas querem funcionar como projetos de código aberto

Em sua essência, empresas de grande porte funcionam de forma semelhante a grandes projetos de código aberto. Em ambas as entidades, existem várias partes móveis: muitos colaboradores, diversas ferramentas e múltiplas diretivas e estratégias. Contudo, no modelo de negócios tradicional, uma empresa funciona seguindo orientações formuladas por uma hierarquia de líderes seniores. Em parte, a eficiência da empresa depende da capacidade dos gerentes de acompanhar grandes quantidades de informações recebidas.

A abundância de informações muitas vezes se afunila em um gargalo gerencial, por isso não é surpreendente que vários projetos possam ser negligenciados. À medida que os projetos se tornam mais complexos ou mais equipes se envolvem, mais tarefas provavelmente passarão despercebidas por algum tempo. Em projetos de código aberto, as informações relacionadas ao desenvolvimento são gerenciadas por meio de um processo de documentação e verificações projetado para evitar que os componentes sejam negligenciados ao longo do tempo.

As práticas de fluxo de trabalho de código aberto mais importantes para as empresas são:

  • Visibilidade
  • Forking
  • Solicitações de pull/merge
  • Teste
  • Integração contínua
  • Documentação
  • Rastreador de tíquetes

Ao adotar uma mentalidade de código aberto para o desenvolvimento de software, as empresas fecham lacunas e eliminam silos, levando a um ciclo de vida de desenvolvimento de software mais eficiente e uniforme. Além disso, abre caminho para uma experiência aprimorada do desenvolvedor, metodologias de desenvolvimento simplificadas e uma cultura de colaboração transparente.

Essa abordagem não apenas aumenta a velocidade do desenvolvedor, mas também promove uma colaboração mais próxima entre os principais membros da equipe em vários projetos de desenvolvimento.

Benefícios do Inner Source

Empresas que usam Inner Source experimentam benefícios típicos do desenvolvimento de código aberto, como:

  • Código de alta qualidade: com testes unitários, cobertura de código e integração contínua, as equipes melhoram a qualidade do código mais cedo no ciclo de vida.
  • Documentação abrangente: o código é melhor documentado, tanto em termos de comentários quanto de discussões mais informais, que constitui uma fonte única de referência e oferece maior transparência e conhecimento compartilhado.
  • Reutilização eficaz de código: o código e a arquitetura são facilmente detectáveis e estão disponíveis para a equipe e toda a empresa.
  • Colaboração sólida: as revisões de código encontram menos atrito, a comunicação se fortalece e as contribuições se tornam numericamente mais significativas.
  • Cultura saudável: os silos são removidos para que o desenvolvedor fique mais satisfeito com sua função, o que leva a melhores resultados de retenção e recrutamento.

Problemas que o Inner Source soluciona

Confira aqui alguns dos problemas que grandes empresas enfrentam com frequência e que o Inner Source pode ajudar a resolver.

Desafio Solução
Comunicação:  em grandes empresas, geralmente não há apenas uma equipe unificada trabalhando para alcançar um objetivo único. Em vez disso, os membros da equipe tendem a ser divididos em várias equipes desconectadas que têm suas próprias estruturas e liderança. As normas e terminologias de comunicação podem variar entre as equipes, e a comunicação e o compartilhamento de conhecimento são mínimos e ineficazes entre os silos. Os sistemas de código aberto permitem participação e contribuição em grande escala. As linhas de comunicação são diretas e visíveis para todos no projeto. As hierarquias de comunicação geralmente são planas, eliminando ruídos desnecessários e conectando as contribuições com as partes interessadas.
Descoberta: uma solução de software pode ser criada várias vezes em diferentes departamentos, o que essencialmente multiplica o esforço, apenas porque não há comunicação, transparência e colaboração entre eles. Muitas vezes, não há um processo para verificar se uma solução já foi criada. O benefício dos projetos de código aberto é que eles são transparentes por natureza. Se as equipes têm acesso ao projeto, podem pesquisar e determinar se existe uma solução para o problema que enfrentam. Se alguém não pesquisar antes de começar a trabalhar, outros colaboradores do projeto têm visibilidade total e podem identificar se uma solução já existe. Os projetos de código aberto aumentam a descoberta de soluções que já existem e reduzem esforços desnecessários.
Burocracia: na maioria dos ambientes comerciais, existem estruturas organizacionais que determinam o que os membros da equipe podem acessar. Um membro da equipe pode estar ciente de que existe uma solução, mas precisa solicitar o acesso ao projeto a um administrador, o que tira o foco do desenvolvedor e do administrador de tarefas importantes. Com projetos de código aberto, os membros da equipe têm acesso total para colaborar nos projetos ou visualizá-los. Essa visibilidade e acesso diminuem o trabalho administrativo e os atrasos que resultam do gerenciamento de solicitações de acesso.
Alterações: em um ambiente comercial tradicional, se as equipes têm acesso somente de leitura a um projeto, não têm a permissão ou a opção de editar ou adicionar um recurso e precisam pedir que outra pessoa faça isso. Se os responsáveis pelas alterações não tiverem tempo ou acharem que não há necessidade para alteração por não entenderem o motivo, os colaboradores ficam sem opções. A equipe responsável pelo aplicativo é encarregada de garantir que ele cumpra os prazos e funcione corretamente, portanto, o trabalho de alguém depende da manutenção desse aplicativo. Mesmo que outra equipe possa se beneficiar desse novo recurso, a solicitação para alterar o aplicativo pode interferir na sua estabilidade. Assim, é arriscado conceder o acesso. Se um desenvolvedor não tiver acesso para fazer as alterações necessárias, as equipes precisam criar seu próprio codebase ou aplicativo para resolver o problema, o que pode acontecer várias vezes, com várias pessoas enfrentando o mesmo problema. Isso faz com que muitos aplicativos sejam criados separadamente para resolver o mesmo problema. Se as equipes quiserem alterar um projeto de código aberto, não precisam pedir aprovação. Em vez disso, contribuem com a mudança e permitem que o sistema teste e valide sua funcionalidade. Na prática, as equipes criam um fork com o codebase, fazem as alterações e criam uma solicitação de merge para que o outro desenvolvedor possa verificá-la, fazer perguntas e testá-la. Os responsáveis por aceitar a solicitação de merge têm uma carga de trabalho reduzida em comparação com o outro cenário. Eles não precisaram fazer o trabalho extra sozinhos e, como o recurso já foi testado, sabem que ele funciona. Há também o benefício de que essa abordagem reduz a carga geral no gerador de relatórios, pois ele só precisa oferecer suporte a um único codebase em vez de oito.

Como as equipes podem usar o Inner Source

Para equipes que trabalham de forma colaborativa em diferentes fusos horários — o que é o caso da maioria das equipes hoje em dia — e empresas com vários departamentos, o Inner Source é uma maneira simples de criar um fluxo de trabalho mais eficiente. As equipes podem quebrar os silos de informações e incentivar que a colaboração entre toda a empresa seja mais eficaz. O Inner Source também pode ser usado para que o processo de integração do desenvolvedor seja mais rápido e pode incentivar os membros da equipe a retribuir à comunidade de código aberto com o software.

A implementação de projetos Inner Source significa substituir abordagens de desenvolvimento tradicionais por fluxos de trabalho mais dinâmicos, inclusivos e eficientes.

Conclusão

O Inner Source representa uma mudança fundamental na forma como as empresas abordam o desenvolvimento de software. Sua prática promete não apenas melhorar a qualidade e a segurança dos produtos de software, mas também ocasionar uma transformação cultural que posiciona as empresas para o sucesso. Ao utilizar as práticas do Inner Source, as empresas estão prontas para enfrentar os desafios de desenvolvimento de software modernos com agilidade, ao mesmo tempo em que promovem a inovação colaborativa para o crescimento dos negócios.

Quando as empresas consideram seu planejamento futuro, a adoção do Inner Source se destaca como um elemento estratégico essencial que as prepara para enfrentar desafios emergentes e aproveitar ao máximo novas oportunidades.

Saiba como GitLab simplifica o desenvolvimento de software

Tudo pronto para começar?

Descubra o que sua equipe pode fazer com uma plataforma DevSecOps unificada.