Como gerenciar um programa InnerSource bem-sucedido

Concluído

Aqui abordamos como é possível criar um programa InnerSource para aproveitar o melhor dos padrões de software livre em qualquer organização de desenvolvimento de software.

O que é InnerSource?

Qualquer pessoa pode usar, modificar e compartilhar livremente software de código aberto. Ao usar software de código aberto, qualquer pessoa pode exibir, 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-alvo limitado. Por exemplo, uma empresa pode estabelecer um programa InnerSource que espelhe a estrutura de um projeto típico de código aberto, exceto que ele é acessível apenas aos funcionários daquela 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 dos que os modelos tradicionais de código fechado oferecem.

Primeiro, ele incentiva a transparência. O acesso ao código-fonte de outros projetos da empresa pode ajudar os desenvolvedores a ser mais produtivos ao trabalhar nos próprios projetos. Eles podem ver como diferentes equipes resolvem problemas semelhantes aos que estão enfrentando e, muitas vezes, encontrar códigos e outros ativos que podem reutilizar. O acesso a emissões, solicitações de pull e planos de projeto da equipe também fornece melhores dados para que eles compreendam a velocidade e a direção do projeto.

Em seguida, eles reduzem atritos. Digamos que uma equipe de consumidores depende de uma correção de bug ou de um novo recurso para um projeto de propriedade de outra equipe. Em um programa InnerSource, eles têm um canal por meio do qual podem propor as alterações necessárias. E se essas alterações não puderem ser mescladas por algum motivo, a equipe do consumidor terá a opção de criar fork do projeto para atender às respectivas necessidades.

Por fim, ela padroniza práticas. Um desafio comum que as organizações de desenvolvimento enfrentam é que diferentes equipes geralmente divergem nas formas como elas operam. A criação de um programa InnerSource é uma grande oportunidade de adotar convenções padrão que possam ser usadas em todas as equipes de desenvolvimento, mesmo que elas não sigam práticas idênticas. Por exemplo, duas equipes podem preferir processos diferentes para aceitar contribuições. Padronizar a maneira como comunicam os diferentes processos torna muito mais fácil a contribuição de qualquer pessoa.

Esses exemplos são apenas alguns dos benefícios que os programas InnerSource oferecem. Para saber mais, confira Uma introdução ao InnerSource.

Definir um programa InnerSource no GitHub

Definir a visibilidade e as permissões do repositório

Os repositórios do GitHub podem ser configurados com três níveis de visibilidade. Os usuários que não atenderem ao requisito de visibilidade verão páginas "não encontradas" ao tentar acessar o repositório. Os níveis são:

• Repositórios públicos estão visíveis para todos. Use essa visibilidade para projetos que são verdadeiramente de software livre e oferecem acesso a pessoas dentro e fora da sua organização.
• Os repositórios internos só estão visíveis para os membros da organização que tem a propriedade deles. Use essa visibilidade para projetos InnerSource.
• Os repositórios privados estão visíveis apenas para o proprietário e para as equipes ou indivíduos que eles adicionam. Use essa visibilidade para projetos que só devem ser acessados por usuários e grupos específicos.

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

• Leitura O nível é recomendado para colaboradores não codificados que desejam visualizar ou discutir o projeto.
• O nível de triagem é recomendado para colaboradores que precisam gerenciar emissões e solicitações de pull proativamente sem acesso de gravação.
• O nível de gravação é recomendado para colaboradores que efetuam push ativamente para o projeto.
• O nível de manutenção é recomendado para gerentes de projetos que precisam gerenciar o repositório sem acesso a ações sensíveis ou destrutivas.
• O nível de administrador é recomendado para quem precisa de acesso completo ao projeto, incluindo ações sensíveis e destrutivas como gerenciar a segurança ou excluir um repositório.

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

Criar repositórios detectáveis

À medida que um programa InnerSource cresce, o número de repositórios também aumenta significativamente. Embora seja ótimo ter todos esses ativos disponíveis para a organização, pode se tornar um desafio encontrar conteúdo com eficiência. Para resolver esse problema proativamente, uma prática recomendada para as equipes é considerar o que pode ser feito para facilitar a localização e o trabalho de outras pessoas com os respectivos repositórios.

Algumas das melhores práticas incluem:

• Usar um nome de repositório descritivo, como warehouse-api ou supply-chain-web.
• Incluir uma descrição concisa. Uma ou duas frases devem ser suficientes para que os usuários potenciais saibam se o projeto pode atender às necessidades deles.
• Licencie seu repositório para que os clientes saibam como podem usar, alterar e distribuir o software.
• Incluir um arquivo README.md no repositório. Esse arquivo é usado pelo GitHub como a página de aterrissagem quando as pessoas acessam o repositório.

Adicionar um arquivo LEIAME

Um arquivo README comunica as expectativas para seu projeto e ajuda a gerenciar contribuições. Os arquivos README podem:

• Articular a finalidade e a visão do projeto para que potenciais consumidores saibam se o projeto atende às necessidades deles.
• Oferecer auxílios visuais, como capturas de tela ou exemplos de código, para ilustrar o projeto em ação.
• Incluir links para uma versão de produção ou demonstração do aplicativo para revisão.
• Definir expectativas para os pré-requisitos e procedimentos de implantação.
• Incluir referências aos projetos dos quais você depende. Essas referências são uma boa maneira de promover o trabalho de outras pessoas.
• Usar o Markdown para orientar os leitores em um conteúdo formatado corretamente.

Se você colocar seu arquivo README no diretório raiz do seu repositório ou no diretório oculto .github ou docs, o GitHub reconhecerá e exibirá automaticamente seu README aos visitantes do repositório. Se um repositório contiver mais de um arquivo README, o arquivo mostrado nos links será escolhido nos locais na seguinte ordem: o diretório .github, o diretório raiz do repositório e, por fim, o diretório docs.

Confira alguns exemplos LEIAME incríveis.

Depois que o projeto for lançado, use email e outros canais de rede para promovê-lo. Atingir um público-alvo apropriado pode produzir um aumento significativo na participação do projeto.

Gerenciar projetos no GitHub

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

Para resolver proativamente esse problema, o GitHub procura um arquivo CONTRIBUTING.md na raiz (/docs ou /.github) de um repositório. Use esse arquivo para explicar a política de contribuição para o projeto. Os detalhes exatos podem variar, mas é uma boa ideia informar aos possíveis colaboradores quais convenções o projeto segue. Por exemplo, onde a equipe está procurando por solicitações de pull, quais detalhes são solicitados para relatórios de bugs e assim por diante.

Se houver um CONTRIBUTING.md, o GitHub apresentará um link para ele quando os usuários criarem problemas ou solicitações de pull para que eles possam 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 por revisar modificações de código.

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

O GitHub dá suporte a modelos iniciais para novas emissões e solicitações de pull. Use esses modelos para fornecer o texto de descrição inicial para um problema ou solicitação de pull recém-criada.

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

É o mesmo para solicitações de pull, exceto pelo fato de que o caminho é .github/PULL_REQUEST_TEMPLATE.md.

Confira alguns Modelos de emissão e solicitação de pull incríveis do GitHub.

Definir fluxos de trabalho

Para projetos que fomentam contribuições externas, especifique 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 de pull devem ser abertas e quaisquer outros detalhes que pessoas de fora da equipe do repositório devem saber antes de enviar o código. Se você ainda não tiver um fluxo de trabalho em mente, considere o fluxo do GitHub.

Você deve comunicar uma estratégia para gerenciar versões e implantações. Essas partes do fluxo de trabalho afetarão o branch e a mesclagem do dia a dia, portanto é importante comunicá-las aos colaboradores. Saiba mais sobre como eles se relacionam com sua Estratégia de branch do Git.

Medir o sucesso do programa

Qualquer equipe que se aventurar no InnerSource deve pensar nos tipos de métricas que desejam controlar para medir o sucesso do programa dela. Embora as métricas tradicionais como "tempo de colocação no mercado" e "bugs relatados" ainda sejam aplicáveis, elas não vão necessariamente ilustrar os benefícios obtidos por meio do InnerSource.

Em vez disso, considere adicionar métricas que mostrem como a participação externa melhorou a qualidade do projeto. O repositório está recebendo solicitações de pull de fontes externas que corrigem bugs e adicionam recursos? Há participantes ativos em discussões sobre o projeto e o futuro? O programa está inspirando uma expansão do InnerSource que impulsiona os benefícios em outro lugar da organização?

Em resumo, as métricas são difíceis, principalmente quando se trata de medir o valor e o impacto de contribuições individuais e da equipe. Se forem utilizadas indevidamente, as métricas poderão prejudicar a cultura, os processos existentes e diminuir o sentimento coletivo com relação à organização ou à equipe de liderança. Ao pensar em medir a adoção do InnerSource, considere as seguintes orientações sobre métricas:

• Processo de medida, não saída
  • Tempo de retorno da revisão de código
  • Tamanho da solicitação de pull
  • Trabalho em andamento
  • Tempo para abrir
• Medir com relação a destinos e não absolutos
• Medir equipes e não indivíduos
  • Número de colaboradores exclusivos de um projeto
  • Número de projetos que reutilizam código
  • Número de @mentions entre equipes

Saiba mais sobre os sucessos que outros obtiveram nesses estudos de caso da InnerSource.