3. Software aperto per la ricerca e open source
Di che cosa si tratta?
Il concetto di “software di ricerca aperto” o “software di ricerca open source” (codice sorgente aperto), si riferisce all’uso e sviluppo di software di ricerca (per analisi, simulazione, visualizzazione, etc.) il cui codice sorgente è interamente disponibile; in aggiunta a questo, però, secondo la definizione di “Open Source”, il software “open source” deve essere distribuito in formato sorgente e/o compilato (nel secondo caso, con possibilità di accesso al codice sorgente) e reso disponibile con una licenza che ne consenta l'uso libero, la modifica, e la ri-distribuzione.
Fondamenti
La ricerca moderna è incentrata sul software; per portare avanti una certa ricerca -o riprodurne i risultati- è necessario poter accedere al codice sorgente del software usato (Barnes, 2010; Morin et al., 2012; Ince et al., 2012; Prins et al. 2015; Lowndes et al., 2018). Come dicono Buckheit e Donoho, parafrasando Jon Claerbout, "Un articolo su un risultato computazionale è pubblicità, non scienza. La vera scienza sta nell’ambiente software completo, codice e dati, che ha prodotto quel risultato" (Buckheit & Donoho, 1995). Tra l’altro, l’accesso libero al codice sorgente del software scientifico aumenta l’impatto della ricerca prodotta (Vandewalle, 2012).
La condivisione del software utilizzato per la ricerca (sia per studi di natura prettamente computazionale che per studi che contengono un’analisi o interpretazione di dati basata su software) è una condizione necessaria, ma non sufficiente, per la riproducibilità. Questo perché, quando si descrive un software nel linguaggio naturale, -ad esempio- in un articolo, un certo grado di imprecisione è inevitabile (Ince et al., 2012). Inoltre, molti programmi software (forse la maggior parte) possono contenere errori nascosti (Soergel, 2015), quindi anche una "perfetta" descrizione scritta del software non sarebbe in grado di spiegare interamente i risultati.
Oltre all’aspetto della riproducibilità, la condivisione aperta del software permette di riconoscere il lavoro svolto dagli sviluppatori, sia attraverso la citazione diretta (Smith et al., 2016) che attraverso meta-articoli di software pubblicati, ad esempio, nel Journal of Open Research Software o nel Journal of Open Source Software (Smith et al., 2018). Esiste anche un elenco abbastanza nutrito delle riviste di settore che pubblicano articoli di software, a cura di Neil Chue Hong.
Finalità didattiche
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.
Imparare ad usare i programmi “open source” esistenti e a fare un’attribuzione appropriata (citazione).
Imparare ad utilizzare i più comuni strumenti e servizi di condivisione aperta dei codici di ricerca.
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 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 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).pdf). 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 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
Domande, intoppi e comuni equivoci
Domanda: "Non me la sento di condividere il mio software - è troppo disordinato / non ha una buona documentazione / non ho inserito abbastanza commenti!”
Risposta: In tutto il mondo gli sviluppatori di software di ricerca hanno questa stessa sensazione - le persone raramente pensano che il loro codice sia "pronto" per essere condiviso pubblicamente o che sia "finito". Tuttavia, come dice Barnes (2010), "se il tuo codice è abbastanza buono per fare il lavoro, allora è abbastanza buono per essere pubblicato - e pubblicarlo aiuterà la tua ricerca e il tuo settore”. In altre parole, se ci si sente abbastanza sicuri del proprio software per pubblicare uno studio o riportare i risultati, allora il codice è sufficientemente sviluppato per essere condiviso con i colleghi (viceversa, se non si è sicuri di voler condividere il codice, allora forse quest’ultimo necessita di ulteriori sviluppi o test prima di venire utilizzato in una pubblicazione). Inoltre, condividere un codice permette ad altri di migliorarlo e svilupparlo, producendo un impatto maggiore e una maggiore innovazione (e anche più citazioni per te!).
Domanda: "E se qualcuno si appropria del codice che ho condiviso e lo usa per scopi illeciti, o sostiene di averlo scritto?
Risposta: Scegliere una licenza appropriata per il proprio software serve a salvaguardarvi dall’uso improprio che altri possono farne; per esempio, la [licenza MIT] (https://choosealicense.com/licenses/mit/), abbastanza diffusa, prevede alcune limitazioni di responsabilità e precisa che non viene fornita alcuna garanzia. D’altra parte, se qualcuno prova a sostenere di essere l’autore di un vostro software diffuso al pubblico, voi potete citare la data e l'ora registrate nel vostro archivio o sulle versioni archiviate a riprova del fatto che la vostra opera precede la rivendicazione.
Domanda: Se condivido il mio codice in un archivio online, sarò sommerso da richieste di assistenza da parte degli utenti"
Risposta: Anche se dei potenziali utenti vi possono contattare con delle richieste di aiuto, sia via e-mail oppure (ad esempio) attraverso problemi segnalati nell’archivio online, non avete alcun obbligo di fornire assistenza se non volete o non potete farlo. Una licenza appropriata dà anche una protezione legale in questo senso (ad esempio, la clausola di non garanzia della licenza MIT License.
È un equivoco abbastanza comune pensare che il solo fatto di mettere un codice online lo renda “open source”. In realtà, a meno che il software non sia accompagnato da una licenza che conceda ad altri il permesso di usare, copiare, modificare e/o distribuire, lo sviluppatore (o gli sviluppatori) mantengono il copyright esclusivo. Per rendere un software “open source”, questo deve essere accompagnato da una licenza ”open source”.
Obiettivi di apprendimento
Essere in grado di condividere il software con la licenza più appropriata (cioè, sapere scegliere sia gli strumenti che la licenza).
Essere in grado di caricare, modificare e registrare un elemento di codice con un identificativo permanente.
Essere in grado di citare il software utilizzato per un articolo di ricerca
Letture integrative
Balasegaram et al. (2017). An open source pharma roadmap. doi.org/10.1371/journal.pmed.1002276
Dryden et al. (2017). Upon the Shoulders of Giants: Open-Source Hardware and Software in Analytical Chemistry. doi.org/10.1021/acs.analchem.7b00485
Ince et al. (2012). The case for open computer programs.doi.org/10.1038/nature10836
Iskoujina and Roberts (2015). Knowledge sharing in open source software communities: motivations and management. PDF
Jiménez et al. (2017).Four simple recommendations to encourage best practices in research software. doi.org/10.12688/f1000research.11407.1
Martinez-Torres and Diaz-Fernandez (2013).Current issues and research trends on open-source software communities PDF
Morin et al. (2012). Shining Light into Black Boxes. PDF
Oishi et al. (2018). Perspectives on Reproducibility and Sustainability of Open-Source Scientific Software from Seven Years of the Dedalus Project. arXiv:1801.08200v1 [astro-ph.IM]
Scacchi (2010). The Future of Research in Free/Open Source Software Development. PDF
Sandve et al. (2013). Ten simple rules for reproducible computational research doi.org/10.1371/journal.pcbi.1003285
Shamir et al. (2013).Practices in source code sharing in astrophysics. arXiv:1304.6780v1 [astro-ph.IM]
Steinmacher et al. (2014). A systematic literature review on the barriers faced by newcomers to open source software projects. PDF
Stodden (2010). The Scientific Method in Practice: Reproducibility in the Computational Sciences.PDF
Vandewalle (2012). Code Sharing Is Associated with Research Impact in Image Processing. PDF