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.