Aquí está mi lista de verificación con respecto a la madurez del proyecto:
¿Ha alcanzado el proyecto su hito inicial?
Evitaría agregar cualquier código si no ha alcanzado su hito inicial autodescrito. No sugiero que siempre debe confiar en un desarrollador que afirma que su proyecto está listo para la producción y siempre tratar de evaluar tales afirmaciones, pero definitivamente debe confiar en ella cuando le dice que no, es decir, etiquetar el software como versión 0.x, alfa, beta, candidato de lanzamiento, etc.
¿Hay documentación adecuada?
Un proyecto perfecto ofrecería:
- Guía de usuario completa con ejemplos
- Una guía de integración / extensión si es una biblioteca
- Documentación API
- Código fuente completamente documentado
- Un rastreador de problemas públicos
¿Los desarrolladores siguen comprometidos con el proyecto?
Nunca se puede saber si los desarrolladores se mantendrán comprometidos en el futuro, a menos, por supuesto, que sea un proyecto respaldado por la fundación / empresa. Pero casi siempre se puede saber si están comprometidos en este momento, al verificar:
- Actividad de confirmación reciente
- Funciones recientes (no solo correcciones de errores)
- Actividad de documentación reciente (actualizaciones de documentos, publicaciones de blog, etc.)
También un buen indicador de la madurez del proyecto es una segunda generación de desarrolladores, desarrolladores activos que se involucraron después de los hitos iniciales.
¿Son accesibles los desarrolladores?
- ¿Responden a los errores?
- ¿Proporcionan otros medios de contacto, además de un rastreador genérico de problemas? Este es un elemento menor en la lista de verificación, pero para proyectos de desarrollador único, medios alternativos de contacto podrían ayudar en casos como el "caso del desarrollador perdido" .
Ahora, para sus preguntas más específicas:
Velocidad
En un proyecto con un rastreador público de problemas, definitivamente verificaría para ver cuánto tiempo lleva cerrar los problemas. Por supuesto, la velocidad no siempre significa calidad, por lo que probablemente pasaría por problemas cerrados, elegiría algunos que consideraría importantes y evaluaría el tiempo de respuesta y la calidad de los desarrolladores.
Compatibilidad de licencia
En cuanto a cuestiones legales, nunca integre un proyecto de código abierto en su base de código si no está 100% seguro de que su uso es compatible con su licencia. En caso de duda, siempre puede preguntar a los desarrolladores del proyecto, o incluso preguntar aquí.
Exageración comunitaria
Siempre debes evaluar el bombo publicitario. Las recomendaciones de otros desarrolladores son casi siempre un indicador suficientemente bueno de la madurez del proyecto.
Todos los elementos de la lista de verificación son opcionales, excepto la compatibilidad de la licencia. He integrado muchos proyectos muertos o indocumentados en mi código, siempre depende de cuáles sean sus necesidades específicas y de cómo ve evolucionar su propio código.
