È da un po’ che non recensisco un libro, probabilmente sono un po’ fuori allenamento. Ma non importa, oggi voglio parlare di Uncurled (everything I know and learned about running and maintaining Open Source projects for three decades) di Daniel Stenberg. Si tratta di un ebook che contiene aneddoti, consigli e considerazioni su come gestire e mantenere un progetto open source.
L’autore
La prima cosa di cui parlare è l’autore. Daniel è un programmatore svedese ed è il creatore di curl, forse uno dei progetti open source più importanti del mondo. Nel suo ebook racconta bene la storia che ha portato a questo progetto, e anche le sue evoluzioni. Poiché il libro è gratis, consiglio di leggere direttamente dalla sua penna il capitolo Experience: curl.
Il libro
Il libro si divide in diverse sezioni:
- Introduction, dove l’autore spiega il significato di alcuni termini fondamentali e di uso comune.
- Experience, dove l’autore racconta la sua esperienza personale nello sviluppo e nella gestione di progetti open source (come Dancer, curl, libssh2 e Firefox).
- Start, dove vengono riportate le informazioni base per cominciare un progetto open source.
- People, forse quello per me più complicato. Spiega come gestire e mantenere un gruppo di persone, come comportarsi in alcune situazioni comuni, come affrontare le critiche (e gli insulti).
- Project, strettamente legato alla sezione precedente, continua a indagare e a spiegare la stretta correlazione tra persone, open source e rapporti di buon vicinato.
- Money, ovvero come autofinanziare un progetto open source. O, per dirla in altre parole, non lasciare il tuo lavoro sperando che l’open source ti paghi la pagnotta.
- Source, dove Daniel spiega come gestire i contributi di altri sviluppatori, la documentazione scritta da altri e altri aspetti più squisitamente legati al codice.
- Security, dove l’autore spiega i problemi più comuni per creare del codice sicuro, e come gestire i cacciatori di bug (Bug Bounty).
- Maintainer, un altra sezione molto interessante in cui si affrontano i compiti necessari per mantenere un progetto open source. E, di conseguenza, le responsabilità di un maintainer. Spoiler: sono molte di più le cose da fare rispetto a quello che uno si aspetta.
- Evolution, ovvero com’è cambiato il mondo dell’Open Source negli ultimi tre decenni.
- Life, come gestire la propria vita e non trascurare la propria famiglia. E mia moglie ringrazia sentitamente per questo capitolo.
- Emails, una collezione di email che Daniel ha ricevuto nel corso degli anni. Perché quando la tua mail appare nei credit di un’auto, vuoi non essere responsabile per l’auto tutta?
Come si può ben vedere dalla quantità di argomenti trattati, sono una settantina di pagine piene dense di argomenti, suggerimenti, idee e spunti di riflessione.
Quello che mi è rimasto
Detto questo, cosa ho capito io?
Beh, ci sono alcune cose che mi hanno colpito e di cui voglio tenere nota.
A volte un progetto tira l’altro, come per le ciliegie. È un’aspetto comune in tutti i processi creativi. La risoluzione di problemi matematici, informatici, logici non è diversa: partendo da un problema particolare si incontrano molti altri problemi legati a quello iniziale. E spesso non c’è altro modo che risolverli per poter tornare a quello iniziale. Penso sia uno degli aspetti più belli della programmazione. E anche più frustranti.
Perfect is the enemy of the good, e a volte il buono è più che sufficiente. Anzi, a volte anche il mediocre va bene per risolvere un problema. E anche se un problema è un problema, una soluzione è una soluzione. Ed è spesso meglio cominciare da una soluzione e poi cambiare se necessario.
Open Source spesso vuol dire lavoro in solitaria. Non so perché, ma è una cosa che mi ha colpito. Sì, lo so che i miei progetti sono sostanzialmente tutti frutto del mio lavoro. E per quanto mi ostini a lasciarli Open Source, beh, è più un lavoro da cowboy solitario più che di squadra. Scoprire che è la norma mi ha in qualche modo rassicurato. E anche in qualche modo spaventato.
Fanno più rumore le lamentele che i complimenti. E questo, ahimè vale in quasi tutti i campi. Quando si cura un progetto Open Source, o qualsiasi altra cosa gratis, sono più le voci di chi si lamenta piuttosto di chi ringrazia. In fin dei conti è anche comprensibile: chi usa una mia libreria vuole una soluzione. Se tutto va liscio non c’è nessuna ragione per interrogarsi sul perché. Se invece qualcosa non va, beh, ecco che la ricerca della soluzione prevede l’interpellare chi ha proposto quella soluzione.
Aspettati insulti. Anche questo vale per tutto, ci sarà qualcuno che insulterà. Lo so che non ha senso, ma così è. L’unica cosa da fare è restare calmi, e non rispondere a tono. Magari aspettare un giorno prima di rispondere, e farlo con tranquillità. E se la cosa non funziona, allungare un po’ alla volta i tempi di risposta fino a far cadere la conversazione. Non c’è nessun progetto Open Source per vale la pena di farsi venire il sangue amaro.
La gente va è viene. Vale per chi insulta, vale anche per chi da una mano. Ognuno di noi ha una propria vita, i propri problemi, le proprie priorità. Ogni contributo è bene accetto. E anche chi non può, o non vuole, contribuire lo è. Ci saranno sempre strade che si incrociano e strade che si allontanano. Va bene così, e non c’è nessun problema.
La vita ha la precedenza. La propria vita, e quella dei collaboratori. Ognuno ha diritto di vivere la propria, e di dedicare all’Open Source il tempo che può. Nessuno ha il diritto di giudicare, o di discutere, il modo in cui qualcun altro impiega il proprio tempo nel progetto. In fin dei conti si tratta pur sempre di tempo donato.
Ci sono pregiudizi. Anche nella comunità Open Source, ci sono pregiudizi. C’è chi considera le donne meno capaci, chi ha idee razziste, chi è intollerante verso altre religioni, e così via. Fa schifo, ma è così. Per fortuna ci sono anche molti progetti Open Source che sono attivi contro questi pregiudizi. E, personalmente, trovo siano quelli dove si respira un clima migliore.
A volte le cose sono fatte così semplicemente perché funzionano. Ovvero, non sono l’unico a dire “Ok, questa soluzione funziona. Per il momento va bene così, poi in futuro ci penserò”. Inutile dire che quel futuro non arriverà mai.
Il successo di un progetto open source è dato dal tempo. Non è tanto importante quante persone usino un dato programma o una libreria, o quale sia l’obiettivo che ci si prefigge. Il successo in questo genere di progetti è dato dalla perseveranza, dal continuare ad aggiornare il codice, dal mantenerlo vivo attraverso le varie vicissitudini.
Non aspettarsi soldi. Se una libreria è ben fatta, e ben curata, e funziona, allora verrà utilizzata. E anche industrie, anche grandi, la useranno. Ma non faranno donazioni, non pagheranno nulla e spesso non avviseranno nemmeno che la libreria è stata usata. Così funziona l’Opens Source, e non c’è granché da fare.
Tutte le modifiche possono aspettare. Se una modifica non è pronta, o non è testata, o non è valida, allora è possibile aspettare prima di renderla pubblica. Come dicevo prima, la vita ha la precedenza, così la famiglia, e la salute dei nostri collaboratori, e quindi anche di noi. Non succede nulla di brutto se un aggiornamento esce un po’ più tardi del solito.
Le cose cambiano. Così anche il mondo Open Source. Con gli strumenti di oggi è molto più facile ed economico gestire codice Open Source. Basti pensare a GitHub, per dirne una. Forse stiamo vivendo gli anni d’oro dell’Open Source. O forse il futuro sarà ancora migliore, sotto questo punto di vista.
Quindi, per concludere, consiglio davvero la lettura di Uncurled.
