Como estabelecer um programa open-source

Aqui, discutimos as principais considerações para estabelecer um programa open-source.

O que queremos dizer com "código aberto"?

Um programa de código aberto é mais do que o acesso público a uma base de código. Trata-se de expor um projeto dinâmico para a participação de qualquer pessoa que se queira envolver. Quando executado corretamente para um projeto apropriado, um programa de código aberto pode ajudar a impulsionar melhorias substanciais na qualidade do seu produto.

Uma das principais razões pelas quais as empresas recorrem a projetos em open-source é quererem envolver a comunidade. Os projetos conhecidos recebem contribuições significativas da comunidade e obtêm-nas gratuitamente.

Não se trata necessariamente de altruísmo. Pessoas e organizações consomem projetos porque veem um benefício pessoal ou empresarial. Quando o projeto não atende às suas necessidades ou expectativas, eles podem usar a oportunidade para resolver bugs ou adicionar recursos. Em vez de reter essas melhorias em bifurcações privadas, eles são obrigados a contribuir com essas alterações de volta para o repositório de origem para se tornarem parte da linha de base do projeto. Este ciclo virtuoso de melhoria é o motivo pelo qual muitas empresas produzem software usando o modelo de código aberto.

Objetivos de open-source

Para recapitular, existem três dimensões para a participação em software open-source:

• Consumidores, que estudam ou utilizam os repositórios de outros.
• Contribuidores, que estão ativamente envolvidos na melhoria dos repositórios de outros.
• Produtores, que constroem e mantêm os seus próprios repositórios abertos a outros.

À medida que as organizações pensam mais profundamente sobre o que querem obter de cada dimensão, é boa prática fazer um balanço do ponto em que estão atualmente. Há cinco níveis de processo dentro de cada dimensão.

• Ad hoc, que não têm qualquer processo implementado. O sucesso depende dos esforços individuais.
• Geridos, cujo processo está parcialmente documentado. O sucesso depende da disciplina.
• Definidos, que possuem um processo documentado, padronizado e integrado. O sucesso depende da automatização.
• Medido, que tem um processo gerido quantitativamente. O sucesso depende da medição das métricas em relação aos objetivos do negócio.
• Otimizados, que têm um processo que está continuamente e confiavelmente melhorando através de mudanças incrementais e inovadoras. O sucesso depende da redução do risco de mudança.

Para entender melhor a situação da sua organização, confira as autoavaliações de código aberto.

O que deve criar em open-source?

Muitos projetos não estão destinados à grandeza de código aberto. Embora seus critérios possam variar com base nos objetivos e no nível de processo da sua empresa, aqui estão alguns critérios recomendados a serem considerados antes de abrir um projeto:

• O seu projeto contém propriedade intelectual que pretende proteger? Se sim, o código aberto da sua origem cederia o seu valor. Não abra o código-fonte desses tipos de projetos, a menos que sinta que os benefícios superam os riscos.

• O projeto está num estado estável com código de boa qualidade? O projeto não precisa ser perfeito, mas os potenciais colaboradores podem se afastar se o projeto estiver em péssima forma.

• O seu projeto é útil para pessoas fora da sua empresa? Se não, então você provavelmente não está recebendo nenhuma participação.

• As pessoas fora da sua empresa podem contribuir? Eles precisam de acesso a todas as dependências do projeto, processos de compilação e o que mais for necessário para executar o projeto. Se não puderem executá-lo, não poderão contribuir.

• A sua equipa tem a largura de banda necessária para suportar um programa open-source? Se não, espere até que o faça. Se você abrir um projeto de código aberto e não apoiá-lo, poderá perder a oportunidade de construir uma comunidade de confiança.

Estas questões são apenas algumas das considerações mais comuns. Sua organização pode ter outros problemas de negócios ou conformidade para ter em mente.

Conceber um programa open-source

A execução de um programa open-source é semelhante à execução de um programa InnerSource, mas para uma audiência pública. Como resultado, há mais algumas considerações.

Definir expectativas da comunidade

Os arquivos gostam README.md e CONTRIBUTING.md são ainda mais importantes porque estão sendo expostos a pessoas que não têm seu contexto organizacional. Eles precisam ser avaliados a partir da perspetiva de alguém de fora da empresa para garantir clareza.

Além disso, o seu código de conduta é uma política importante a expressar. O padrão é adicionar um CODE_OF_CONDUCT.md arquivo à raiz do repositório e usá-lo para explicar o comportamento esperado dos participantes da sua comunidade. Vários grupos em sua organização devem revisar este documento, incluindo sua equipe jurídica. Felizmente, existem muitos códigos de conduta normalizados disponíveis para começar. Muitos projetos utilizam estes códigos tal como estão sem serem modificados. Saiba mais no Guia de códigos de conduta de código aberto.

Preparar os colaboradores para manter um repositório

Os funcionários podem não ter experiência em trabalhar com a comunidade de código aberto. Para ajudá-los a se preparar, recomendamos que a empresa ofereça um conjunto de guias que abranjam as principais coisas que todos devem saber antes de começar. Esses guias devem ser postados em um repositório ou portal interno que seja mantido regularmente e acessível apenas aos funcionários da empresa. Os guias a seguir são alguns dos mais importantes:

• Um guia "Devemos abrir este projeto?" que fornece uma estrutura para decidir se um projeto candidato deve ou não ser de código aberto. Este guia pode ser estruturado como um fluxograma, conjunto de perguntas ou lista de considerações.

• Uma lista de verificação de configuração que inclui todos os itens de trabalho que uma equipe precisa concluir antes e depois do lançamento de um projeto de código aberto. Essa lista deve incluir a obtenção de aprovação para abrir o projeto, revisões de código para garantir que dados confidenciais sejam removidos antes que o projeto entre em operação, uma marca registrada ou pesquisa de projeto de código aberto para garantir que não haja um conflito de nomenclatura, e assim por diante.

• Uma lista de contatos para pessoas-chave em sua organização que talvez precisem ser contatadas caso seja necessário suporte direto dos mantenedores. Esta lista deve incluir pessoas da segurança do software, da segurança do site, do departamento jurídico, das relações públicas, etc.

• Um link para um repositório inicial que pode ser clonado como ponto de partida. Deve conter um ficheiro README de exemplo, uma licença, um código de conduta, um guia de contribuição e quaisquer outros ficheiros de suporte que qualquer projeto em open-source da sua empresa precisa de ter. Não deve conter nada que não queira acidentalmente emitir para uma audiência pública.

• Um guia do mantenedor que explica as responsabilidades que um mantenedor tem em manter o repositório íntegro. Essas responsabilidades incluem manter a documentação do repositório atualizada, garantir que os problemas e solicitações pull recebam a atenção das pessoas certas em tempo hábil, e assim por diante.

• Um guia de comunicações que oferece aos mantenedores do repositório orientação para alguns dos tópicos que você prefere não incluir em arquivos públicos, como README.md, CONTRIBUTING.mdou CODE_OF_CONDUCT.md. Esses assuntos podem ser tópicos de negócios sensíveis, como não discutir concorrentes; ou tópicos de conduta mais gerais, como reconhecer adequadamente os principais contribuidores.

• Um FAQ interno que fornece respostas aprovadas para perguntas comuns. Esta lista é especialmente útil se houver sutilezas legais para os tópicos que sua empresa pode discutir no decorrer da manutenção de um programa de código aberto.

• Uma política de licença que lista quais licenças foram aprovadas ou rejeitadas pelo departamento jurídico para consumo ou contribuição de código aberto.