Preparando para liberar código como código-fonte aberto [duplicado]

Escolha sua licença

Se o seu código foi código fechado até agora, a primeira coisa que você deve fazer é decidir em qual licença de código aberto ( GPL < = 2, GPL 3 , LGPL , BSD , Eclipse etc.) que você quer para usar.

Há prós e contras para cada um deles, então leia as restrições que eles colocam no código e decida quem você quer poder usá-lo. Atenção , o que você escolher, alguém irá reclamar - este é território de guerra santa e além do escopo desta questão.

• Um excelente recurso para determinar qual licença é a licença certa para você é o diferenciador de licenças muito abrangente e interativo , de Oxford Universities OSS Assista .

Sanitize seu repositório

Se o código em seu repositório não tiver sua licença escolhida aplicada a ele, eu passaria por todo o histórico de revisão até agora e aplicaria retroativamente (isso pode exigir uma nova base em cada ponto em que uma nova fonte arquivo é introduzido). Isso, no entanto, produzirá um belo repositório limpo que, quando você o liberar para o público, não possui revisões onde a licença escolhida não esteja em vigor.

Outra opção é iniciar seu repositório público no ponto de sua primeira versão, com um mínimo ou nenhum histórico até esse ponto.

Isso tem a desvantagem de que as pessoas não podem voltar pela sua história e descobrir como você chegou onde você está hoje, mas tem vantagem que as pessoas Não posso voltar pela sua história e descobrir como você chegou onde está hoje. * 8 ')

Quando a empresa para a qual trabalho faz o software que eu trabalho em código aberto, começamos produzindo apenas instantâneos do diretório de trabalho em pontos de liberação. Quando nos mudamos para usar repositórios públicos do github, iniciamos cada git repo no ponto em que um plug-in era (ou um conjunto de plug-ins era) movido para fora de svn , raramente incluindo qualquer histórico.

Considere uma licença dupla

Se você acha que pode haver interesse comercial em usar seu software, mas tem uma preferência ideológica por uma licença restritiva de reutilização, como a GPL 3, considere oferecer licenciamento duplo. Oferecendo licenças GPL 3 para download público, e licenças comerciais por uma taxa lhe dão o melhor dos dois mundos.

Fazer isso desde o início provavelmente causará menos atrito do que começar a oferecer licenças comerciais mais tarde. Se a sua comunidade se tornar popular, as pessoas podem acusá-lo de vender se você não estivesse certo sobre a possibilidade de exploração comercial mais tarde.

Considere um contrato de colaboração

Se você planeja fazer uma dupla licença, ou simplesmente deseja manter sua base de código, você precisará reimplantar as correções feitas por você mesmo ou fazer com que os colaboradores atribuam direitos sobre suas contribuições para você. Caso contrário, você descobrirá que suas contribuições impedem que você libere sua base de código sob outras licenças.

A resposta de Mason Wheeler para a pergunta O licenciamento de código aberto que meu código me limita mais tarde? fornece algumas boas informações sobre isso e como o projeto libsdl costumava lidar com esse problema.

Entretanto, esteja ciente de que, assim como a sua escolha de licença pode restringir as pessoas e organizações que usarão e contribuirão para o seu projeto, a sua escolha dependerá de um contrato de contribuinte. Algumas pessoas não ficarão felizes em contribuir para um projeto que exige que eles assinem um contrato de contribuição.

Contratos de Colaborador de Licença Dupla

O Contrato de colaboração da Oracle (links difíceis de ver nessa página) é uma boa modelo para um contrato de colaborador. Ele também é licenciado (CC) de uma maneira que você pode modificá-lo e reutilizá-lo.

A resposta por Mark Booth é excelente, mas fala apenas sobre licenciamento / versionamento, então eu gostaria de adicionar alguns pontos em um campo mais técnico que são os primeiros (ou não tão primeiro) passos para mim ao liberar código aberto.

1. Aplicar estilo e legibilidade . Ninguém quer contribuir para um projeto onde eles precisam passar meses para entender o básico. E ninguém quer ler e usar código como esse. Se você quiser que outras pessoas contribuam com o projeto, também seria ótimo especificar quais são os padrões de estilo a serem usados.

2. Limpeza . Mark Booth explicou por que pode ser aborrecedor deixar alguém acessar todas as revisões e ver como o projeto foi feito desde o início. Da mesma forma, você deve se livrar de grandes blocos de código comentado antes de liberá-lo (o que é uma prática ruim em todos os casos), ou remover os comentários que dizem sobre o que foi a modificação, quando foi feito, etc. uma prática ainda pior).

3. Certifique-se de que seu código-fonte tenha testes suficientes . É especialmente importante neste contexto, já que as pessoas virão sem saber em detalhes como sua aplicação é feita e quais são as ressalvas, e tentarão modificá-la, eventualmente quebrando o código.

4. Descreva seu projeto . O código pode ser ótimo. Se eu não tenho nenhuma ideia sobre o que é a aplicação, há poucas chances de eu contribuir para o projeto.

5. Descreva o que os contribuidores podem fazer . Alguns projetos de código aberto são muito próximos e aceitarão as contribuições somente após testes e revisões rigorosos e somente se acharem que precisam da contribuição em questão. Em outros projetos, por outro lado, contribuições são bem vindas. É sempre bom saber qual é o seu caso antes de começar a contribuir para isso.

6. Apresentar . Veja, o site da jQuery é bem feito, com design profissional, conteúdo de alta qualidade, etc. Faz com que você deseje participar do projeto. Se, por outro lado, você tem um site lento e feio com conteúdo que suga demais, as pessoas preferem ir e contribuir para outros projetos de código aberto.

7. Adicione ferramentas de suporte . Por exemplo, o rastreamento de erros não é uma opção para um projeto comercial. Por que seria para um open source? Também pode ajudar a saber quais são os pontos que precisam de contribuição. Se eu usar seu produto de código aberto, encontrar um bug, acesse o site de rastreamento de bugs e descubra que o bug é o número 1 da lista, ficarei mais motivado não só para resolvê-lo, mas também para confirmar minhas alterações. / p>

Construa e eles virão.

Se houver necessidade de sua ferramenta, as pessoas a encontrarão por meio de mecanismos de pesquisa e palavras de fóruns. Nunca é demais fazer alguns posts em fóruns de interesse especial relevantes para o domínio em que sua ferramenta está. Se houver, entre em um canal de IRC com pessoas de interesses semelhantes para informá-los sobre isso. Blog sobre isso (se você tiver um blog pessoal). Essencialmente, quanto mais publicidade você fizer, melhor. Dito isto, se não houver necessidade, as pessoas simplesmente não vão usá-lo.

Então, em resumo, sim, envie para o GitHub. Ative o recurso de problemas para que as pessoas possam registrar bugs e um Wiki se sua ferramenta for complexa o suficiente para garantir isso. Não desanime se você não conseguir hits imediatos. Às vezes, as ferramentas do SO podem demorar um pouco para coletar vapor (embora algumas delas também sejam um sucesso).

Boa sorte:)

Antes de analisar o Outro conselho, considere:

Governança

Como o seu projeto será gerenciado depois de concedê-lo à comunidade. O modelo de ditador benevolente funciona, mas as pessoas vão andar e bifurcar se não receberem benefícios do código / projeto.

Propriedade do código

Quem possui o código é muito importante, pois somente os proprietários (na legislação dos EUA) podem levar as pessoas ao tribunal para aplicar os direitos autorais.

É por isso que a FSF diz aos colaboradores para conceder a propriedade a eles, e eles, por sua vez, concedem acesso ao código sob a licença relevante (GPL, LGPL versão 2.0 ou 3.0).

Organizações de governança

Não sei ao certo o que está disponível no mundo PHP, mas há diversas plataformas e ecossistemas úteis para a governança de código. Cada um com sua própria licença e estrutura de governança.

• Free Software Foundation Licenças GNU
• Eclipse.org Licença pública Eclipse
• Apache.org Licença Apache

Outras considerações de licença

Onde o código será usado, quem irá reimplantá-lo, quais são as licenças atuais nas quais o código semelhante e a plataforma são implantados. Todas essas questões fornecem orientações sobre qual licença deve ser usada.

Se já não houver uma comunidade de interesse que você possa aproveitar, é muito difícil ter um projeto de sucesso sozinho.