¿Cómo saber si un proyecto de código abierto es lo suficientemente maduro como para usarlo en un producto?

Hay algunos proyectos de código abierto que me gustaría incorporar a un producto en el trabajo. No tenemos el ancho de banda ni la experiencia en el tema para hacerlo nosotros mismos. Encontré esto buscando en Google. No conozco a ningún "jugador importante" que utilice los proyectos, pero estoy bastante animado por lo que veo.

Ahora, estoy un poco preocupado por la cantidad de riesgo al que estoy expuesto al usar el proyecto de código abierto de joe-blow. Si me lleva el 95% del camino, quizás el 5% restante sea fácil de agregar o arreglar. Quizás no sea trivial.

¿Cómo hacen las personas para determinar si un proyecto de código abierto es lo suficientemente maduro como para usarlo en un producto?

Este no es un proyecto de pasatiempo, por lo que la estabilidad, el mantenimiento, etc. son primordiales.

Los criterios que uso, siempre que el proyecto se ajuste a mis requisitos:

1. ¿Existe una comunidad activa, con personas capaces de brindar asistencia?
2. ¿La licencia es apropiada para mi desarrollo?
3. ¿El producto todavía está en desarrollo activo?
4. ¿Es un marco de uso común?
5. ¿Puedo encontrar comentarios / publicaciones de blog / etc. del producto y cómo las personas se han integrado con él?

4 y 5 realmente no ayudan para proyectos de nicho que suena como el suyo.

Lo más importante es ¿cumple con sus requisitos? Si cree que es así, lo siguiente que debe hacer es hacer un arnés para probar el proyecto y ver si puede hacer lo que quiere que haga. Esto le dará una idea de su API (si es una biblioteca) y cómo funciona.

Al final del día, si hay algo de código abierto que hace el 90% de lo que haces, bifurca, agrega la funcionalidad adicional y devuélvelo a la comunidad. He hecho esto antes en proyectos comerciales.

1. Para el marco, generalmente solo utilizo un marco grande y maduro con muchos módulos preescritos y una gran comunidad. En general, elegir un marco sobre el otro no reduciría mucho la cantidad de trabajo que necesita gastar en su propio código, algunos marcos pueden alentar un código más hermoso, otros pueden facilitar ciertas operaciones, pero en general suman muy poca diferencia con el esfuerzo total de desarrollo. Sin embargo, los marcos populares tendrían más módulos preescritos que puede aprovechar y así es como generalmente puede ahorrar mucho más tiempo y esfuerzo.
2. Para una biblioteca pequeña que no sea framework, generalmente podrá realizar modificaciones usted mismo si es necesario sin mucho problema, por lo que generalmente consideraría tener una comunidad como una ventaja adicional. La mayoría de las bibliotecas pequeñas solo son administradas por una sola persona, pero aún así son mejores que construir usted mismo. Sin embargo, para bibliotecas grandes, tener una comunidad madura y activa, y la documentación es esencial porque es poco probable que pueda hacer los cambios usted mismo tan fácilmente.
3. La licencia es esencial. Para las bibliotecas de un solo usuario, es probable que deba realizar modificaciones en la biblioteca, por lo tanto, es esencial que su licencia le permita hacerlo bajo los términos con los que estaría de acuerdo.

Para bibliotecas pequeñas, siempre debe suponer que necesitará bifurcar y que el proyecto ya está abandonado. Esto generalmente no es un problema, especialmente si el proyecto está alojado en Github o BitBucket, porque hacen que bifurcar el proyecto de otras personas sea estúpidamente fácil. Para bibliotecas pequeñas, siempre puede hacerse cargo del mantenimiento del proyecto usted mismo, si el responsable original se ha ido o si planean llevar la dirección del proyecto a lugares a los que no desea ir.

Estoy menos preocupado con la actividad del proyecto, la biblioteca madura que ha logrado su sentido de "perfección" generalmente solo necesitaría hacer correcciones de errores, por lo que su actividad se ralentizó. La actividad del proyecto solo es importante si la biblioteca involucra un objetivo que está evolucionando activamente, por ejemplo, un contenedor para servicio externo necesitaría actualizarse constantemente a medida que evoluciona el servicio externo, por lo que el desarrollo activo es esencial, pero una biblioteca matemática no necesitaría mucho nuevo desarrollo una vez que tenga todas las características que necesitaba.

Para bibliotecas más grandes, las cosas se vuelven más difíciles. Tomar el control es mucho más complicado, afortunadamente las bibliotecas más grandes generalmente no se mueven tan rápido, ya que generalmente son más maduras.

Como @Sam dijo en su respuesta, estoy de acuerdo en que lo más importante al evaluar la biblioteca de código abierto es cuánto se ajusta a sus requisitos. Una vez que se resuelve cualquier problema de licencia, el uso de una biblioteca de código abierto rara vez es un error porque siempre se puede bifurcar si las cosas van mal.

Mire en el rastreador de errores del proyecto. Si ve muchas entradas archivadas por muchas personas diferentes, y las respuestas provienen de una variedad de personas también, entonces es una buena señal. Más tickets de errores == comunidad de usuarios más grande == es más probable que esté listo para su uso en producción.

La noticia no es buena, pero eso no significa que sea incorrecta: no lo sabes.

Si hubiera implementaciones análogas en la producción, sabrías que es factible, pero como dijiste, ningún "jugador importante" usa los proyectos.

Si te hubieras desarrollado en casa, lo sabrías, pero como dijiste, no tienes los recursos.

Es razonable querer saber, pero ... no lo sabes.

Espero que esta respuesta ayude, porque debería tener planes de contingencia para desconectar cualquier tecnología de la que dependa pero no controle ... y saber que no sabe si es confiable es un paso en esa dirección.

La pregunta tiene que formularse de manera diferente. Lo que realmente está preguntando es si utilizar este proyecto de código abierto es la mejor manera de desarrollar el producto.

Eso implica necesariamente no solo el proyecto de código abierto en cuestión, sino también sus otras opciones. Si su única otra opción es escribir todo usted mismo, es mejor que use el proyecto si puede comprender que es código suficiente para poder modificarlo.

Entonces, por supuesto, surge la otra pregunta si su proyecto es viable en absoluto. Es decir, debe estimar el esfuerzo, incluido cualquier riesgo de tener que arreglar o completar la funcionalidad que espera que proporcione el código de código abierto. Si el proyecto no se usa ampliamente, tendrá que revisar el código para eso.