Quando um projeto de código aberto está pronto para produção?

Quando você encontra uma nova biblioteca / projeto de código aberto, quais critérios você analisa antes de incorporá-lo à sua base de código-fonte.

• Há perguntas legais que você precisa responder?

• Você procura uma certa quantidade de velocidade de desenvolvimento?

• O burburinho da comunidade é uma razão suficientemente boa?

• Sua decisão muda se você é quem está na linha do projeto?

• A complexidade do domínio ou código muda sua maneira de pensar sobre isso?

Aqui está minha lista de verificação sobre a maturidade do projeto:

O projeto atingiu seu marco inicial?

Eu evitaria adicionar qualquer código se ele não atingisse seu marco inicial auto-descrito. Não sugiro que você sempre confie em um desenvolvedor afirmando que seu projeto está pronto para a produção e sempre tente avaliar essas afirmações, mas você definitivamente deve confiar nela quando ela lhe disser que não, ou seja, rotular o software como versão 0.x, alfa, beta, candidato a lançamento e assim por diante.

Existe documentação adequada?

Um projeto perfeito ofereceria:

• Guia do usuário completo com exemplos
• Um guia de integração / extensão, se for uma biblioteca
• Documentação da API
• Código fonte totalmente documentado
• Um rastreador de problemas públicos

Os desenvolvedores ainda estão comprometidos com o projeto?

Você nunca pode dizer se os desenvolvedores permanecerão comprometidos no futuro, a menos que seja um projeto apoiado por uma fundação / empresa. Mas quase sempre é possível saber se eles foram confirmados agora, verificando:

• Atividade de confirmação recente
• Recursos recentes (não apenas correções de bugs)
• Atividade recente da documentação (atualizações de documentos, postagens no blog etc.)

Também um bom indicador da maturidade do projeto é uma segunda geração de desenvolvedores, desenvolvedores ativos que se envolveram após os marcos iniciais.

Os desenvolvedores estão acessíveis?

• Eles respondem a bugs?
• Eles fornecem outros meios de contato, além de um rastreador genérico de problemas? Esse é um item menor da lista de verificação, mas para projetos de desenvolvedor único, meios alternativos de contato podem ajudar em casos como o "caso do desenvolvedor ausente" .

Agora, para suas perguntas mais específicas:

Velocidade

Em um projeto com um rastreador de problemas públicos, eu definitivamente verificaria quanto tempo leva para os problemas serem fechados. É claro que velocidade nem sempre significa qualidade, então eu provavelmente passaria por questões fechadas, escolheria algumas que consideraria importantes e avaliaria o tempo de resposta e a qualidade dos desenvolvedores.

Compatibilidade de licença

Quanto a questões legais, nunca integre um projeto de código aberto na sua base de código se você não tiver 100% de certeza de que seu uso é compatível com sua licença. Em caso de dúvida, você sempre pode perguntar aos desenvolvedores do projeto ou até mesmo perguntar aqui.

Hype da comunidade

Você sempre deve avaliar o hype. As recomendações de outros desenvolvedores são quase sempre um indicador suficientemente bom da maturidade do projeto.

Cada item da lista de verificação é opcional, exceto a compatibilidade da licença. Integrei muitos projetos mortos ou não documentados no meu código, sempre depende de quais são suas necessidades específicas e de como você vê seu próprio código evoluindo.

Além da resposta declarada por Yannis Rizos, eu tentaria em um breve projeto de teste ou lado, se possível. Isso permitirá que você se familiarize com as peculiaridades de um produto antes que algum importante esteja em risco. O projeto não deve ser muito pequeno, pois isso deixaria muito da base de código inexplorada. Dê uma volta para ver se pode fazer o que você quer dele sem muito trabalho. Se você não conseguir trabalhar o básico sozinho com a ajuda da documentação e uma ou duas perguntas para a comunidade do projeto, convém considerar procurar uma base de código com suporte mais adequado. Se o teste inicial funcionar para você, você pode começar a usá-lo de verdade. Eu tive que lidar com esse problema no passado e, depois das duas primeiras vezes, estabeleci como regra testar coisas novas antes de colocá-lo em produção,

Em termos de BP: a introdução de coisas novas nunca deve ser feita sem alguma forma de fase de preparação / aprendizado.