Voici ma liste de contrôle concernant la maturité du projet:
Le projet a-t-il atteint son jalon initial?
J'éviterais d'ajouter du code s'il n'a pas atteint son jalon initial auto-décrit. Je ne suggère pas que vous fassiez toujours confiance à un développeur affirmant que son projet est prêt pour la production et que vous essayiez toujours d'évaluer de telles revendications, mais vous devriez certainement lui faire confiance quand elle vous le dit non, c'est-à-dire étiqueter le logiciel comme la version 0.x, alpha, beta, release candidate et ainsi de suite.
Existe-t-il une documentation adéquate?
Un projet parfait offrirait:
- Guide d'utilisation complet avec des exemples
- Un guide d'intégration / d'extension s'il s'agit d'une bibliothèque
- Documentation API
- Code source entièrement documenté
- Un outil de suivi des problèmes publics
Les développeurs sont-ils toujours engagés dans le projet?
Vous ne pouvez jamais dire si les développeurs resteront engagés à l'avenir, à moins bien sûr qu'il s'agisse d'un projet soutenu par une fondation / entreprise. Mais vous pouvez presque toujours dire s'ils sont commis dès maintenant, en vérifiant:
- Activité de validation récente
- Fonctionnalités récentes (pas seulement des corrections de bugs)
- Activité récente de documentation (mises à jour de documents, articles de blog, etc.)
Un deuxième indicateur de la maturité du projet est également une deuxième génération de développeurs, des développeurs actifs qui se sont impliqués après les étapes initiales.
Les développeurs sont-ils joignables?
- Répondent-ils aux bugs?
- Fournissent-ils d'autres moyens de contact, en dehors d'un outil de suivi des problèmes générique? Il s'agit d'un élément mineur de la liste de contrôle, mais pour les projets à développeur unique, des moyens de contact alternatifs pourraient aider dans des cas comme le "cas du développeur manquant" .
Maintenant, pour vos questions plus spécifiques:
Rapidité
Dans un projet avec un tracker de problème public, je vérifierais certainement pour voir combien de temps faut-il pour que les problèmes soient résolus. Bien sûr, la vitesse ne signifie pas toujours la qualité, donc je passerais probablement par des problèmes résolus, en choisirais quelques-uns que je considérerais importants et évaluerais le temps de réponse et la qualité des développeurs.
Compatibilité des licences
En ce qui concerne les questions juridiques, n'intégrez jamais un projet open source dans votre base de code si vous n'êtes pas certain à 100% que votre utilisation est compatible avec sa licence. En cas de doute, vous pouvez toujours demander aux développeurs du projet, ou même demander ici.
Battage médiatique communautaire
Vous devez toujours évaluer le battage médiatique. Les recommandations des autres développeurs sont presque toujours un assez bon indicateur de la maturité du projet.
Chaque élément de la liste de contrôle est facultatif, à l'exception de la compatibilité des licences. J'ai intégré de nombreux projets morts ou non documentés dans mon code, cela dépend toujours de vos besoins spécifiques et de la façon dont vous voyez votre propre code évoluer.
