O desenvolvimento de software sempre foi um processo com muitos desafios. À medida que uma organização cresce é importante trabalhar de forma colaborativa para ter mais eficiência, produtividade, reuso, menor número de bugs e tendo como consequência aceleração do processo de inovação. No post de hoje, falaremos sobre como atingir esses resultados com o Inner Source.
Mas o que é Inner Source? Em simples palavras, Inner Source é uma tendência crescente encontrada em equipes de desenvolvimento de software de alto desempenho que adotam alguns princípios e práticas de times Open Source dentro de uma organização.
Open Source? Mas isso não é filosofia?
Diferente do que muitas pessoas pensam, o open source vai muito além da filosofia. Atualmente, os mais complexos softwares existentes de toda a indústria possuem alguma licença aberta.
E isso gera oportunidades bilionárias, foi o caso da IBM comprar a maior empresa open source do mundo, a Red Hat, na época por trinta e quatro bilhões de dólares.
Entrando no mercado de Developer Experience, ou DevEx, esses números são hegemônicos. É possível ver que as linguagens mais populares do mundo são open source. O mesmo vale para os bancos de dados mais populares.
Hoje podemos ver a grande mudança de comportamento de empresas como a Microsoft que passou de maior inimiga para uma das maiores aliadas do mundo open source nas últimas duas décadas. Uma possível razão para essa mudança de pensamento: sobrevivência.
Se estima que 90% de toda a internet roda em Linux e que entre 65% a 95% de um código de uma aplicação é código de terceiro e é bem provável que boa parte dessas bibliotecas sejam open source.
Em outras palavras, é praticamente impossível pensar em engenharia de software ou em um desenvolvimento de aplicação sem pensar ou passar por alguma ferramenta, linguagem ou banco de dados que não seja open source.
Desafios e semelhanças entre open source e grandes organizações
Qual é a motivação de uma empresa usar as práticas Open Source? Para responder essa pergunta é importante entender que os dois mundos possuem diversas similaridades.
Isso mesmo! Tanto open source quanto uma grande organização possuem vários pontos em comum, o que inclui também as dores: ambos precisam lidar com vários componentes, contribuidores e ferramentas, além das estratégias.
Vamos ver algumas dessas dores a seguir.
Topologia de times
Um outro ponto é a topologia de times, afinal, muitas empresas começaram com uma filosofia de remote-first e times distribuídos. Isso ficou muito evidente, principalmente, nos anos de 2020 para o mundo corporativo, porém, o mundo open source já tem experiência com isso há pelo menos vinte anos.
Reuso de código
Reuso de código é outro ponto que ambos almejam, afinal, criar a mesma solução várias vezes faz com que o esforço e o conhecimento sejam duplicados, além de um alto custo de manutenção. Muito se discute o problema de se reinventar a roda a nível de solução, no entanto, pouco se fala a nível organizacional.
No mundo open source, temos o caso da Apache Foundation com o projeto Apache Commons, uma biblioteca Java cujo foco é centralizar componentes reutilizáveis em Java, que dentre os seus mais de milhares de usuários também se encontram os próprios projetos da Apache Foundation.
Ou seja, a mesma biblioteca Apache Commons é utilizada no Apache Kafka, Hbase, Hive, ao invés de cada um possuir a sua própria solução. Com isso se tem um componente que é provado e testado de aplicações comerciais até banco de dados e uma plataforma de evento distribuído.
Um outro ponto da prática de reuso é a possibilidade da utilização de ferramentas que facilitam o uso de componentes e bibliotecas no desenvolvimento da sua solução. Falando mais uma vez da Apache Foundation e do mundo Java existe o Maven. Que permite de modo realmente simples o uso de componentes, como bibliotecas, além de plugins dentro do universo Java.
Gestão de times e tomada de decisão
O modelo tradicional tendia a trabalhar de uma forma diferente, principalmente, focando em uma hierarquia da gestão. O que, muitas vezes, deixa toda a responsabilidade do resultado na mão de líderes em gerência e diretoria.
Com o tempo e o crescimento do projeto podemos perceber que esse modelo gerencial geral tem alguns gargalos. Nessa abordagem o aumento da complexidade e atuação de um número maior de pessoas com o objetivo de ganho de velocidade na entrega, não necessariamente se traduz no impacto esperado podendo assim na maioria dos cenários diminuir a eficiência.
A consequência sendo o aumento da desmotivação e rotatividade das pessoas. Essa rotatividade podendo impactar pessoas que detém conhecimento sobre o problema que está sendo resolvido ou mais especificamente sobre um componente do projeto, impactando prazos, manutenibilidade e tudo isso em um ciclo vicioso.
O software é “promovido” a legado e a solução é refazer o projeto, porém, se a metodologia não muda ao longo do percurso o software tende a retornar a esse estado. Afinal, sem boas práticas de engenharia e desenvolvimento o grande número de opções tende muito mais a atrapalhar do que auxiliar em momentos críticos.
O outro ponto é o desperdício de conhecimento e a falta ou baixo índice no reuso de componentes, o que faz com que ao longo da organização exista o mesmo componente inúmeras vezes. Assim, um bug precisará ser corrigido inúmeras vezes, o mesmo trabalho feito inúmeras vezes ao invés de ter eficiência entre times.
Boas práticas do mundo Open Source
O que o mundo open source traz é uma série de metodologias e práticas para o mundo corporativo e que já foram validadas com sucesso em grandes fundações open source como Apache, Eclipse, Linux entre outras. Por exemplo:
- Visibilidade
- Code Review
- Testes
- CI/CD
- Documentação de software
- Issue tracker
A utilização dessa abordagem cria a tendência de se fechar gaps e quebrar os silos de conhecimentos dentro de uma organização.
Em outras palavras, trazer para o mercado corporativo todo o know-how e maturidade de uma metodologia que é remote-first, distribuída, colaborativa e que foca na qualidade do código sem esquecer da entrega. Como é o caso da Linguagem Java, a JVM, o kernel do Linux além de diversos projetos da Apache Foundation como Cassandra, HBase, Hive dentre outros.
Os maiores benefícios do Inner Source?
Através do uso da metodologia entende-se que a curto e a médio prazo o Inner Source consegue trazer, de uma forma geral, os seguintes benefícios:
- Código de alta qualidade: Com uma maior cobertura de testes e devs com atenção no padrão de qualidade é possível um maior fluxo dentro da integração contínua.
- Documentação abrangente: Um código bem documentado e a documentação próxima do código faz com que o código seja a fonte da verdade. Isso permite, inclusive, um melhor entendimento do negócio, principalmente, aplicando as boas práticas do Domain-Driven Design (DDD) como uma linguagem ubíqua.
- Reutilização eficaz de código: Com uma boa documentação tanto do código quanto da arquitetura fica muito mais fácil o seu reuso, sem falar, que o processo de onboarding tende a ser menos custoso e mais rápido.
- Colaboração forte: Como consequência dos pontos anteriores podemos citar que o modelo promove a colaboração e com um menor número de atritos.
- Cultura saudável: Os silos são quebrados e a comunicação fica mais transparente. Existem relatos que isso também aumenta o propósito da pessoa engenheira, diminuindo a rotatividade do time.
Em outras palavras, são várias pessoas, com diferentes conhecimentos e especialidades, que conhecem a documentação, acessando o código, testando, reutilizando e garantindo a qualidade e a reputação do código.
Funciona em produção?
Essas práticas são muito boas, na verdade, parece ser uma proposta utópica. Isso, de fato, existe? Alguém já adota?
A resposta é sim! Existe inclusive uma fundação de Inner Source que contém casos de sucesso de diversas empresas ao redor do mundo, por exemplo: Microsoft, Gitlab, Adobe, Capital One, dentre outros.
Os benefícios são muitos similares entre as empresas além do desenvolvimento de forma mais eficiente.
Um outro ponto é a segurança, quase 40% de devs indentificam que o Inner Source ajuda a identificar problemas de segurança.
Em seu livro sobre Inner Source, a Paypal relata maior espaço para inovação, qualidade, além de escalabilidade das soluções existentes dentro da organização.
Também de acordo com o relatório State of Inner Souce, 61% das pessoas que responderam apontaram o compartilhamento de conhecimento como o maior benefício da adoção do Inner Source. Em seguida, 51% declararam que o uso trouxe um aumento na satisfação do trabalho.
Inner Source no Brasil
No Brasil já existem empresas que já utilizam e adotam os conceitos e as práticas de maneira bastante fluente. A seguir vamos ver um pouco mais sobre as aplicações no Itaú e na Zup
Inclusive, temos um episódio do Zupcast sobre como Itaú, Rede e a Zup fazem Inner Source:
Inner Source na Zup
Por exemplo, dentro da Zup boa parte das práticas aplicadas no seus produtos open source foram usadas em projetos internos e externos da organização.
Nesse caso, podemos destacar a parte de documentação da arquitetura na qual os projetos se preocuparam com a aplicação de C4-model, utilização de um Tech Radar além do Architecture Decision Records (ADR).
Como próximo passo, o objetivo é escalar essas práticas e muitas outras para toda a organização.
Inner Source no Itaú
No Itaú, muitos times já praticam Inner Source, e alguns já praticam antes mesmo de falarmos em Inner Source em escala corporativa.
Mais do que fazer Inner Source, é importante saber o porquê fazer Inner Source – o propósito e o valor que irá trazer, já que sabemos que Inner Source não é bala de prata.
Esta é uma das primeiras abordagens: comece Inner Source onde faça sentido o reuso e colaboração por mais de dois times, pelo menos. E se fizer sentido adotar as práticas de Inner Source, ajudamos os times a se estruturar para tal com seus repositórios.
Por exemplo, incentivamos os times a compartilharem seus componentes e bibliotecas e promovemos a visibilidade para que outros times reutilizem e não criem do zero.
Além disso, procuramos entender o potencial de Inner Source para os times. Alguns praticam Inner Source para tirar o gargalo do dia a dia, outros por questões de capacity de times, outros para gerar adoção para seus componentes, bibliotecas ou templates de infraestrutura, por exemplo.
E através disso, geramos dados para os times que praticam Inner Source como está a adoção do produto, colaboração, quantidade de dias que as issues estão abertas. Ou seja, o Inner Source como meio de solução para o dia a dia nas práticas de engenharia de software.
Nosso próximo passo é criar, com vários times, um padrão de reuso, onde todos possam trazer as boas práticas, independente do time e promover a escala maior na organização.
Inclusive, com base em suas experiências Itaú, Rede e a Zup focam em um Inner Source que visa impactar ainda mais as três organizações. O objetivo é garantir o reuso, elevar a qualidade técnica do time, além diminuir o tempo de desenvolvimento em componentes já existentes para focar na inovação, diretamente, para o negócio.
Conclusão
O mundo do open source é uma ótima fonte de grandes cases de sucesso como JVM e Linux, além de uma supremacia quando o assunto é Developer Experience com linguagens, banco de dados e outros produtos muito utilizados.
Além disso, o open source traz uma cultura que foca na qualidade de software, clareza na comunicação, boa documentação, uma entrega contínua em um time distribuído garantindo o reuso e focando na inovação. E essa cultura em lidar com desenvolvimento de software faz com que muitas organizações busquem o mesmo resultado.
É por isso que organizações como Itaú, Rede e Zup almejam aumentar os esforços na cultura do Inner Source. Conseguir voos ainda mais altos através de uma colaboração maior e mais fluida.
Referências
*Colaboram com o artigo Danielle Almeida, Orlando Valverde, Sergio Lopes e Vitor Nascimento Jr.
