Liberando o software de código aberto muito em breve [fechado]

Eu acredito, pelo contrário, que você deve lançar um software de código aberto o mais rápido possível. Não há "muito cedo" para isso (mas deve compilar).

^{Ou pelo menos publique o código-fonte muito cedo e continuamente (por exemplo, por freqüentes empurra o github ), sem fazer versões formais .}

No entanto, é muito importante sinalizá-lo como fase alfa ou beta e, se possível, dizer (por exemplo, em um arquivo README ou TODO , em algum blog, etc ...) o que está faltando, não testado, ou em mau estado. Você também deve usar o número da versão para transmitir essas informações.

Com o software livre , o melhor que deve acontecer é que alguém dê uma olhada no código-fonte e proponha um pequeno remendo melhorando isso. É por isso que você faz o seu software gratuitamente!

^{Portanto, você precisa tornar visível o seu trabalho diário em seu software livre! Contribuidores externos ficariam chateados se o patch não funcionasse ou fosse uma duplicata do seu código-fonte de software recente.}

O que você deve ter medo é de ninguém se interessar pelo seu software (e contribuir para isso). Atrair interesse externo para um software livre (em particular, atrair colaboradores externos) é uma longa jornada.

TL; DR:

Lançamento antecipado. Liberar frequentemente.

Anedota pessoal:

Eu estava muito empolgado com o projeto em que estava trabalhando. Como, realmente animado. Não consegui dormir à noite animada. Então, eu empurrei meu co-dev para liberar v1.0 mais rápido do que ele queria.

Foi terrível. Nada funcionou do jeito que deveria. Havia bugs em cada turno, mas nós registramos e corrigimos. Nós até mesmo tivemos alguns pioneiros que apresentavam bugs que talvez não tivéssemos encontrado. Uma ou duas semanas depois, lançamos uma nova versão que abordava muitos dos problemas e depois voltamos para a criação de novos recursos.

A liberação antecipada foi a melhor coisa que poderíamos ter feito. Ele colocou o nosso produto na frente de usuários reais. Ao fazer estes bugs expostos, podemos ou não ter encontrado e tornado nosso projeto melhor. Ele também permite que os primeiros adeptos saibam que estamos falando sério sobre esse projeto. Haverá mais lançamentos e desenvolvimento ativo.

Poderia ter ido facilmente para o outro lado também. Nós poderíamos ter ignorado esses relatórios de bugs. Ou poderíamos não ter reagido rapidamente. Pode ter sido uma história diferente se levássemos 3 meses para lançar a v1.1 em vez de algumas semanas.

É o mesmo que com o software de código fechado. A comunicação é importante.

Informe aos usuários qual é o estado do software e por que ele está disponível para download.

O software sempre levará a problemas do cliente, independentemente de ser totalmente testado ou não. A maioria dos clientes aceita esse fato e alguns clientes nunca aceitam. Mas se o software levar a mais problemas do que se poderia razoavelmente esperar, há uma obrigação moral de informar o cliente sobre o risco que ele está assumindo. As informações devem estar em formato resumido (rótulos "Alpha / Beta / EarlyAccess") * e em detalhes: uma lista de problemas conhecidos, soluções alternativas e considerações especiais, por exemplo, se é provável que os dados possam estar corrompidos.

* Esteja ciente de que os usuários foram treinados por algumas grandes empresas de software a pensar em "Beta" como um estado em que o software é bastante sólido, portanto dizer ao usuário que o software é "Beta" não é informação suficiente. / p>     

Não existe responsabilidade moral alguma. Ninguém está sendo forçado a usar seu software meio cozido.

A única coisa com que se preocupar seria a sua credibilidade.

Minha experiência é que há um equilíbrio a ser alcançado.

Neste momento, estou trabalhando (no sentido de responder perguntas e fornecer sugestões de desenvolvimento, sem ver nenhum código) com um desenvolvedor que está produzindo o que parece ser um projeto FOSS muito interessante que utiliza código que escrevi. O lançamento público foi repetidamente adiado por realizações de alterações de design que tornarão o projeto muito melhor a longo prazo, mas que exigem reescritas significativas de código que já foram escritas e que já estavam "funcionando". Meu ponto de vista é que, se um release funcionando, mas imperfeito, fosse feito assim que houvesse algo para mostrar, idéias para mudanças (e patches reais) poderiam ter vindo da comunidade mais ampla que está interessada neste projeto e acelerado em vez de ter os problemas aparecem lentamente, um de cada vez, enquanto o desenvolvedor pensa neles e pede feedback de design de mim mesmo e de outros membros interessados da comunidade. Então, desse ponto de vista, sou muito mais um defensor de "lançar cedo, liberar com frequência".

Por outro lado, lançamentos de baixa qualidade podem fazer um novo projeto parecer ruim antes mesmo de decolar. Algumas armadilhas que eu vi incluem:

• Árvores de esqueleto com definições de interface, mas sem código.
• Código que não é compilado com sucesso para ninguém, exceto o desenvolvedor.
• Não há instruções sobre como criar / executar o programa.
• Nenhuma documentação de quais aspectos podem ser esperados para funcionar.
• Descrição pouco clara do que o programa faz ou fará.
• Falta de qualquer demonstração de utilidade.

Para o último ponto, estou pensando em coisas como:

• Compilador / interpretador que não pode nem mesmo compilar / executar um programa do tipo hello-world.
• Emulador que não pode, pelo menos, executar um exemplo de programa ou demonstrar que está fazendo alguma coisa.
• Ferramenta de processamento de imagens que não pode fazer nada além de carregar e salvar novamente a imagem não modificada.
• Jogo com nada além de uma tela de título.

Esses tipos de problemas levam a uma imagem de "vaporware" que pode ser difícil de abalar, a menos que você seja muito aberto sobre a falta de código de trabalho para começar.

Por fim, faça com que seus números de versão façam sentido. Não chame seu projeto "1.0" até que ele faça o que os usuários esperam que ele faça sem travar. Eu sempre tive sorte com o uso de números de versão em torno de "0,5" para lançamento público inicial e de lá, mas também vi coisas como "0,1" ou "0,10" que fazem sentido.

Há um caso em que liberar software livre pode ter consequências negativas. Algumas especificações são licenciadas ao público com a condição de que todas as implementações distribuídas ao público estejam em conformidade com a especificação completamente quando publicadas pela primeira vez. O editor proíbe legalmente que você distribua uma implementação em andamento da especificação. Sem uma licença específica negociada do editor da especificação, você deve compartilhá-la com ninguém até que ela passe em todos os testes. Isso força um "modelo de catedral" (como Eric S. Raymond chamou) nas implementações da especificação.

Uma especificação sob essa licença é a especificação da linguagem Java . Essa restrição se aplica a desenvolvedores de máquinas virtuais compatíveis com a JVM, mas, felizmente, não para desenvolvedores de aplicativos executados em uma JVM.

O artigo " 4 Shifty Details Sobre o 'Open Source' da Microsoft. NET "por Liu Qihao & Ciaran O'Riordan menciona a possibilidade de interpretar a Promessa de Patentes da Microsoft para Bibliotecas .NET e Componentes de Tempo de Execução para excluir implementações incompletas do CLR de maneira semelhante. Mas, novamente, isso não se aplica a aplicativos executados no CLR.