Scegliere un componente open source è facile; scoprire dopo due anni che è stato abbandonato, quando l'intero sistema dipende da lui, è molto costoso. Il numero di stelle su una piattaforma di hosting o la popolarità sui forum dicono poco sulla salute reale di un progetto. Servono controlli diversi, quasi tutti verificabili in mezz'ora guardando il repository e la documentazione.
Attività recente
Il primo segnale è se qualcuno sta ancora lavorando al progetto. Controlla:
- data dell'ultimo commit sul ramo principale e frequenza nell'ultimo anno;
- data dell'ultimo rilascio e regolarità dei rilasci precedenti;
- tempo di risposta alle issue: non serve che vengano risolte subito, ma che qualcuno le legga;
- pull request esterne: vengono revisionate e unite, o restano aperte indefinitamente?
Attenzione a un caso particolare: un progetto piccolo e stabile può avere pochi commit semplicemente perché è completo. Una libreria che fa una cosa sola e la fa bene non ha bisogno di cambiamenti continui. La differenza la fa la risposta ai problemi: se le issue di sicurezza ricevono attenzione, il progetto è vivo anche se tranquillo.
Persone e bus factor
Il bus factor è il numero di persone che dovrebbero sparire perché il progetto si fermi. Si stima guardando la distribuzione dei contributi:
- se una sola persona ha scritto la grande maggioranza dei commit recenti, il bus factor è uno;
- se più persone hanno permessi di rilascio e sono attive, il rischio è minore;
- se i manutentori appartengono tutti alla stessa azienda, il rischio coincide con le decisioni di quell'azienda.
Un bus factor basso non è un motivo automatico per scartare un progetto, ma va pesato in base a quanto il componente è critico e a quanto sarebbe difficile sostituirlo.
Rilasci e versioni
Un progetto maturo gestisce i rilasci in modo prevedibile:
- versioni numerate con uno schema dichiarato;
- note di rilascio che spiegano cosa cambia e cosa si rompe;
- indicazione di quali versioni ricevono ancora correzioni;
- pacchetti pubblicati nei registri ufficiali dell'ecosistema, firmati quando possibile.
Se l'unico modo di installare il software è compilare il ramo principale, il progetto non è pronto per un uso in produzione.
Gestione della sicurezza
È l'area dove le differenze sono più marcate. Cerca:
- un file
SECURITY.mdo una pagina che spieghi come segnalare vulnerabilità in privato; - avvisi di sicurezza pubblicati per i problemi passati, con versioni interessate e corrette;
- tempi ragionevoli tra la segnalazione pubblica di una vulnerabilità e la correzione;
- aggiornamento regolare delle dipendenze.
L'assenza di avvisi passati non significa necessariamente che il software sia sicuro: può significare che nessuno li ha mai cercati o pubblicati.
Documentazione e comunità
Una buona documentazione riduce il costo di adozione e indica cura. Valuta se esistono guida di installazione, riferimento delle opzioni, esempi aggiornati e istruzioni di migrazione tra versioni. Guarda anche dove si chiedono aiuto gli utenti e se le domande ricevono risposte, anche da altri utenti e non solo dai manutentori.
Licenza e governance
Verifica che la licenza sia una licenza open source riconosciuta e che sia la stessa per tutto il repository. Controlla anche se ai contributori è richiesto un CLA che consenta a un'azienda di cambiare licenza, e se il progetto ha una governance scritta o è sotto una fondazione.
Una checklist da compilare
| Criterio | Segnale positivo | Segnale di allarme |
|---|---|---|
| Attività | Rilasci regolari, issue lette | Nessuna risposta da mesi |
| Persone | Più manutentori attivi | Una sola persona |
| Rilasci | Versioni, changelog, supporto dichiarato | Solo il ramo principale |
| Sicurezza | Canale privato, avvisi pubblici | Nessun processo |
| Documentazione | Completa e aggiornata | Ferma a versioni vecchie |
| Licenza | Chiara, uniforme | Mista o assente |
Il piano di uscita
L'ultima domanda è la più trascurata: cosa farei se il progetto si fermasse domani? Le risposte possibili sono passare a un fork, mantenere internamente una copia, migrare a un'alternativa. Se nessuna è praticabile, il componente va isolato dietro un'interfaccia interna, così da poterlo sostituire senza riscrivere tutto.
Nel mio lavoro preferisco spesso una libreria meno brillante ma con tre manutentori attivi a una più elegante che dipende da una sola persona.
In sintesi
- Stelle e popolarità non misurano la salute di un progetto.
- Controlla attività, bus factor, rilasci, sicurezza, documentazione e licenza.
- Un progetto piccolo e stabile può essere sano anche con pochi commit.
- Per i componenti critici prepara sempre un piano di uscita.
