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:
- Bedienungsanleitung voll mit Beispielen
- Ein Integrations- / Erweiterungshandbuch, wenn es sich um eine Bibliothek handelt
- API-Dokumentation
- Vollständig dokumentierter Quellcode
- Ein öffentlicher Issue Tracker
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:
- Letzte Commit-Aktivität
- Neueste Funktionen (nicht nur Fehlerkorrekturen)
- Neueste Dokumentationsaktivitäten (Dokumentenaktualisierungen, Blogposts usw.)
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?
- Reagieren sie auf Bugs?
- Bieten sie neben einem generischen Issue-Tracker auch andere Kontaktmöglichkeiten? Dies ist ein kleiner Punkt auf der Checkliste, aber für einzelne Entwicklerprojekte könnten alternative Kontaktmöglichkeiten in Fällen wie dem "Fall des fehlenden Entwicklers" hilfreich sein .
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.
