Como gerir um programa InnerSource com êxito

Aqui, discutimos como você pode projetar um programa InnerSource para aproveitar o melhor dos padrões de código aberto dentro de qualquer organização de desenvolvimento de software.

O que é o InnerSource?

Qualquer pessoa pode usar, modificar e compartilhar livremente software de código aberto. Usando software de código aberto, qualquer pessoa pode visualizar, modificar e distribuir um projeto para qualquer finalidade com a ideia de que o compartilhamento de código leva a um software melhor e mais confiável.

InnerSource é a prática de aplicar padrões de código aberto a projetos com um público limitado. Por exemplo, uma empresa pode estabelecer um programa InnerSource que espelhe a estrutura de um projeto de código aberto típico, exceto que ele só é acessível aos funcionários dessa empresa. Na verdade, é um programa de código aberto por trás do firewall da sua empresa.

Benefícios do InnerSource

Um programa InnerSource pode oferecer inúmeros benefícios além do que os modelos tradicionais de código fechado oferecem.

Em primeiro lugar, apoiam a visibilidade interna. O acesso ao código fonte de outros projetos da empresa pode ajudar os programadores a serem mais produtivos quando trabalham nos seus próprios projetos. Eles podem ver como diferentes equipes resolvem problemas semelhantes aos que estão enfrentando e, muitas vezes, encontrar código e outros ativos que podem reutilizar. O acesso a questões de equipa, pedidos Pull e planos de projeto também fornecem melhores dados para que compreendam a velocidade e direção do projeto.

Em seguida, reduzem o atrito. Digamos que uma equipe de consumidores dependa de uma correção de bug ou de um novo recurso para um projeto de propriedade de uma equipe diferente. Em um programa InnerSource, eles têm um canal através do qual podem propor as mudanças de que precisam. E se essas mudanças não puderem ser mescladas por qualquer motivo, a equipe de consumidores tem a opção de forjar o projeto para atender às suas necessidades.

Por fim, padronizam as práticas. Um desafio comum que as organizações de desenvolvimento enfrentam é que as diferentes equipas muitas vezes divergem na forma como operam. Construir um programa InnerSource é uma ótima oportunidade para adotar convenções padrão que podem ser usadas em todas as equipes de desenvolvimento, mesmo que elas não sigam práticas idênticas. Por exemplo, duas equipas podem preferir processos diferentes para aceitar contribuições. A uniformização da forma como comunicam os respetivos processos diferentes facilita a contribuição por parte das pessoas.

Estes exemplos são apenas alguns dos benefícios de que beneficiam os programas InnerSource. Para saber mais, consulte Uma introdução ao InnerSource.

Configurar um programa InnerSource no GitHub

Definir visibilidade e permissões do repositório

Você pode configurar repositórios do GitHub com três níveis de visibilidade. Os usuários que não atendem ao requisito de visibilidade veem páginas "não encontradas" quando tentam acessar seu repositório. Os níveis são:

• Os repositórios públicos são visíveis para todos. Utilize esta visibilidade para projetos que são verdadeiramente em open source e ofereça acesso a pessoas dentro e fora da sua organização.
• Os repositórios internos só são visíveis para os membros da empresa que os possui.

• Os repositórios privados só são visíveis para o proprietário e quaisquer equipas ou indivíduos que adicionem. Use essa visibilidade para projetos aos quais apenas usuários e grupos específicos devem ter acesso.

Depois de estabelecer a visibilidade do repositório, você pode configurar as permissões individualmente ou em equipe. Existem cinco níveis de permissão:

• O nível de leitura é recomendado para colaboradores não técnicos que desejam ver ou discutir o projeto.
• O nível de triagem é recomendado para colaboradores que precisam gerenciar proativamente problemas e pedidos de pull sem acesso de escrita.
• O nível de escrita é recomendado para colaboradores que estão a trabalhar ativamente no projeto.
• O nível de acesso "Manter" é recomendado para gerentes de projeto que precisam gerenciar o repositório sem ter acesso a ações confidenciais ou destrutivas.
• O nível de administrador é recomendado para pessoas que precisam de acesso total ao projeto, incluindo ações sensíveis e destrutivas, como gerenciar a segurança ou excluir um repositório.

Saiba mais sobre as permissões de acesso ao repositório por nível.

Criar repositórios detetáveis

À medida que um programa InnerSource cresce, o número de repositórios provavelmente aumenta significativamente. Embora seja ótimo ter todos estes recursos disponíveis para a organização, pode tornar-se um desafio para encontrar conteúdo de forma eficiente. Para resolver esse problema de forma proativa, é uma prática recomendada para as equipes considerarem o que podem fazer para tornar mais fácil para outras pessoas encontrarem e trabalharem com seus repositórios.

Algumas melhores práticas incluem:

• Utilizar um nome descritivo do repositório, como warehouse-api ou supply-chain-web.
• Incluir uma descrição concisa. Uma ou duas frases deve ser suficiente para que os potenciais utilizadores saibam se o projeto pode corresponder às suas necessidades.
• Licencie seu repositório para que os clientes saibam como podem usar, alterar e distribuir o software.
• Inclua um README.md arquivo no repositório. O GitHub usa esse arquivo como a página de destino quando as pessoas visitam o repositório.

Adicionar um arquivo LEIA-ME

Um ficheiro LEIA-ME comunica as expectativas para o seu projeto e ajuda-o a gerir as contribuições. Os ficheiros LEIA-ME podem:

• Articular o propósito e a visão do projeto para que os potenciais consumidores compreendam se corresponde às suas necessidades.
• Oferecer ajudas visuais, como capturas de ecrã ou exemplos de código, para ilustrar o projeto em ação.
• Inclua links para uma versão de produção ou demonstração do aplicativo para revisão.
• Definir expetativas para pré-requisitos e procedimentos de implementação.
• Inclua referências aos projetos dos quais você depende. Estas referências são uma boa forma de promover o trabalho dos outros.
• Use Markdown para orientar os leitores através do conteúdo formatado corretamente.

Se você colocar seu arquivo README.md no diretório raiz do repositório ou no diretório oculto, .githubdocs o GitHub reconhecerá e exibirá automaticamente seu LEIA-ME para os visitantes do repositório. Se um repositório contiver mais de um arquivo LEIA-ME, o arquivo mostrado será escolhido entre os locais na seguinte ordem:

1. O .github diretório
2. O diretório raiz do repositório
3. O docs diretório

Confira alguns exemplos incríveis de LEIA-ME.

Assim que o projeto for lançado, use o e-mail e outros canais de rede para promovê-lo. Alcançar um público adequado pode produzir um impulso significativo na participação do projeto.

Saiba mais sobre os arquivos LEIA-ME na documentação do GitHub.

Gerenciar projetos no GitHub

À medida que os projetos ganham força, o influxo de usuários e contribuições pode exigir muito trabalho para gerenciar. Dependendo do projeto, uma quantidade significativa de trabalho pode ser necessária apenas para gerenciar as expectativas dos participantes do projeto.

Para resolver esse problema de forma proativa, o GitHub procura um CONTRIBUTING.md arquivo na raiz (ou /docs/.github) de um repositório. Utilize este ficheiro para explicar a política de contribuição do projeto. Os detalhes exatos podem variar, mas é uma boa ideia informar os potenciais contribuidores sobre as convenções que o projeto segue. Por exemplo, onde a equipe está procurando solicitações pull, quais detalhes são solicitados para relatórios de bugs e assim por diante.

Se existir, o CONTRIBUTING.md GitHub apresenta um link para ele quando os usuários criam problemas ou recebem solicitações para incentivá-los a segui-lo.

Confira alguns exemplos de CONTRIBUTING.md incríveis

Além disso, considere adicionar um arquivo CODEOWNERS ao repositório para definir indivíduos ou equipes responsáveis pela revisão de modificações de código.

Criar modelos de solicitação de emissão e pull

O GitHub suporta modelos de arranque para novas questões e pedidos Pull. Use esses modelos para fornecer o texto de descrição inicial para um problema recém-criado ou solicitação pull.

Por exemplo, se o seu projeto tiver .github/ISSUE_TEMPLATE.md, sempre que um usuário iniciar o processo de criação de um problema, ele verá esse conteúdo. Em vez de ter que referenciar constantemente os detalhes necessários de um CONTRIBUTING.md, eles são capazes de apenas preencher o problema como um formulário usando o texto do modelo.

O mesmo aplica-se para pedidos Pull, com a exceção do caminho, que é .github/PULL_REQUEST_TEMPLATE.md.

Confira alguns fantásticos modelos de issues e pull requests do GitHub.

Definir fluxos de trabalho

Para projetos que incentivam contribuições externas, certifique-se de que especifica o fluxo de trabalho que o projeto segue. O fluxo de trabalho deve incluir detalhes sobre onde e como as ramificações devem ser usadas para bugs e recursos. Ele também deve incluir como as solicitações pull devem ser abertas e quaisquer outros detalhes que as pessoas fora da equipe do repositório devem saber antes de enviar código. Se você ainda não tem um fluxo de trabalho em mente, deve considerar o fluxo do GitHub.

Deve comunicar uma estratégia de gestão de lançamentos e implementações. Essas partes do fluxo de trabalho afetam a ramificação e a fusão diárias, por isso é importante comunicá-las aos colaboradores. Saiba mais sobre como eles se relacionam com sua estratégia de ramificação do Git.

Medir o êxito do programa

Uma equipa que se aventura no InnerSource deve pensar nos tipos de métricas que quer seguir para avaliar o êxito do seu programa. Embora as métricas tradicionais como "tempo para alcançar o mercado" e "erros comunicados" ainda sejam aplicáveis, não vão necessariamente ilustrar os benefícios alcançados através do InnerSource.

Em vez disso, considere adicionar métricas que mostrem como a participação externa melhorou a qualidade do projeto. O repositório recebe pedidos Pull de fontes externas que corrigem erros e adicionam funcionalidades? Há participantes ativos nas discussões em torno do projeto e do seu futuro? O programa está a inspirar uma expansão InnerSource que aumenta os benefícios noutros locais da organização?

Em suma, as métricas são difíceis, especialmente quando se trata de medir o valor e o efeito das contribuições individuais e de equipe. Quando são mal utilizadas, as métricas podem prejudicar a cultura, os processos existentes e diminuir o sentimento coletivo em relação à organização ou equipa de liderança. Ao pensar em medir a adoção do InnerSource, considere as seguintes orientações sobre métricas:

• Medir o processo, não a saída
  • Tempo de entrega de revisão de código
  • Tamanho do pedido Pull
  • Trabalho em curso
  • Tempo para abrir
• Meça em comparação com metas e não pontos absolutos
• Meça equipas e não indivíduos
  • Número de contribuidores únicos para um projeto
  • Número de projetos que reutilizam código
  • Número de @mentions de equipa cruzada

Saiba mais sobre os sucessos que outros tiveram nestes estudos de caso da InnerSource.