O código normalmente flui downstream, de um projeto de código aberto para os próprios produtos de uma organização. Upstreaming é o processo de reverter esse fluxo – contribuindo com código voltar para um projeto de código aberto. A proposta de valor do upstreaming inclui aproveitar a força de uma comunidade de código aberto para examinar o código, encontrar e corrigir problemas e adicionar seus próprios recursos que tornam o código mais valioso para todos que o utilizam.
Como alguém que esteve profundamente envolvido com projetos de código aberto por muitos anos — eu comprometi o código no projeto do sistema operacional de código aberto FreeBSD por mais de uma década, atuei na equipe principal desse projeto por dois mandatos, contribuí para o ZFS de código aberto e co-escrevi dois livros sobre ZFS — vi inúmeras organizações enfrentarem os desafios e colherem os benefícios substanciais do upstreaming. Resumindo, o código contribuído que se torna parte de um projeto principal de código aberto recebe manutenção compartilhada, desenvolvimento ativo e extensão, com outros membros da comunidade muitas vezes agregando valor que vai muito além da contribuição inicial.
Na verdade, o upstreaming é como a maioria dos novos recursos importantes são introduzidos em projetos de código aberto como FreeBSD e ZFS, entre muitos outros. Vejamos os benefícios específicos do upstreaming e as melhores práticas para desbloquear diretamente suas vantagens.
Benefícios do upstreaming
O compromisso com o upstreaming resulta em código de maior qualidade, um processo de desenvolvimento mais simples, cargas de manutenção reduzidas e maior sustentabilidade do projeto.
Código de maior qualidade
Desenvolver código com a intenção de upstreaming atua como uma função de força de qualidade. Para equipes de desenvolvimento e líderes que devem resistir constantemente às mentalidades de “basta lançar o código” e “está tudo bem se o código for feio porque ninguém vai vê-lo”, um compromisso com o upstreaming e passar pelo processo de revisão upstream fornece uma vantagem inatacável. guarda-corpo.
Ao mesmo tempo, quando o código começa a ser desenvolvido destinado a olhos internos e uso interno, e depois precisa ter generalidade reforçada posteriormente, o resultado geralmente são recursos menos satisfatórios (e maiores cargas de manutenção) no futuro. Aderir às práticas de codificação upstream e aos requisitos de estilo durante todo o desenvolvimento resulta em código de qualidade muito mais alta – código criado para fornecer valor não apenas dentro de uma organização, mas para todos.
Desenvolvimento mais fácil
Um dos maiores desafios do uso de tecnologias de código aberto surge quando as organizações cometem o erro de desenvolver para a versão de software de código aberto que estão usando atualmente (que pode ter vários anos) em vez de para a versão mais recente. Essa prática ineficiente (se não totalmente ineficaz) significa fazer um rebase para acompanhar todas as outras alterações de software que podem impactar seu novo recurso e enfrentar toda a dívida técnica que o atraso cria.
Desenvolver para a versão principal mais recente do software de código aberto e, em seguida, fazer backport conforme necessário garante que o processo de upstreaming não fique atolado por mudanças que estão acontecendo no upstream durante o desenvolvimento e significa muito menos trabalho no final, já que você não está tentando rebase contra um alvo em movimento rápido.
Menos manutenção
Novamente, as organizações que criam novos recursos em um ramo local mais antigo de software de código aberto e depois tentam fazer o upstream para uma versão mais recente tendem a ter dificuldades porque exigem conhecimento no assunto em todas as áreas do software que mudaram durante esse período. . A disponibilidade de conhecimentos especializados é um desafio importante do upstreaming. Por exemplo, uma equipe de desenvolvimento que ainda não está familiarizada com o sistema operacional FreeBSD achará um desafio abordar toda a área de superfície tocada pelas mudanças upstream nas quais eles precisam fazer rebase para pegar seu código até a linha principal antes que possam fazer o upstream seu patch muda.
Comprometer-se com o upstreaming desde o início permite um foco muito mais concentrado no que é o seu patch na verdade fazendo, o que provavelmente está na casa do leme do seu assunto. Depois que as alterações são integradas no upstream e fazem parte do software de código aberto principal, a manutenção não é mais um problema apenas seu. É um esforço comunitário.
Sustentabilidade do projeto
Com as contribuições originais mantidas pela comunidade, os novos recursos atraem mais usuários e mais contribuições. Esse ciclo virtuoso desenvolve projetos de código aberto, comunidades e funcionalidades de software eficazes para seu maior benefício.
Melhores práticas para fazer upstreaming de um patch
Com base em minha experiência no upstream de patches para projetos de código aberto, o processo descrito abaixo fornece uma visão geral de como fazer o upstream de um recurso com sucesso.
Etapa 1: crie o patch candidato
É importante ressaltar que você deve garantir que seu patch seja geralmente útil e valioso para outros usuários do projeto para o qual você está contribuindo. Não é uma boa prática fazer upstream de código que seja excessivamente específico para seu aplicativo e de pouco valor para qualquer outra pessoa. Isso é apenas jogar código por cima do muro e esperar que alguém o mantenha. Estender um recurso para oferecer valor geral pode exigir algum trabalho extra, mas essa utilidade é essencial para a qualidade da sua contribuição e para a resposta da comunidade.
Isto leva a outro desafio fundamental do upstreaming: advocacia. Tornar seu recurso contribuído um sucesso requer entusiasmo da comunidade. Eles precisam entender por que eles deveriam adotá-lo e como eles podem se beneficiar disso. Conhecer bem a comunidade e envolver-se desde cedo (mesmo antes do desenvolvimento) para compreender as necessidades dos outros é um grande passo para superar este desafio. Quanto mais seu código upstream for usado, maior será a probabilidade de ele prosperar e se expandir (em vez de ser removido ou obsoleto no futuro). O envolvimento é muitas vezes o factor mais importante que determina onde o esforço de manutenção da comunidade é aplicado.
Etapa 2: enviar o patch para revisão por outros contribuidores originais
Forneça documentação suficiente para que outras pessoas possam usar o código, juntamente com testes que garantam que seu código não quebrará outros recursos e que qualquer regressão na funcionalidade de seu recurso causada por outras alterações será detectada. Naturalmente, inclua também uma descrição clara do seu patch, que explique sua finalidade e seu valor para os revisores.
Outros contribuidores originais revisam seu patch e fornecem feedback, que você deve abordar adequadamente.
Etapa 3: os revisores integram o patch na ramificação upstream
O patch também pode ser mesclado com a ramificação estável ou ramificações do software de código aberto. Versões futuras do software upstream incluirão suas alterações. Defender backports para as ramificações estáveis e ajudar a mantê-los ajudará a garantir que esses backports estejam disponíveis para seus produtos que usam essas ramificações estáveis e que você tenha um caminho de atualização fácil no futuro.
Adote uma mentalidade de ‘upstream primeiro’
O upstreaming força sua organização a criar código que não seja bom o suficiente apenas para uso interno, mas também bom o suficiente para servir uma comunidade inteira de código aberto e obter seu apoio duradouro. Ao projetar recursos que atendam efetivamente às necessidades da comunidade e também às suas, o processo de upstreaming e revisão se torna muito mais fácil, e os recursos dos quais sua organização depende podem crescer e florescer muito além do que sua equipe poderia fazer sozinha. Esse é o poder do código aberto.
Allan Jude é gerente de engenharia do FreeBSD da Klara Inc., que fornece serviços corporativos e suporte para infraestruturas de código aberto. Ele é Committer do FreeBSD desde 2014.
–
O New Tech Forum oferece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Envie todos consultas para [email protected].
