Quando trovi una nuova libreria / progetto open source, quali criteri consideri prima di incorporarla nella tua base di partenza.
Ci sono domande legali a cui devi rispondere?
Cerchi una certa velocità di sviluppo?
La community ha una buona ragione?
La tua decisione cambia se sei quello sulla linea per il progetto?
La complessità del dominio o del codice cambia nel modo in cui ci pensi?
Ecco la mia lista di controllo relativa alla maturità del progetto:
Il progetto ha raggiunto il traguardo iniziale?
Eviterei di aggiungere qualsiasi codice se non ha raggiunto la pietra miliare iniziale descritta. Non suggerisco che dovresti sempre fidarti di uno sviluppatore che sostiene che il suo progetto è pronto per la produzione e cerca sempre di valutare tali affermazioni, ma dovresti fidarti di lei quando lei ti dice di no, cioè etichettare il software come versione 0.x, alpha, beta, release candidate e così via.
C'è una documentazione adeguata?
Un progetto perfetto offrirebbe:
Gli sviluppatori sono ancora impegnati nel progetto?
Non si può mai dire se gli sviluppatori rimarranno impegnati in futuro, a meno che, naturalmente, non si tratti di un progetto finanziato dalla fondazione / azienda. Ma puoi quasi sempre dire se sono impegnati in questo momento, controllando:
Anche un buon indicatore della maturità del progetto è una seconda generazione di sviluppatori, sviluppatori attivi che sono stati coinvolti dopo le tappe iniziali.
Gli sviluppatori sono raggiungibili?
Ora, per le tue domande più specifiche:
Velocity
In un progetto con un tracker di problemi pubblici controllerò sicuramente per vedere quanto tempo ci vuole per chiudere i problemi. Ovviamente la velocità non è sempre sinonimo di qualità, quindi probabilmente passerei attraverso problemi chiusi, ne selezionerò alcuni che ritengo importanti e valuterò il tempo di risposta e la qualità degli sviluppatori.
Compatibilità della licenza
Per quanto riguarda i problemi legali, non integrare mai un progetto open source nella tua base di codice se non sei sicuro al 100% che il tuo utilizzo sia compatibile con la sua licenza. In caso di dubbio, puoi sempre chiedere agli sviluppatori del progetto, o anche chiedere qui.
Hype della community
Dovresti sempre valutare l'hype. I consigli degli altri sviluppatori sono quasi sempre un indicatore abbastanza buono della maturità del progetto.
Ogni elemento nell'elenco di controllo è facoltativo, tranne la compatibilità con la licenza. Ho integrato molti progetti morti o non documentati nel mio codice, dipende sempre da quali sono le tue esigenze specifiche e da come vedi che il tuo codice si sta evolvendo.
Oltre alla risposta dichiarata da Yannis Rizos, proverei se possibile su un lato corto o su un progetto di prova. Questo ti permetterà di familiarizzare con le stranezze di un prodotto prima che sia in gioco qualcosa di importante. Il progetto non dovrebbe essere troppo piccolo, in quanto ciò lascerebbe inesplorato troppo il codebase. Prendilo per un giro per vedere se può fare quello che vuoi da esso senza troppi problemi. Se non riesci a far funzionare le nozioni di base da solo con l'aiuto della documentazione e una o due domande alla community del progetto, potresti prendere in considerazione la possibilità di considerare una base di codice più idoneamente supportata. Se il test iniziale funziona per te, puoi iniziare a usarlo per davvero. Ho avuto a che fare con questo problema in passato, e dopo le prime due volte ho fatto una regola per me stesso per testare nuove cose prima di portarlo in produzione, non importa quale fosse il rappresentante o l'apparente livello di documentazione .
BP saggio: introdurre nuove cose non dovrebbe mai essere fatto senza una qualche forma di preparazione / fase di apprendimento.
Leggi altre domande sui tag open-source