Comment savoir si un projet Open Source est suffisamment mature pour être utilisé dans un produit?

Il y a des projets open source que j'aimerais intégrer dans un produit au travail. Nous n'avons ni la bande passante ni l'expertise en la matière pour le faire nous-mêmes. Je les ai trouvés en recherchant dans Google. Je ne connais aucun "acteur majeur" qui utilise les projets, mais je suis plutôt encouragé par ce que je vois.

Maintenant, je suis un peu préoccupé par le niveau de risque auquel je suis exposé en utilisant le projet open source de joe-blow. Si cela me prend 95% du chemin, peut-être que les 5% restants sont faciles à ajouter ou à corriger. Ce n'est peut-être pas anodin.

Comment les gens déterminent-ils si un projet open source est suffisamment mûr pour être utilisé dans un produit?

Ce n'est pas un projet de loisir, donc la stabilité, la maintenabilité, etc. sont primordiales.

Les critères que j'utilise, à condition que le projet réponde à mes exigences:

1. Existe-t-il une communauté active, avec des personnes capables de fournir une assistance?
2. La licence est-elle adaptée à mon développement?
3. Le produit est-il toujours en développement actif?
4. Est-ce un cadre couramment utilisé?
5. Puis-je trouver des critiques / articles de blog / etc. sur le produit et comment les gens s'y sont intégrés?

4 & 5 n'aident pas vraiment les projets de niche qui semblent être les vôtres.

La chose la plus importante est-elle conforme à vos exigences? Si vous pensez que c'est le cas, la prochaine chose à faire est de faire un harnais pour tester le projet et voir si vous pouvez faire ce que vous voulez qu'il fasse. Cela vous donnera une idée de son API (s'il s'agit d'une bibliothèque) et de son fonctionnement.

À la fin de la journée, s'il existe quelque chose d'open source qui fait 90% de ce que vous faites, créez-le, ajoutez la fonctionnalité supplémentaire et renvoyez-le à la communauté. Je l'ai déjà fait sur des projets commerciaux.

1. Pour le framework, je n'utilise généralement qu'un framework grand et mature avec beaucoup de modules pré-écrits et une grande communauté. Généralement, choisir un framework plutôt qu'un autre ne réduirait pas vraiment la quantité de travail que vous devez consacrer à votre propre code, certains frameworks peuvent encourager un code plus beau, d'autres peuvent faciliter certaines opérations, mais ils se résument généralement à très peu de différence par rapport à l'effort de développement total. Cependant, les frameworks populaires auraient plus de modules pré-écrits que vous pouvez exploiter et c'est ainsi que vous pouvez généralement économiser beaucoup plus de temps et d'efforts.
2. Pour les petites bibliothèques non-framework, vous pourrez généralement apporter des modifications vous-même si nécessaire sans trop de problèmes, donc je considérerais généralement la communauté comme un bonus supplémentaire. La plupart des petites bibliothèques ne sont gérées que par une seule personne, mais elles sont toujours meilleures que de se construire soi-même. Cependant, pour les grandes bibliothèques, il est essentiel d'avoir une communauté mature et active et de la documentation, car il est peu probable que vous puissiez apporter des modifications vous-même aussi facilement.
3. La licence est essentielle. Pour les bibliothèques unipersonnelles, il est probable que vous devrez apporter des modifications à la bibliothèque, il est donc essentiel que leur licence vous permette de le faire selon des conditions avec lesquelles vous seriez d'accord.

Pour les petites bibliothèques, vous devez toujours supposer que vous aurez besoin de fork et que le projet est déjà abandonné. Ce n'est généralement pas un problème, surtout si le projet est hébergé sur Github ou BitBucket, car ils facilitent stupidement le projet des autres. Pour les petites bibliothèques, vous pouvez toujours prendre en charge la maintenance du projet vous-même, si le responsable d'origine est parti ou s'il prévoit de prendre la direction du projet vers des endroits où vous ne voulez pas aller.

Je suis moins préoccupé par l'activité du projet, une bibliothèque mature qui a atteint son sentiment de «perfection» n'aurait généralement besoin que de corriger des bogues, donc son activité a ralenti. L'activité de projet n'est importante que si la bibliothèque implique une cible qui évolue activement, par exemple, un wrapper pour un service externe devrait être constamment mis à jour à mesure que le service externe évolue, donc un développement actif est essentiel, mais une bibliothèque mathématique n'aurait pas besoin de beaucoup nouveau développement une fois qu'il a toutes les fonctionnalités dont il avait besoin.

Pour les grandes bibliothèques, les choses deviennent plus difficiles. La prise en charge est beaucoup plus complexe, heureusement, les grandes bibliothèques ne se déplacent généralement pas aussi vite, car elles sont généralement plus matures.

Comme @Sam l'a dit dans sa réponse, je conviens que la chose la plus importante dans l'évaluation d'une bibliothèque open source est de savoir dans quelle mesure elle correspond à vos besoins. Une fois qu'un problème de licence est réglé, l'utilisation d'une bibliothèque open source est rarement une erreur car vous pouvez toujours bifurquer si les choses tournent au sud.

Regardez dans le suivi des bogues du projet. Si vous voyez beaucoup de tickets déposés par de nombreuses personnes différentes, et des réponses provenant d'une variété de personnes aussi, alors c'est un bon signe. Plus de tickets de bogue == plus grande communauté d'utilisateurs == plus susceptibles d'être prêts pour une utilisation en production par vous.

Les nouvelles ne sont pas bonnes, mais cela ne signifie pas qu'elles sont incorrectes: vous ne savez pas.

S'il y avait des implémentations analogues en production, vous sauriez que c'est faisable, mais comme vous l'avez dit, aucun "acteur majeur" n'utilise les projets.

Si vous aviez développé en interne, vous le sauriez, mais comme vous l'avez dit, vous n'avez pas les ressources.

Il est raisonnable de vouloir savoir, mais ... ce n'est pas le cas.

J'espère que cette réponse vous aidera, car vous devriez avoir des plans d'urgence pour débrancher toute technologie dont vous dépendez mais que vous ne contrôlez pas ... et savoir que vous ne savez pas si elle est fiable est un pas dans cette direction.

La question doit être posée différemment. Ce que vous demandez vraiment, c'est d' utiliser ce projet open source comme la meilleure façon de développer le produit?

Cela implique nécessairement non seulement le projet open source en question, mais aussi vos autres options. Si votre seule autre option consiste à tout écrire vous-même, il vaut mieux utiliser le projet si vous pouvez comprendre que son code est suffisant pour pouvoir le modifier.

Bien sûr, l'autre question se pose de savoir si votre projet est viable du tout. C'est-à-dire que vous devez estimer l'effort, y compris tout risque de devoir réparer ou compléter la fonctionnalité que vous espérez être fournie par le code open-source. Si le projet n'est pas largement utilisé, vous devrez revoir le code pour cela.