Come sapere se un progetto Open Source è abbastanza maturo per essere utilizzato in un prodotto?

Ci sono alcuni progetti open source che mi piacerebbe incorporare in un prodotto al lavoro. Non abbiamo la larghezza di banda né la competenza in materia per farlo da soli. Ho trovato questi cercando in Google. Non sono a conoscenza di nessuno dei "principali attori" che utilizzano i progetti, ma sono piuttosto incoraggiato da ciò che vedo.

Ora, sono un po 'preoccupato per la quantità di rischio a cui sono esposto usando il progetto open source di joe-blow. Se ci impiego il 95% del percorso, forse il restante 5% è facile da aggiungere o correggere. Forse non è banale.

In che modo le persone determinano se un progetto open source è abbastanza maturo da poter essere utilizzato in un prodotto?

Questo non è un progetto hobby, quindi stabilità, manutenibilità, ecc. Sono di primaria importanza.

I criteri che utilizzo, a condizione che il progetto soddisfi i miei requisiti:

1. Esiste una comunità attiva, con persone in grado di fornire assistenza?
2. La licenza è adeguata al mio sviluppo?
3. Il prodotto è ancora in fase di sviluppo attivo?
4. È un framework comunemente usato?
5. Posso trovare recensioni / post di blog / ecc del prodotto e come le persone si sono integrate con esso?

4 e 5 non aiutano davvero per progetti di nicchia che sembrano i tuoi.

L'unica cosa più importante è che soddisfa le tue esigenze? Se ritieni che lo faccia, la prossima cosa da fare è creare un cablaggio per testare il progetto e vedere se riesci a fare quello che vuoi che faccia. Questo ti darà un'idea della sua API (se è una libreria) e di come funziona.

Alla fine della giornata, se c'è qualcosa di open source che fa il 90% di quello che fai, biforcalo, aggiungi le funzionalità extra e restituiscilo alla community. L'ho già fatto su progetti commerciali.

1. Per il framework, generalmente vado solo con un framework grande e maturo con molti moduli pre-scritti e una grande comunità. In generale, la scelta di un framework rispetto all'altro non ridurrebbe di molto la quantità di lavoro che è necessario spendere per il proprio codice di molto, alcuni framework potrebbero incoraggiare un codice più bello, altri potrebbero rendere semplici alcune operazioni, ma in genere si sommano a poca differenza rispetto allo sforzo di sviluppo totale. Tuttavia, i framework popolari avrebbero più moduli prestabiliti che è possibile sfruttare ed è così che di solito è possibile risparmiare molto più tempo e fatica.
2. Per le piccole librerie non framework, generalmente saresti in grado di apportare modifiche se necessario senza troppi problemi, quindi di solito prenderei in considerazione la possibilità di avere la community come bonus aggiuntivo. La maggior parte delle librerie di piccole dimensioni sono gestite da una sola persona, ma sono comunque meglio che costruirsi. Per le grandi biblioteche, però, avere una comunità matura e attiva e la documentazione è essenziale perché è improbabile che tu sia in grado di apportare le modifiche con la stessa facilità.
3. La licenza è essenziale. Per le librerie one-man, è probabile che dovrai apportare modifiche alla libreria, quindi è essenziale che la loro licenza ti consenta di farlo in base ai termini che vorresti concordare.

Per le piccole librerie, dovresti sempre presumere che dovrai fork e che il progetto sia già abbandonato. Questo di solito non è un problema, specialmente se il progetto è ospitato su Github o BitBucket, perché rendono incredibilmente facile il fork di progetti di altre persone. Per le piccole biblioteche, puoi sempre assumere tu stesso la manutenzione del progetto, se il manutentore originale è sparito o se stanno pianificando di prendere la direzione del progetto in luoghi in cui non vuoi andare.

Sono meno preoccupato per l'attività di progetto, una biblioteca matura che ha raggiunto il suo senso di "perfezione" in genere dovrebbe fare solo correzioni di bug, quindi la loro attività ha rallentato. L'attività del progetto è importante solo se la biblioteca coinvolge un obiettivo che si sta evolvendo attivamente, ad esempio, un wrapper per il servizio esterno dovrebbe essere costantemente aggiornato man mano che il servizio esterno si evolve, quindi lo sviluppo attivo è essenziale, ma una biblioteca matematica non avrebbe bisogno di molto nuovo sviluppo una volta che ha tutte le funzionalità necessarie.

Per le biblioteche più grandi, le cose diventano più difficili. La presa in consegna è molto più complicata, fortunatamente le biblioteche più grandi generalmente non si muovono così velocemente, poiché sono generalmente più mature.

Come ha detto @Sam nella sua risposta, sono d'accordo sul fatto che la cosa più importante nella valutazione della libreria open source è quanto si adatta alle tue esigenze. Una volta risolto qualsiasi problema di licenza, l'uso di una libreria open source raramente è un errore perché puoi sempre biforcare se le cose vanno a sud.

Cerca nel bug tracker del progetto. Se vedi molti biglietti archiviati da molte persone diverse e le risposte arrivano anche da una varietà di persone, allora è un buon segno. Più ticket bug == comunità di utenti più grandi == maggiori probabilità di essere pronti per l'uso in produzione da parte tua.

La notizia non è buona, ma ciò non significa che sia errata: non lo sai.

Se ci fossero implementazioni analoghe nella produzione, sapresti che è fattibile, ma come hai detto nessun "attore principale" usa i progetti.

Se ti fossi sviluppato in casa, lo sapresti, ma come hai detto, non hai le risorse.

È ragionevole volerlo sapere, ma ... tu no.

Spero che questa risposta ti aiuti, perché dovresti avere piani di emergenza per staccare la spina da qualsiasi tecnologia da cui dipendi ma non controlli ... e sapere che non sai se è affidabile è un passo in quella direzione.

La domanda deve essere posta in modo diverso. Quello che stai veramente chiedendo è usare questo progetto open source nel modo migliore per sviluppare il prodotto?

Ciò implica necessariamente non solo il progetto open source in questione, ma anche le altre opzioni. Se la tua unica altra opzione è scrivere tutto da solo, allora stai meglio usando il progetto se riesci a capire che è abbastanza codice per poterlo modificare.

Che ovviamente l'altra domanda sorge se il tuo progetto è fattibile. Vale a dire che è necessario stimare lo sforzo, incluso qualsiasi rischio di dover correggere o completare la funzionalità che si spera sia fornita dal codice open-source. Se il progetto non è ampiamente utilizzato, dovrai rivedere il codice per questo.