Como saber se um projeto de código aberto está maduro o suficiente para ser usado em um produto?

Existem alguns projetos de código aberto que eu gostaria de incorporar a um produto no trabalho. Não temos a largura de banda nem o conhecimento necessário para fazer isso sozinhos. Eu os encontrei pesquisando no Google. Não conheço nenhum "ator importante" que utilize os projetos, mas sou bastante encorajado pelo que vejo.

Agora, estou um pouco preocupado com a quantidade de risco a que estou exposto usando o projeto de código aberto do joe-blow. Se me levar a 95% do caminho, talvez os 5% restantes sejam fáceis de adicionar ou corrigir. Talvez não seja trivial.

Como as pessoas determinam se um projeto de código aberto é maduro o suficiente para ser usado em um produto?

Este não é um projeto de hobby, portanto, estabilidade, facilidade de manutenção etc. são fundamentais.

Os critérios que eu uso, desde que o projeto atenda aos meus requisitos:

1. Existe uma comunidade ativa, com pessoas capazes de prestar assistência?
2. A licença é apropriada para o meu desenvolvimento?
3. O produto ainda está em desenvolvimento ativo?
4. É uma estrutura comumente usada?
5. Posso encontrar opiniões / postagens em blog / etc sobre o produto e como as pessoas se integraram a ele?

4 e 5 realmente não ajudam em projetos de nicho, o que parece ser o seu.

O mais importante é que ele atende aos seus requisitos? Se você acha que sim, a próxima coisa a fazer é usar um equipamento para testar o projeto e ver se você pode fazer o que deseja. Isso lhe dará uma ideia da API (se for uma biblioteca) e como ela funciona.

No final do dia, se houver algo de código aberto que faça 90% do que você faz, bifurque-o, adicione a funcionalidade extra e devolva-a à comunidade. Eu já fiz isso antes em projetos comerciais.

1. Para o framework, geralmente eu só uso um framework grande e maduro, com muitos módulos pré-escritos e uma grande comunidade. Geralmente, escolher uma estrutura sobre a outra não reduziria muito a quantidade de trabalho que você precisa para gastar em seu próprio código; algumas estruturas podem incentivar um código mais bonito, outras podem facilitar certas operações, mas geralmente somam muito pouca diferença para o esforço total de desenvolvimento. No entanto, as estruturas populares teriam mais módulos pré-escritos que você pode aproveitar e é assim que geralmente você pode economizar muito mais tempo e esforço.
2. Para uma pequena biblioteca que não seja de estrutura, geralmente você poderá fazer as modificações sozinho, se necessário, sem muitos problemas; portanto, geralmente consideraria ter a comunidade como um bônus adicional. A maioria das bibliotecas pequenas é gerenciada apenas por uma única pessoa, mas ainda é melhor do que construir você mesmo. No entanto, para bibliotecas grandes, é essencial ter uma comunidade ativa e madura e a documentação, porque é improvável que você possa fazer alterações com a mesma facilidade.
3. Licença é essencial. Para bibliotecas individuais, é provável que você precise fazer modificações na biblioteca; portanto, é essencial que a licença deles permita que você faça isso nos termos com os quais você concorda.

Para bibliotecas pequenas, você deve sempre assumir que precisará bifurcar-se e que o projeto já foi abandonado. Isso geralmente não é um problema, especialmente se o projeto estiver hospedado no Github ou BitBucket, porque eles facilitam estupidamente o projeto de outras pessoas. Para bibliotecas pequenas, você sempre pode assumir a manutenção do projeto, se o mantenedor original se foi ou se está planejando levar a direção do projeto para lugares para os quais não deseja ir.

Estou menos preocupado com a atividade do projeto, uma biblioteca madura que alcançou seu senso de "perfeição" geralmente só precisaria fazer correções de bugs, para que sua atividade diminuísse. A atividade do projeto é importante apenas se a biblioteca envolver um destino que está evoluindo ativamente, por exemplo, um wrapper para serviço externo precisaria ser constantemente atualizado à medida que o serviço externo evoluir, para que o desenvolvimento ativo seja essencial, mas uma biblioteca matemática não precisará de muito novo desenvolvimento, uma vez que possui todos os recursos necessários.

Para bibliotecas maiores, as coisas se tornam mais difíceis. Assumir o controle é muito mais envolvido, felizmente as bibliotecas maiores geralmente não se movem tão rápido, pois geralmente são mais maduras.

Como o @Sam disse em sua resposta, concordo que a coisa mais importante na avaliação da biblioteca de código aberto é o quanto ela se adapta às suas necessidades. Depois que qualquer problema de licença é resolvido, o uso de uma biblioteca de código-fonte aberto raramente é um erro, pois você sempre pode bifurcar-se se tudo der errado.

Procure no rastreador de erros do projeto. Se você vir muitos tickets arquivados por muitas pessoas diferentes e respostas de várias pessoas também, isso é um bom sinal. Mais tickets de bugs == maior comunidade de usuários == maior probabilidade de estar pronto para uso da produção por você.

As notícias não são boas, mas isso não significa que estão incorretas: você não sabe.

Se houvesse implementações análogas na produção, você saberia que isso é viável, mas como você disse, nenhum "grande ator" usa os projetos.

Se você tivesse se desenvolvido internamente, saberia, mas, como disse, não possui os recursos.

É razoável querer saber, mas ... você não.

Espero que essa resposta ajude, porque você deve ter planos de contingência para desligar qualquer tecnologia da qual depende, mas não controla ... e saber que não sabe se é confiável é um passo nessa direção.

A questão deve ser colocada de maneira diferente. O que você realmente está perguntando é : usar este projeto de código aberto da melhor maneira para desenvolver o produto?

Isso necessariamente envolve não apenas o projeto de código aberto em questão, mas também suas outras opções. Se sua única outra opção é escrever tudo sozinho, é melhor usar o projeto, se puder entender o código suficiente para modificá-lo.

É claro que surge a outra questão de saber se o seu projeto é viável. Ou seja, você precisa estimar o esforço, incluindo qualquer risco de precisar corrigir ou concluir a funcionalidade que você espera que seja fornecida pelo código de código aberto. Se o projeto não for amplamente utilizado, você precisará revisar o código para isso.