Como acelerar a inovação com o innersource

Introdução

O código aberto mudou a forma como criamos software. Desde reservas de hotéis até serviços bancários, quase toda nova aplicação é desenvolvida com código gratuito e reutilizável, criado por uma comunidade de desenvolvedores de âmbito global. De acordo com a Gartner, mais de 87% das empresas de TI em todo o mundo utilizam código aberto para suas cargas de trabalho críticas de TI, estejam elas cientes disso ou não.

Mas o processo é tão importante quanto o resultado. À medida que as comunidades de código aberto são criadas e se expandem, elas encontram maneiras de colaborar de forma rápida e eficaz entre regiões, fusos horários e idiomas. Elas criam código por meio de equipes distribuídas em escala, transformam os sistemas de controle de versão distribuídos em um padrão do setor, e até estabelecem os fundamentos por trás do DevOps moderno. Se você estiver usando o Git, o Python, ou se estiver compartilhando e reutilizando código com sua equipe, então você está participando das práticas recomendadas de código aberto.

Como vimos com o DevOps, quando as equipes de desenvolvimento de uma empresa adotam essas práticas recomendadas, elas podem alcançar a mesma velocidade e inovação. Por reproduzir a forma como as comunidades de código aberto funcionam, as empresas podem criar software da forma que seus desenvolvedores já conhecem e amam: criando um ambiente que é familiar, livre de distrações desnecessárias e focado na inovação por meio de rápida iteração incremental.

O que estamos descrevendo é conhecido como “innersource”. Assim como com o código aberto, mesmo que o termo não seja conhecido, alguns dos princípios por trás dele ainda podem ser identificados. O innersource pode parecer diferente dependendo da empresa, mas sempre compartilha os mesmos objetivos: adotar as ferramentas, práticas e cultura do código aberto para construir software proprietário.

Sendo a casa da comunidade de código aberto mundial, o GitHub tem visto o impacto do innersource em primeira mão. Por exemplo, no relatório State of the Octoverse de 2021, vimos que as equipes que seguem os princípios de innersource, como a reutilização de código, podem notar um impressionante aumento de 87% na produtividade. Neste e-book, vamos explorar como organizações como Ford e 3M usam essas e outras práticas recomendadas de innersource para melhorar a velocidade e acelerar a inovação, e como o GitHub pode ajudar.

Definição de innersource

O innersource tem sido descrito de várias formas. Muitas empresas usam a palavra “innersource” para descrever como suas equipes de engenharia trabalham juntas num código. Desenvolvedores em organizações que já estão envolvidas com grandes comunidades de código aberto podem não usar o termo innersource. Em vez disso, eles pensam que essa é simplesmente uma forma de aplicar as metodologias do código aberto ao desenvolvimento de software no trabalho.

O innersource é uma metodologia de desenvolvimento onde engenheiros criam software proprietário usando as práticas recomendadas de projetos de código aberto de larga escala. Adotar práticas de innersource é como começar uma comunidade de código aberto dentro de sua organização. Em projetos de código aberto, a colaboração transparente mobiliza o conhecimento e as habilidades coletivas de uma comunidade para criar um software melhor. Já uma comunidade innersource contém o conhecimento, as habilidades, e as competências de pessoas e ferramentas dentro de uma única empresa.

O innersource traz práticas recomendadas encontradas no código aberto e, portanto, uma cultura imersiva de DevOps. Essas práticas recomendadas incluem a colaboração com desenvolvedores fora da equipe principal, a redução do trabalho duplicado com código compartilhável e reutilizável, o incentivo a discussões e colaboração transparentes, e rápidos ciclos de iteração e de feedback. Tudo combinado? Uma experiência melhor para os clientes, entregue com mais rapidez.

Cinco formas de acelerar a inovação com o innersource

Colabore com contexto entre equipes e fusos horários

A forma como as pessoas trabalham mudou com as equipes distribuídas, e o trabalho remoto se tornou a norma. Aproveitar ao máximo uma força de trabalho mundial significa que não importa onde o trabalho acontece; da sede da empresa ao sofá da sala, ele acontece de uma forma colaborativa, transparente e aberta. Significa também que as organizações podem adotar práticas de contratação mais inclusivas e flexíveis, contratando a pessoa certa para o trabalho, sem considerar a localização dela.

Os escritórios globais da Zendesk são um ótimo exemplo. A empresa valoriza a transparência, especialmente no que diz respeito à engenharia, de modo que um engenheiro em Copenhagen pode entender e alavancar um trabalho que está acontecendo em São Francisco. Jason Smale, Vice-Presidente de Engenharia da Zendesk, descreve a configuração interna da equipe como semelhante à encontrada em um projeto de código aberto, com mantenedores e contribuidores colaborando no ecossistema da empresa.

A propriedade clara e documentada dos projetos permite que cada equipe gerencie o caos de diferentes fluxos de trabalho sem excluí-los de grandes ideias. Eles aproveitam a capacidade intelectual coletiva da empresa, permitindo que qualquer pessoa de qualquer equipe contribua, desenvolva ou reutilize o trabalho existente. Como Smale explica, “Nossa cultura de engenharia é aberta e centrada em equipes que possuem serviços e são responsáveis por executá-los na produção.”

A propriedade compartilhada também é um aspecto importante da qualidade do código e da colaboração no Spotify. O Gerente de Produto Laurent Ploix diz: “Você precisa de abertura e propriedade”. Dar às equipes propriedade sobre projetos específicos aumenta o orgulho delas pelo trabalho que fazem e simplifica a tomada de decisões, porque um indivíduo ou grupo passa a ter a palavra final na aprovação das mudanças. Ploix diz: “Com forte propriedade, evitamos o acúmulo de código onde ninguém sabe se ele está ou não sendo usado”. Por outro lado, permitir e incentivar que não proprietários enviem melhorias aumenta o número de olhos procurando por bugs e abre esses projetos para novos recursos inovadores. Ou, como Ploix diz: “Alguém de fora pode encontrar uma solução melhor do que eu”.

O innersource não apenas melhora as funções entre equipes como também ajuda as equipes a trabalhar de forma assíncrona entre divisões geográficas e horários variados, uma habilidade cada vez mais importante para muitas organizações. “O GitHub nos ajuda a colaborar com pessoas que estão de forma remota”, explica Erika Moreno Sierra, Engenheira de Software no Deliveroo. “Há diversas discussões acontecendo dentro de solicitações de pull”. A equipe do Engenheiro de Software Sênior Florian Thomas está trabalhando atualmente com cientistas de dados que escrevem modelos de aprendizado de máquina e conseguem vinculá-lo rapidamente a novas versões no GitHub. “Temos o mesmo acesso, por isso é fácil para mim acompanhar”.

Mesmo com equipes trabalhando em diferentes lugares e regiões, o GitHub e o innersource ainda fornecem a organizações internacionais, como a Otto Group, “uma língua em comum” para compartilhar códigos e recursos. Tendo o GitHub como base, a Otto Group avançou nos programas de innersource em 18 de suas empresas subsidiárias. A Dra. Hanna Huber, Vice-Presidente de Estratégia e Governança de Tecnologia da Otto Group, diz: “Esse desenvolvimento foi impulsionado por um processo de transformação em todo o grupo que representa uma nova era de colaboração”.

E, assim como a colaboração de código aberto que o innersource emula, a escalabilidade é incorporada desde o primeiro dia. De acordo com Jean-Hervé Laveau, Líder de Ferramentas e CI/CD da Engie, as iniciativas de innersource incentivam “o compartilhamento em escala de capacidades, conhecimentos e fontes”. Com funcionários espalhados por 70 países, os desenvolvedores da Engie podem “compartilhar em grande escala, em todo o mundo”.

Dica do GitHub: para manter o trabalho em movimento entre os fusos horários, use o GitHub como uma plataforma de colaboração para discutir ideias e mudanças, e para realizar revisões de forma assíncrona com o GitHub Issues e solicitações de pull. Saiba mais

Levando novas ideias aos clientes com mais rapidez

Abrir um projeto convida novas ideias. Pode também ajudar equipes a aprimorar a qualidade do código, remover o atrito do processo, e levar o trabalho para a produção mais rapidamente. Tom Erickson, Supervisor de Ferramentas e Processos Globais de Software na Ford, enxerga o valor de incentivar mais ideias, não apenas sobre código, mas também sobre processos e estilos de trabalho. Ele diz: “Desenvolvedores podem dar sugestões e adotar um estilo de trabalho que seja mais aberto e esteja de acordo com suas necessidades”. “Se você deseja fornecer um software de qualidade com mais rapidez, faz todo o sentido usar o innersource”.

Velocidade e inovação andam de mãos dadas com o innersource, tornando o processo de compartilhamento de código em plataformas como o GitHub duplamente benéfico para desenvolvedores e clientes: por exemplo, a DXC consegue criar aplicações mais rapidamente (algo especialmente importante em tempos de rápida mudança das dinâmicas de mercado), e dar aos desenvolvedores um único índice para todo o código que eles vão criar. Por exemplo, Tom Halpin, líder técnico na DXC, diz que quando um colega tinha uma questão sobre o framework de teste de web Cypress, ele conseguia simplesmente procurar no GitHub da empresa e encontrar um especialista em tecnologia in-house. Ele diz: “Isso nos ajuda a desbloquear a capacidade intelectual da DXC”.

Chris Swan, Diretor de Tecnologia de Aplicações Modernas e Nativas da Nuvem, Vice-Presidente e Especialista da DXC, diz que os produtos que eles achavam que levariam seis meses acabaram levando seis semanas. Swan explica: “Os clientes esperavam ter que lançar uma série de alicerces antes de poderem construir a casa”. “Mas nós pudemos chegar e dizer: ‘Já fizemos tudo isso. Coloquem apenas as vigas e as paredes.’” Como resultado, os clientes da DXC podem chegar ao mercado mais rapidamente e ser mais competitivos.

Para organizações como Otto Group e 3M, que têm muitas divisões e subsidiarias, o innersource permite que os desenvolvedores, não apenas os clientes, tenham um acesso mais rápido a soluções e tecnologias internas. Kevin Truckenmiller, Engenheiro Líder de DevOps em Corporate Research Systems Lab (Laboratório de Sistemas de Pesquisa Corporativa, CRSL), diz: “Você faz uma vez, e fornece para muitos”. Incontáveis divisões da 3M usam contêineres Docker e desenvolvem na AWS. Como todos elas solicitam acesso à AWS, isso também significa gerenciar milhares de credenciais da AWS. Antes do GitHub, divisões individuais criavam suas próprias ferramentas de credenciais, resultando em múltiplas ferramentas para o mesmo propósito. Em vez disso, o CRSL criou uma ferramenta de federação para ajudar as equipes a acessar as contas da AWS usando credenciais do diretório corporativo. Agora, equipes podem facilmente abrir uma solicitação de pull para baixar o código da ferramenta do repositório no GitHub e colocá-lo em uso. “Velocidade é a chave. Em vez de alguém perguntar se podemos criar um recurso para ele, ele pode abrir uma solicitação de pull e adicioná-lo por conta própria”, diz Truckenmiller. Este modelo self-service permite que as pessoas desbloqueiem suas próprias dependências.

Ainda assim, o sucesso do innersource deve-se ao equilíbrio: avançar à velocidade máxima sem pular as importantes etapas intermediárias. Para evitar atrasos nos projetos enquanto as equipes crescem, é essencial planejar bem tanto os processos como a documentação. Por exemplo, as equipes da Stripe frequentemente trabalham no código umas das outras, mas não importa de onde vem o código, ele sempre passa pelo mesmo processo de revisão. (E com ferramentas de automação, como a varredura de código e os linters do GitHub Advanced Security, esse processo de revisão ocorre com rapidez e eficiência.) A documentação sobre a contribuição e a revisão do código elimina o esforço dos contribuidores individuais de descobrir "o que vem a seguir", o que facilita o envolvimento nos termos de um projeto. Michael Glukhovsky, Developer Advocate da Stripe, acha que a habilidade de contribuir sem atrito empodera: “Se você vir algo que precisa ser consertado, você pode enviar uma solicitação de pull, e começar uma conversa.”

Dica do GitHub: tenha certeza de que os colaboradores conhecem as informações essenciais sobre a base de código e sobre como participar adicionando arquivos README e CONTRIBUTING aos repositórios. Saiba mais

Descobrindo e reutilizando código entre equipes

É um momento muito familiar: sua equipe planeja, projeta, e implementa um novo padrão de UI para seu produto. É utilizável, eficaz e foi iterado com perfeição ao longo de alguns meses. Mas então você se depara com uma solicitação de pull com um recurso similar desenvolvido independentemente por outra equipe. Os criadores do seu código poderiam ter sido poupados de algum trabalho; além disso, há agora uma inconsistência na experiência de usuário do seu produto. Adaptar e reutilizar recursos testados em campo parece óbvio. Permitir que seu código seja descoberto por outra equipe, não.

Para Florent Zara, Líder do Projeto Innersource da ENGIE Digital, “[O objetivo do innersource] é acabar com os pontos de isolamento e incentivar as pessoas a trabalhar juntas”. Ele explica que o innersource torna os projetos abertos, facilitando a descoberta, a reutilização e o desenvolvimento de códigos em toda a organização. Charline Grenet, Diretora de Comunidades Digitais e Comunicações, concorda. “Tudo o que fazemos precisa ser industrializado para ser reutilizável”, diz Grenet. “Queremos ter projetos que sejam 100% de innersource.”

A prática se mantém até mesmo em empresas maiores, como Autodesk e Ford, onde o Engenheiro Chefe Florian Frischmuth sente que manter o código em um lugar, como o GitHub, faz com que ele seja mais fácil de descobrir. “Nosso ambiente permite que desenvolvedores encontrem soluções que já tenham sido desenvolvidas. Eles podem colaborar nelas, e então reutilizá-las”.

George Swan, Diretor Sênior da Plataforma de Construção, diz que, antes, os engenheiros da Autodesk criavam um software complexo várias vezes “porque o que existia só fazia 90% do que precisávamos”. Eles copiavam o branch, criavam o próprio e acrescentavam os 10% finais. Agora, os funcionários têm acesso a quase 100% da propriedade intelectual da Autodesk. De 19.000 repositórios, apenas cerca de 10 são privados. “Estamos abertos para todos.”

Por meio de compartilhamento e reutilização de código, algumas equipes começam a se parecer com comunidades de código aberto, onde as práticas recomendadas de innersource e de DevOps começaram, como no Spotify, onde os desenvolvedores que possuem projetos assumem funções semelhantes às de alguns mantenedores de código aberto. Eles recebem e fazem a triagem de novos bugs, ideias, e código. Eles também podem ser responsáveis pela descontinuação ou até mesmo pelo arquivamento de seus projetos. De acordo com Ploix, “Eles se tornam mantenedores, de fato. E com forte propriedade, evitamos o acúmulo de código onde ninguém sabe se ele está sendo usado ou não.”

Dica do GitHub: contas de empresas podem definir um nível de permissão padrão para todos os repositórios da organização no GitHub. Ajude os desenvolvedores a encontrar e compartilhar códigos com facilidade, definindo as permissões padrão do repositório como abertas ou "nenhuma". Saiba mais

Aumentando a qualidade e a segurança do código

Existe uma tensão lógica entre “aberto” e “seguro”. À medida que as pessoas lançam software com um número crescente de dependências de código aberto, é mais importante do que nunca que as equipes de software façam da segurança uma prioridade desde o começo. Na prática, as equipes de empresas acham que ter mais colaboradores cria mais oportunidades de encontrar bugs e outros problemas. Elas também acham que essa abordagem convida o conhecimento especializado em segurança a participar do processo mais cedo.

Na Nationwide, as equipes mantinham os projetos em segredo, mas abri-los, pelo menos internamente, provou ser essencial para a melhoria em escala da qualidade do código. Cindy Payne, Vice-Presidente Associada de Serviços de Aplicações de TI da Nationwide, explica que os projetos que as equipes mais hesitavam em compartilhar geralmente se beneficiavam mais das perspectivas externas. A prática também ajudou a lidar com as vulnerabilidades de segurança, permitindo que a equipe avaliasse rapidamente o impacto e, em seguida, fizesse a triagem da situação adequadamente.

O innersource pode ocorrer atrás do firewall da empresa, mas a escalabilidade está sempre em primeiro plano. “Os valores fundamentais da 3M não estão necessariamente centrados apenas na empresa”, diz Truckenmiller. “Realmente temos o resto do mundo em mente. Queremos proteger a propriedade intelectual, mas, ao mesmo tempo, não queremos resolver o mesmo problema de cinco maneiras.” Ao mudar para um modelo mais aberto de innersource, uma única solução pode ser compartilhada entre vários pesquisadores, com impactos que chegam até os consumidores. “Estamos rumo a uma maior abertura, o que, em última instância, cria uma cultura de comunicação e uma cultura generativa, em vez de uma burocrática e baseada apenas em processos”.

“A base das consultas continua se expandindo, não apenas por meio do GitHub, mas por meio da experiência de outras empresas. Isso faz com que o potencial do valor que obtemos, apenas na análise estática, seja muito maior do que é hoje.” David Ross, Engenheiro de Segurança da Equipe da Postmates

Dica do GitHub: a segurança é responsabilidade de todos, não apenas da equipe de segurança. Ative os alertas de varredura de código para ajudar os desenvolvedores a encontrar e resolver problemas de segurança sempre que abrirem uma nova solicitação de pull. Saiba mais

Economizando tempo e acelerando a inovação com o self-service

Ao iniciar novos projetos, muitas equipes ainda seguem um modelo de solicitação e espera. Elas fazem uma solicitação, e um administrador central cria um novo repositório. Esse modelo complica de duas formas um processo que poderia ser mais simples: gera necessidade de manutenção administrativa e restrições contra tentativas de algo novo. O innersource, por outro lado, permite que todos tenham autonomia para começar sem atrito.

Permitir que equipes criem seus próprios projetos pode dar a impressão de mais trabalho, e o esforço antecipado para documentar um novo processo e até mesmo criar modelos de governança pode parecer assustador. Mas muitas equipes acham que um modelo self-service, no fim das contas, economiza tempo em manutenção e empodera desenvolvedores a começar.

Payne acha que os repositórios self-service do GitHub não apenas removem bloqueadores, mas também economizam tempo e dinheiro da empresa, do ponto de vista da infraestrutura. Sobre a troca de modelos, ela diz: “Sabíamos que iríamos economizar dinheiro, mas essa economia se transformou imediatamente em mais capacidade para as equipes realizarem o trabalho mais valioso para a nossa empresa.”

Zsuzsanna Gnandt, Gerente de Projetos de Innersource da Continental, explica que fabricantes estabelecidas como Continental e Ford também descobriram que remover barreiras incentivou uma nova criatividade. “Com o innersource, queremos dar a todos os desenvolvedores a liberdade de serem criativos, de impulsionarem a inovação sem barreiras e de serem valorizados por suas contribuições para a empresa”.

Com o código da Ford acessível a todos da organização, as equipes não estão mais separadas pelas estruturas da organização. Em vez disso, elas podem trabalhar juntas em um novo código e aproveitar ao máximo as soluções já existentes. “Nosso ambiente permite que desenvolvedores encontrem soluções que já tenham sido desenvolvidas. Eles podem colaborar nelas e então reutilizá-las”, diz o Engenheiro Chefe Florian Frischmuth.

Por aproveitar a plataforma de colaboração do GitHub e a conexão segura com a comunidade de código aberto, os desenvolvedores do Spotify obtêm o melhor dos dois mundos: innersource interno e trabalho de código aberto que não é de propriedade intelectual.

Dentro ou fora do firewall, ter milhares de contribuidores significa ter milhares de ideias, grande diversidade de pensamento, e no fim das contas, uma melhor experiência para os clientes. Ploix diz: “Solicitações de pull são bem-vindas”. “Alguém de fora pode encontrar uma solução melhor do que eu.”

Dica do GitHub: reconheça o desenvolvimento inovador entre repositórios públicos e privados com contribuições unificadas. Ao conectar as contas do GitHub Enterprise dos desenvolvedores com suas contas do GitHub.com, eles receberão crédito público por seu trabalho árduo, além de oportunidades de colaboração e acesso a novos talentos e ferramentas. Saiba mais