27
1. Apprendere le caratteristiche del software “open source”; approfondire gli aspetti etici, legali, economici e quelli relativi all’impatto sulla ricerca, sia a favore sia contro il software “open source”, nonchè comprendere i requisiti di qualità del codice aperto.
2. Imparare ad usare i programmi “open source” esistenti e a fare un’attribuzione appropriata (citazione).
3. Imparare ad utilizzare i più comuni strumenti e servizi di condivisione aperta dei codici di ricerca. 4. Essere in grado di scegliere la licenza più appropriata per il proprio software e comprendere la
differenza tra licenze permissive e non permissive.
Componenti chiave
Conoscenza
Ci sono diverse piattaforme attraverso le quali si può collaborare a un software, a una ricerca, etc., e condividere i risultati. Per valutare il livello di apertura di un software di ricerca esistente si può usare questo test:
Il software è disponibile per essere scaricato ed installato?
Il software può essere facilmente installato su diverse piattaforme? L’uso del software è soggetto a restrizioni?
Il codice sorgente è disponibile e consultabile?
Esiste una cronologia delle versioni a disposizione del pubblico?
I requisiti (hardware e software) di sistema sono descritti adeguatamente? Questi requisiti (o “dipendenze”) si possono ottenere e utilizzare con uno sforzo ragionevolmente limitato?
Questi requisiti corrispondono, con qualche modifica, alla definizione di Open Source.
GitHub è uno strumento molto usato per il controllo di versione, cioè per la gestione e il monitoraggio globale delle modifiche di un certo elemento di software. Servizi come GitHub, GitLab, Bitbucket e altri forniscono un'interfaccia allo strumento oltre a servizi di archiviazione remota che possono essere utilizzati per mantenere, condividere e collaborare su software di ricerca. GitHub è abbastanza diffuso e, sebbene
28
presenti una certa curva di apprendimento iniziale, si è rivelato uno strumento prezioso per organizzare un flusso di lavoro di ricerca aperto e riproducibile.
Avere il software di ricerca su GitHub è solo il primo passo; è altrettanto importante associare ad esso un identificatore pubblicato e persistente, come un DOI. Ci sono diversi modi per attribuire un DOI ad un archivio GitHub; il più semplice è utilizzare Zenodo (un archivio generico aperto e gratuito creato da OpenAIRE e CERN) anche se esistono altri archivi per depositare un software e ottenere un DOI, come Figshare. Zenodo si integra con GitHub per archiviare il software e creare un DOI ogni volta che viene fatta una release ufficiale su GitHub
Il software condiviso pubblicamente non è realmente “open source” se non è accompagnato da un’appropriata licenza; di default, infatti, il software (come qualsiasi altra opera creativa) è di proprietà esclusiva di chi l’ha creato, il che implica che nessuno può usare, copiare, distribuire o modificare l’opera di un altro (choosealicense.com). (Se si vuole condividere il proprio codice senza alcuna restrizione è anche possibile renderlo di dominio pubblico.) Perchè sia “open source” si deve scegliere una licenza adeguata al proprio software, in base a ciò che si decide di permettere (o di proibire) agli altri di fare con quel codice; un’utile risorsa per imparare a distinguere tra le diverse licenze è il sito choosealicense.org anche se non riporta tutte le licenze “open source” disponibili o più diffuse. Una volta selezionata una licenza, si deve inserirne il testo nell’archivio del software – aggiungendo il nome dell'autore (o degli autori) e l'anno - come file di puro testo LICENSE.
Anche se condividere il software, in qualunque forma, è comunque meglio che non condividerlo affatto, esso avrà un impatto maggiore e sarà più facilmente utilizzabile da altri – e in futuro anche da voi stessi! - se corredato di una documentazione. Questa può essere costituita da commenti inseriti nel codice che spiegano il perchè si è deciso di fare una certa cosa (non tanto quello che si è fatto, che dovrebbe essere già di per sè evidente), un file README informativo che descrive ciò che il software è in grado di fare e che fornisce alcune informazioni utili (ad esempio, come installarlo, come citarlo, come eseguirlo, le
29
dipendenze importanti), tutorial/esempi, e/o documentazione per le API (quest’ultima può essere generata automaticamente da commenti opportunamente formattati nel codice).
La mancanza o l’inaccessibilità di alcune dipendenze, o la carenza di documentazione sull'ambiente di calcolo, spesso costituiscono un ostacolo al ri-utilizzo e alla riproducibilità. Un modo per rimuovere questi ostacoli è quello di distribuire, insieme al codice, anche l’ambiente di calcolo, utilizzando la tecnologia dei contenitori (oggetto contenitore). I contenitori confezionano il codice insieme alle sue dipendenze e al suo ambiente computazionale, cosicchè è più facile per un altro ripetere la vostra analisi. Esempi di implementazione dei contenitori nella ricerca includono Rocker, Binder e Code Ocean.
Quando si utilizza un software - sia che ne siate l’autore, o che sia stato prodotto da altri- citarlo appropriatamente è importante per la riproducibilità dei risultati ottenuti (per un approfondimento al riguardo si rimanda al Capitolo 4; brevemente, la versione usata può cambiare i risultati o l'interpretazione) e anche per dare il giusto riconoscimento ai programmatori (Niemeyer 2016, Smith 2016). Se e quando citare il software è una decisione che spetta al ricercatore, ma raccomandiamo di farlo in tutti i casi in cui il software è parte integrante del lavoro -risultati, interpretazioni o conclusioni. Il modo migliore per rendere il codice facilmente citabile è utilizzare l'integrazione GitHub-Zenodo -descritta sopra- e fornire il DOI in una posizione bene in vista come, ad esempio, nel file README, possibilmente insieme al formato raccomandato per la citazione. Quando si cita un software, si dovrebbe includere almeno il nome dell'autore (o degli autori), il titolo del software, il numero di versione e un identificatore/localizzatore unico (Smith 2016). Se si usa il software di un altro ma che è contrassegnato da un DOI, il software può essere facilmente identificato e localizzato; se il software non è presente in un archivio, allora si dovrebbe indicare l’URL a cui il software può essere trovato ed il numero di versione o (per esempio) il codice hash dell’ultima modifica (commit).
Vi sono ulteriori concetti, un po’ più complicati, tra cui: test automatici e integrazione continua del software; confezionamento del software in formato binario; governance e gestione di progetti “open source” collettivi (ad esempio, codici di condotta, guide contributive). Alcuni di questi argomenti sono descritti da Scopatz and Huff (2015). Wilson et al. (2017) forniscono anche una guida operativa alle buone pratiche per il calcolo scientifico che contiene consigli specifici sullo sviluppo di software di ricerca.
Hardware “open source”
I principi “open source” descritti sopra si applicano anche all'hardware. I ricercatori spesso usano per la loro ricerca strumentazioni o hardware proprietario che non sono liberamente accessibili, riutilizzabili o
30
adattabili. L'hardware scientifico comprende tutto, dagli strumenti per il sequenziamento, ai microscopi, alle apparecchiature di analisi specializzate, agli acceleratori di particelle. La comunità dell'Open Science Hardware (OScH), ad esempio, sta spingendo il movimento open source a occuparsi anche di strumenti scientifici, hardware e infrastrutture di ricerca attraverso la loro Global Open Science Hardware Roadmap.
Competenze
Creare un archivio GitHub e attivare l’integrazione con Zenodo. Coniare la prima versione del software.
Selezionare una licenza di software utilizzando ad esempio choosealicense o Open Source Initiative.
Creare la documentazione per un pacchetto software, inclusi README, commenti ed esempi. Citare correttamente il software utilizzato per un articolo