Como estabelecer um programa de software livre
Aqui, abordamos os principais aspectos a serem considerados ao estabelecer um programa de software livre.
O que queremos dizer com "código aberto"?
Um programa de código aberto envolve muito mais do que o acesso público a uma base de código. Trata-se de abrir um projeto ativo para participação de qualquer pessoa que queira se envolver nele. Quando executado adequadamente para um projeto apropriado, um software de código aberto pode ajudar a promover melhorias substanciais na qualidade do seu produto.
Um dos principais motivos que leva as empresas a converter projetos em software livre é o fato de desejarem o envolvimento da comunidade. Projetos populares recebem gratuitamente contribuições significativas da comunidade.
Não se trata necessariamente de ser altruísta. As pessoas e as organizações consomem os projetos porque enxergam nele um benefício pessoal ou empresarial. Quando o projeto não atende às suas necessidades ou expectativas, ele pode usar a oportunidade para resolver bugs ou adicionar recursos. Em vez de manter esses aprimoramentos em forks privados, elas são obrigadas a contribuir com essas alterações no repositório de origem, para que elas façam parte da linha de base do projeto. É devido a esse ciclo virtuoso de aprimoramentos que muitas empresas produzem programas de software usando o modelo de software livre.
Metas de software livre
Para recapitular, a participação em soluções de software livre envolve três dimensões:
- Os consumidores, que estudam ou usam os repositórios de outras pessoas.
- Os colaboradores, que estão envolvidos ativamente no aprimoramento dos repositórios de outras pessoas.
- Os produtores, que criam e mantêm os próprios repositórios que permanecem abertos para outras pessoas.
Conforme as organizações consideram mais profundamente o que desejam obter de cada dimensão, é uma boa prática fazer uma avaliação geral da situação em que se encontram. Há cinco níveis de processo em cada dimensão.
- Ad hoc, em que não há nenhum processo em vigor. O sucesso depende de esforços individuais.
- Gerenciado, em que há um processo parcialmente documentado. O sucesso depende da disciplina.
- Definido, em que há um processo documentado, padronizado e integrado. O sucesso depende da automação.
- Medido, em que há um processo gerenciado de maneira quantitativa. O sucesso depende da medição de métricas em relação às metas empresariais.
- Otimizado, em que há um processo que é aprimorado de maneira contínua e confiável por meio de alterações incrementais e inovadoras. O sucesso depende da redução dos riscos das alterações.
Para entender melhor onde sua organização se encontra, confira as Autoavaliações para software livre.
O que você deve converter em software livre?
Muitos projetos não terão bom desempenho se forem convertidos em código aberto. Embora seus critérios possam variar com base nas metas e no nível de processo da empresa, estes são alguns critérios recomendados a levar em consideração antes de converter um projeto de código aberto:
O projeto contém propriedade intelectual que você deseja proteger? Nesse caso, abrir o código-fonte implicaria em abrir mão de seu valor. Não converta esse tipo de projeto em código aberto a menos que você acredite que os benefícios superam os riscos.
Trata-se de um projeto estável, com boa qualidade de código? O projeto não precisa ser perfeito, mas possíveis colaboradores podem desistir dele caso seu estado inicial seja muito ruim.
O projeto é útil para pessoas de fora da empresa? Caso contrário, você não terá nenhuma participação.
Pessoas de fora da empresa podem contribuir? Elas precisam ter acesso a todas as dependências e aos processos de build do projeto e ao que mais for necessário para executá-lo. Se eles não podem executá-lo, eles não podem contribuir.
Sua equipe tem largura de banda para dar suporte a um programa de software livre? Se não, aguarde até que tenha. Se você converter um projeto de código aberto e não der suporte a ele, poderá perder a oportunidade de criar uma comunidade confiável.
Essas perguntas 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.
Criando um programa de software livre
A execução de um programa de software livre é semelhante à de um InnerSource, mas voltada para o público geral. Como resultado, há mais algumas considerações.
Definindo as expectativas da comunidade
Arquivos como README.md
e CONTRIBUTING.md
são ainda mais importantes, porque são expostos a pessoas que não têm o contexto da organização. Eles precisam ser avaliados da perspectiva de alguém de fora da empresa para garantir a clareza.
Além disso, o código de conduta é uma política importante a ser declarada. O padrão é adicionar um arquivo CODE_OF_CONDUCT.md
à raiz do repositório e usá-lo para explicar o comportamento esperado dos participantes em sua comunidade. Vários grupos na organização devem examinar este documento, incluindo a equipe jurídica. Felizmente, há muitos códigos de conduta padrão que podem servir como ponto de partida. Muitos projetos usam esses códigos no estado em que se encontram, sem modificações. Saiba mais no Guia de códigos de conduta para projetos de software livre.
Preparando os funcionários a manutenção de 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 aborde os principais aspectos que todos devem conhecer antes de começar. Esses guias devem ser postados em um repositório ou portal interno que seja mantido regularmente e acessível somente aos funcionários da empresa. Os guias a seguir são alguns dos mais importantes:
Um guia "Devemos converter este projeto em software livre?", que fornece uma estrutura para decidir se um projeto candidato deve ou não ser convertido em software livre. Esse guia pode ser estruturado como um fluxograma, um conjunto de perguntas ou uma 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 converter o projeto de software livre, revisões de código para garantir que dados confidenciais sejam removidos antes do lançamento do projeto, uma pesquisa de projeto de software livre ou de marca comercial para garantir que não haja conflitos de nomenclatura e assim por diante.
Uma lista de contatos das pessoas importantes na sua organização que talvez precisem ser contatadas caso o suporte direto dos mantenedores seja necessário. Essa lista deve incluir pessoas dos setores de segurança de software, segurança de site, relações públicas, jurídico e assim por diante.
Um link para um repositório inicial que possa ser clonado como um ponto de partida. Ele deve conter um exemplo de LEIAME, uma licença, um código de conduta, um guia de contribuição e qualquer outro arquivo de suporte que todos os projetos de software livre da empresa precisem ter. Ele não deve conter nada que você não gostaria que fosse disponibilizado acidentalmente para o público.
Um guia do mantenedor explicando as responsabilidades do mantenedor quanto à manutenção da integridade do repositório. Essas responsabilidades incluem manter a documentação do repositório atualizada, garantir que os problemas e as solicitações de pull recebam atenção das pessoas certas em tempo hábil e assim por diante.
Um guia de comunicação que ofereça diretrizes para os mantenedores do repositório com relação a alguns dos tópicos que você prefere não incluir em arquivos públicos, como
README.md
,CONTRIBUTING.md
ouCODE_OF_CONDUCT.md
. Esses assuntos podem ser tópicos confidenciais da empresa, por exemplo, não discutir concorrentes, ou tópicos de conduta mais gerais, por exemplo, como reconhecer adequadamente os principais colaboradores.Um arquivo de perguntas frequentes internas com as respostas aprovadas para perguntas comuns. Essa lista é especialmente útil se houver sutilezas legais nos tópicos que sua empresa pode discutir durante a 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 software livre.