Wenn Sie eine neue Open Source-Bibliothek / ein neues Open Source-Projekt finden, welche Kriterien prüfen Sie, bevor Sie es in Ihre Quelldatenbank aufnehmen.
Gibt es rechtliche Fragen, die Sie beantworten müssen?
Suchen Sie nach einer bestimmten Entwicklungsgeschwindigkeit?
Ist die Community ein guter Grund?
Ändert sich Ihre Entscheidung, wenn Sie für das Projekt an der Reihe sind?
Ändert die Komplexität der Domain oder des Codes Ihre Meinung dazu?
Antworten:
Hier ist meine Checkliste zur Projektreife:
Hat das Projekt seinen ersten Meilenstein erreicht?
Ich würde es vermeiden, Code hinzuzufügen, wenn er nicht seinen selbst beschriebenen ersten Meilenstein erreicht. Ich schlage nicht vor, dass Sie einem Entwickler immer vertrauen, wenn er behauptet, dass sein Projekt produktionsbereit ist, und immer versuchen, solche Behauptungen zu bewerten, aber Sie sollten ihr auf jeden Fall vertrauen, wenn sie Ihnen sagt, dass dies nicht der Fall ist, dh wenn Sie die Software als Version 0.x bezeichnen. Alpha, Beta, Release Candidate und so weiter.
Gibt es ausreichende Unterlagen?
Ein perfektes Projekt würde folgendes bieten:
Sind die Entwickler noch immer dem Projekt verpflichtet?
Man kann nie sagen, ob sich die Entwickler auch in Zukunft engagieren werden, es sei denn, es handelt sich um ein von einer Stiftung oder einem Unternehmen unterstütztes Projekt. Sie können jedoch fast immer feststellen, ob sie gerade festgeschrieben sind, indem Sie Folgendes überprüfen:
Ein guter Indikator für die Projektreife ist auch eine zweite Generation von Entwicklern, aktive Entwickler, die sich nach den ersten Meilensteinen engagiert haben.
Sind die Entwickler erreichbar?
Nun zu Ihren spezifischeren Fragen:
Geschwindigkeit
In einem Projekt mit einem öffentlichen Issue-Tracker würde ich auf jeden Fall überprüfen, wie lange es dauert, bis die Probleme geschlossen sind. Natürlich bedeutet Geschwindigkeit nicht immer Qualität. Daher würde ich wahrscheinlich geschlossene Fragen durchgehen, ein paar auswählen, die ich für wichtig halte, und die Reaktionszeit und Qualität der Entwickler bewerten.
Lizenzkompatibilität
Integrieren Sie aus rechtlichen Gründen niemals ein Open-Source-Projekt in Ihre Codebasis, wenn Sie nicht zu 100% sicher sind, dass Ihre Verwendung mit der Lizenz kompatibel ist. Im Zweifelsfall können Sie jederzeit die Entwickler des Projekts oder sogar hier fragen.
Community-Hype
Sie sollten immer Hype bewerten. Empfehlungen von anderen Entwicklern sind fast immer ein ausreichender Indikator für die Projektreife.
Jedes Element auf der Checkliste ist optional, mit Ausnahme der Lizenzkompatibilität. Ich habe viele tote und / oder undokumentierte Projekte in meinen Code integriert. Es hängt immer davon ab, welche spezifischen Anforderungen Sie haben und wie sich Ihr eigener Code entwickelt.
Zusätzlich zu der Antwort von Yannis Rizos würde ich es in einer kurzen Seite ausprobieren oder wenn möglich in einem Testprojekt. Auf diese Weise können Sie sich mit den Besonderheiten eines Produkts vertraut machen, bevor es um wichtige Dinge geht. Das Projekt sollte nicht zu klein sein, da dies zu viel von der Codebasis unerforscht lassen würde. Probieren Sie es aus, um zu sehen, ob Sie ohne großen Aufwand das tun können, was Sie wollen. Wenn Sie mit Hilfe der Dokumentation und einer oder zwei Fragen an die Projektgemeinschaft die Grundlagen nicht selbst zum Laufen bringen können, sollten Sie sich eine besser unterstützte Codebasis ansehen. Wenn der erste Test für Sie erfolgreich ist, können Sie ihn in der Praxis einsetzen. Ich habe mich in der Vergangenheit mit diesem Problem befasst und es mir nach den ersten beiden Malen zur Regel gemacht, neue Dinge zu testen, bevor ich sie in Produktion nehme.
BP weise: Die Einführung neuer Dinge sollte niemals ohne irgendeine Form von Vorbereitungs- / Lernphase erfolgen.