Lorsque vous trouvez une nouvelle bibliothèque / projet open source, quels critères examinez-vous avant de l'intégrer dans votre base source.
Y a-t-il des questions juridiques auxquelles vous devez répondre?
Cherchez-vous une certaine vitesse de développement?
Le buzz communautaire est-il une raison suffisante?
Votre décision change-t-elle si vous êtes celui qui est en ligne pour le projet?
La complexité du domaine ou du code change-t-elle votre façon de penser?
Réponses:
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:
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:
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?
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.
En plus de la réponse donnée par Yannis Rizos, je l'essayerais dans un petit côté ou testerais un projet si possible. Cela vous permettra de vous familiariser avec les caprices d'un produit avant qu'un enjeu important ne soit en jeu. Le projet ne devrait pas être trop petit, car cela laisserait une trop grande partie de la base de code inexplorée. Faites un tour pour voir si vous pouvez en faire ce que vous voulez sans trop de tracas. Si vous ne pouvez pas faire fonctionner les bases par vous-même à l'aide de la documentation et d'une ou deux questions à la communauté du projet, vous voudrez peut-être envisager de rechercher une base de code mieux prise en charge. Si le test initial fonctionne pour vous, vous pouvez commencer à l'utiliser pour de vrai. J'ai dû faire face à ce problème dans le passé, et après les deux premières fois, je me suis fait une règle pour tester de nouvelles choses avant de le mettre en production,
BP sage: l'introduction de nouvelles choses ne devrait jamais se faire sans une certaine forme de phase de préparation / d'apprentissage.