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

I criteri che utilizzo, a condizione che il progetto si adatti alle mie esigenze:

1. Esiste una comunità attiva, con persone in grado di fornire assistenza?
2. La licenza è appropriata per il 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 in che modo le persone si sono integrati con esso?

4 & 5 non sono di grande aiuto per progetti di nicchia che sembrano i tuoi.

L'unica cosa più importante è che soddisfi le tue esigenze? Se senti che lo fa, la prossima cosa da fare è fare un'imbracatura per testare il progetto e vedere se puoi fare ciò che vuoi che faccia. Questo ti darà un'idea della sua API (se si tratta di una libreria) e di come funziona.

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

1. Per framework, in genere vado solo con framework grandi e maturi con un sacco di 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 dedicare al proprio codice, alcuni framework potrebbero incoraggiare un codice più bello, altri potrebbero rendere certe operazioni facili, ma in genere riassumono molto piccola differenza per lo sforzo di sviluppo totale. Tuttavia, i framework più diffusi potrebbero avere più moduli già pronti da sfruttare e in questo modo è possibile risparmiare molto più tempo e impegno.
2. Per le librerie di piccole dimensioni e non, in generale potresti apportare modifiche tu stesso se necessario senza molti problemi, quindi di solito considererei la comunità come un ulteriore vantaggio. La maggior parte delle piccole biblioteche è gestita da una sola persona, ma è comunque meglio che costruirsi. Per le biblioteche di grandi dimensioni, tuttavia, disporre di una community attiva e matura e della documentazione è essenziale perché difficilmente si è in grado di apportare modifiche da soli con la stessa facilità.
3. La licenza è essenziale. Per le librerie one-man, è probabile che sia necessario apportare modifiche alla libreria, quindi è essenziale che la loro licenza ti consenta di farlo in base ai termini con cui sei d'accordo.

Per le librerie di piccole dimensioni, dovresti sempre presumere che dovrai biforcarti e che il progetto è già stato abbandonato. Questo di solito non è un problema, specialmente se il progetto è ospitato su Github o BitBucket, perché rendono il progetto di altre persone molto semplice. Per le librerie di piccole dimensioni, puoi sempre prendere in carico la manutenzione del progetto da solo, se il manutentore originale se ne è andato o se stanno pianificando di portare la direzione del progetto in luoghi in cui non vuoi andare.

Sono meno interessato all'attività del progetto, le biblioteche mature che hanno raggiunto il loro senso di "perfezione" in genere dovrebbero solo eseguire correzioni di bug, quindi la loro attività è rallentata. L'attività del progetto è importante solo se la biblioteca coinvolge un target in continua evoluzione, ad esempio, un wrapper per il servizio esterno dovrebbe essere costantemente aggiornato con l'evolversi del servizio esterno, quindi lo sviluppo attivo è essenziale, ma una libreria 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 più velocemente, in quanto 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 soddisfa le tue esigenze. Una volta risolto qualsiasi problema di licenza, l'uso di una libreria open source è raramente un errore perché puoi sempre andare in forchetta se le cose vanno a sud.

Cerca nel bug tracker del progetto. Se vedi un sacco di biglietti presentati da un sacco di persone diverse, e le risposte provenienti da una varietà di persone, allora questo è un buon segno. Altri ticket di bug == community di utenti più grandi == più probabilità di essere pronti per l'uso di produzione da parte tua.

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

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

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

È ragionevole volerlo sapere, ma ... non lo fai.

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

La domanda deve essere posta in modo diverso. Quello che stai veramente chiedendo è che stia usando 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 è meglio usare il progetto se riesci a capire il codice sufficiente per poterlo modificare.

Di certo, l'altra domanda sorge spontanea se il tuo progetto è in grado di funzionare. Cioè è necessario stimare lo sforzo incluso il rischio di dover correggere o completare la funzionalità che si spera sia fornita dal codice open source. Se il progetto non è ampiamente utilizzato, dovrai verificarne il codice.