Em que estágio de um projeto de código aberto você deve convidar contribuições da comunidade? [fechadas]

Fiquei pensando em obter contribuições para um novo produto de código aberto que minha equipe desenvolverá. Existe um incentivo para que possamos obter o máximo apoio da comunidade em geral, mas também vejo isso absorvendo muito tempo, garantindo que terceiros localizados fora do nosso escritório estejam no caminho certo quanto a qualidade do código. Também no início do projeto, é provável que tenhamos muitas discussões informais dentro da equipe principal sobre o design do sistema, picos, etc. e colocá-las on-line para permitir o envolvimento da comunidade será demorado e eu posso imaginar que poderia fazer isso. discussão menos eficaz.

Existe um lado mais humano nisso que provavelmente precisa ser considerado: permitir que o envolvimento da comunidade no processo de design também tenha seus benefícios em relação à propriedade percebida do projeto, e sempre há uma chance de que o envolvimento precoce possa detectar problemas que o núcleo equipe não percebeu.

Então a pergunta: em que estágio de um projeto de código aberto você deve convidar contribuições da comunidade?

Bem no começo! Você quer que a comunidade sinta que eles têm um interesse genuíno em seu projeto, caso contrário, eles sentirão que estão sendo usados ​​como trabalho livre.

Toda a comunicação deve ser feita por meio de uma lista de discussão ou fórum público, mais uma vez, isso aprimora a idéia da comunidade.

Você pode atenuar o problema de 'projetar por comitê' apresentando uma visão clara em suas postagens iniciais na lista de discussão, por exemplo,

"Então, estamos vendo um modelo de domínio para representar nossa Pet Store (conforme o JIRA-4). Alguém vê algum problema importante com esse modelo?"

Em termos de aceitação de contribuições físicas reais, você deve começar aceitando patches e executando revisões de código público nelas. Dessa forma, os colaboradores já podem ver publicamente que tipo de padrões de codificação precisam aderir. Certifique-se de que seus commits também estejam disponíveis em uma lista de emails de commit - você precisa manter os mesmos padrões!

Também vale a pena ter padrões de projeto em um Wiki ou em algum documento desse tipo.

Leia http://www.producingoss.org para obter mais detalhes sobre como executar um projeto de código aberto bem-sucedido.

Isso foi discutido detalhadamente na conversa do IO no Google, Myth of the genius programmer , por Brian Fitzpatrick e Ben Collins-Sussman, do Subversion. Em suma, eles concluíram que não deveria ser tão cedo que ainda não há nada (ou seja, "venha ver o meu projeto incrível! Ainda não há muito aqui, mas muitas coisas incríveis estão planejadas!") Ou tarde demais então todas as decisões já foram tomadas (é difícil falar uma palavra sobre um projeto solo).

Eu concordo com Martijn Verburg . Você deve começar a solicitar contribuições desde o início. Eu escrevi um pouco sobre isso antes.

O resumo dessa publicação é que o software apodrece. Se você deseja mantê-lo fresco, você deve fazer a manutenção. E quanto mais popular um projeto se torna, mais bugs serão encontrados, mais recursos serão adicionados e mais essa tarefa de manutenção vai atolá-lo.

De fato, este é um problema muito comum. Há uma grande palestra de Fat chamada O que é código aberto e por que me sinto tão culpado? Nesta palestra (que eu recomendo que você assista), ele conta a história de um de seus projetos de OSS e, com o tempo, passou a maior parte do tempo livre realizando tarefas de triagem e gerenciamento de tickets. E ele fala sobre como isso foi prejudicial. O que é algo que eu posso simpatizar completamente.

A solução, é claro, é adicionar pessoas ao projeto com antecedência e frequência. Seu tempo é limitado e valioso. Invista no crescimento de sua base de colaboradores, e o restante dos problemas começará a se cuidar.

Como digo no final do meu post: "O que é mais importante para o seu projeto: recursos ou futuro? Escolha um e priorize seus esforços de acordo."