Projetos Inner Source

O que são projetos Inner Source?

Um projeto Inner Source é um projeto proprietário (é só seu/só da empresa) mas que aplica os padrões de Open Source, como código disponível para todos, com a diferença de que nem todos podem distribuir esse software.

Um projeto assim pode trazer vários benefícios, como:

  • Outros Devs podem ter acesso à outros códigos e olhar como que aquele grupo conseguiu resolver aquele problema
  • Meio de contato onde outras pessoas podem propor soluções, e caso elas não sejam aceitas, é possivel fazer um fork para editar e desenvolver aquela solução (mods)
  • Padronização de práticas (contribuição de um projeto Open Source fica igual a de um projeto Inner Source)

Aqui tem um artigo falando mais detalhadamente sobre softwares InnerSource e seus benefícios.

Criando um projeto InnerSource

O repositório deve ser colocado como Interno, e só está disponível para as pessoas que possem o GitHub Enterprise.

Após isso, é necessário configurar as permissões dos usuários que terão acesso.

  • Leitura/Read: recomendado para colaboradores que naõ trabalham com código e que apenas visualizam e discutem sobre o projeto.
  • Triagem/Triage: recomendado para colaboradores que precisam gerenciar Issues e PRs sem o acesso de escrita
  • Gravação/Write: colaboradores que editam e realizam push ativamente no projeto
  • Manutenção: recomendado para gerente de projeto que precisam gerenciar o repo sem o acesso a ações confidenciais
  • Admin: acesso total ao projeto.

Boas práticas

  • Usar um bom nome para o repositório, como comunicacao-api ou supply-chain-web
  • Uma boa descrição. Geralmente uma ou duas frases é o suficiente
  • Licenciar o repositório
  • Incluir um README com um resumo do projeto
    • Imagens de funcionamento
    • Links de apoio
    • Pré-requisitos
    • Como rodar
    • Referências de outros projetos que este depende

Arquivos

OBS.: Se tiver mais de um README, o GitHub exibe na página inical do repositório nesta seguinte ordem de prioridade:

      Pasta .github
      Pasta raiz do repositório
      Pasta docs
Alguns exemplos de READMEs bem legais

Também é importante adcionar um arquivo CONTRIBUTTING.md para mostrar as pessoas como elas podem contribuir.

Também é interessante adicionar m arquivo CODEOWNERS ao repositório para definir quais indivíduos ou equipes para revisar as modificações do código. Veja esse artigo para mais informações.

Modelos/templates prontos

É possivel criar templates para quando uma pessoa for criar uma nova Issue ou solicitar um PR. É só criar um arquivo ISSUE_TEMPLATE.md e salvar na pasta .github que o GitHub já reconhece como um template para as Issues. A mesma coisa para os PRs (PULL_REQUEST_TEMPLATE.md).

Aqui tem um repositório com alguns templates.

Fluxos de trabalho

Especifique como que o projeto segue (como que funcionam as branches e como trabalhar nelas, como abrir os PRs, como funciona o sistema de versões)

Estabelecer métricas

É importante estabelecer métricas para saber se o projeto está encaminhando bem. Métricas com "tempo no mercado" "bugs relatados" são boas mas para o modelo InnerSource, seria mais interessante adicionar métricas que mostrem como a participação externa do público melhorou a qualidade do projeto.

Aqui possui um artigo com mais instruções sobre um construir um projeto Inner Source com o passo a passo e boas práticas