Waarom onderzoekssoftware ook FAIR moet zijn en niet alleen jouw data
Je hebt vast wel eens het acroniem FAIR gehoord: Findable, Accessible, Interoperable, Reusable. Tegenwoordig staat het op bijna elke subsidieaanvraag, elk data-managementplan en elke universiteitssite over Open Science. En terecht!
▶Inhoudsopgave
Maar er zit een vreemd gat in die FAIR-gesprekken. Iedereen praat over data. Over data delen, data beschikbaar maken, data herbruiken.
Terwijl de software waarmee die data wordt gegenereerd, verwerkt en geanalyseerd, eigenlijk even belangrijk is.
Zo belangrijk zelfs, dat onderzoek zonder FAIR software bijna niet meer reproduceerbaar is. Laten we er eens goed naar kijken.
Software is geen bijzaak meer, het is het hart van onderzoek
Stel je voor: jij doet onderzoek naar klimaatverandering. Je hebt een dataset van 500 gigabyte met weermetingen.
Die dataset deel je netjes in een repository, voorzien van metadata, onder een open licentie. FAIR op z'n top. Maar hoe heb je die data verwerkt? Met welk script? Welke versie van welk softwarepakket?
Welke parameters heb je gebruikt? Als die informatie ontbreekt, kan niemand jouw resultaten ophalen.
De data zijn dan wel vindbaar en toegankelijk, maar de volledige onderzoeksketen is niet reproduceerbaar.
En dat is geen theoretisch probleem. Uit onderzoek van de USENIX-organisatie bleek dat in 2022 ongeveer 50% van de wetenschappelijke artikelen die gebruikmaken van computationele methodes, niet voldoende informatie verstrekt om de resultaten te reproduceren. Niet omdat de data ontbreken, maar omdat de code en software-omgeving onvoldoende gedocumenteerd of beschikbaar zijn.
Software is geen hulpmiddel meer. Het is een fundamenteel onderdeel van de onderzoeksmethode. Net zoals je in een artikel beschrijft welk microscoop je gebruikt en bij welke vergroting, zou je moeten documenteerd hebben welke software en welke versie je gebruikt hebt.
Wat betekenen de FAIR-principes eigenlijk voor software?
Findable: zodat anderen je code kunnen vinden
De meeste onderzoekers die software schrijven, zetten die code ergens op GitHub of GitLab. Prima start.
Maar is het ook echt vindbaar? Heeft de repository een duidelijke naam? Een goede beschrijving? Metadata over de programmeertaal, versie en doelgroep? Zonder die informatie is het alsof je een boek in een bibliotheek zet zonder titel of auteur op de rug.
Technisch aanwezig, maar praktisch onvindbaar. Plattelandswacht Nederland neem ik even mee als voorbeeld, maar dan voor de wetenschappelijke wereld: platforms zoals Zenodo en Figshare bieden de mogelijkheid om software te archiveren met een DOI (Digital Object Identifier).
Dat maakt code niet alleen vindbaar, maar ook citeerbaar. En dat is belangrijk, want onderzoekers die code schrijven verdienen erkenning voor hun werk.
Accessible: zodat anderen daadwerkelijk bij de code kunnen
Vindbaar is een eerste stap. Maar als je code achter een inlogscherm zit, of als de repository privé is, dan is het niet toegankelijk. Toegankelijkheid betekent dat anderen de code kunnen downloaden, installeren en uitvoeren.
Dat klinkt logisch, maar in de praktijk zit het vaak tegen. Denk aan afhankelijkheden.
Jij schrijft een Python-script dat draait op jouw laptop, met jouw specifieke versie van pandas, NumPy en een handjevol andere bibliotheken. Als iemand anders dat script downloadt en draait, werkt het misschien niet. Daarom wordt er steeds meer gepleit voor het gebruik van containertechnologieën zoals Docker en Singularity.
Daarmee pak je de hele software-omgeving in, inclusief alle afhankelijkheden, en kun je die als een geheel delen.
Interoperable: zodat code samenwerkt met andere tools
Interoperabiliteit is een van de lastigste pijlers, vooral voor software. Het gaat erom dat je code en data kunnen communiceren met andere systemen.
Dat betekent: gebruik open standaarden waar mogelijk. Denk aan dataformaten zoals CSV, JSON, HDF5 of NetCDF.
Vermijd eigen, gesloten formaten waar alleen jouw software mee overweg kan. API's spelen hier een grote rol. Goed ontworpen software biedt een interface waarmee andere tools er mee kunnen praten. Dat maakt het mogelijk om verschillende stukken software aan elkaar te koppelen tot een complete onderzoekspipeline.
In de bio-informatica bijvoorbeeld is dit al gemeengoed: tools zoals Galaxy en Nextflow bouwen hele workflows door bestaande software componenten aan elkaar te rijgen. Herbruikbaarheid is uiteindelijk waar het om draagt.
Reusable: zodat anderen daadwerkelijk wat met je code kunnen
Code is pas echt herbruikbaar als deze goed gedocumenteerd is, voorzien van een duidelijke licentie, en opgebouwd op een manier die aanpassing mogelijk maakt.
Een README-bestand met installatie-instructies, voorbeelden van gebruik, en een beschrijving van de input- en outputformaten maakt een wereld van verschil. En dan die licentie. Veel onderzoekers delen code zonder licentie.
Dat lijkt vrijgevig, maar het is eigenlijk contraproductief. Zonder licentie weet niemand wat ze wel en niet mogen doen met je code.
De meeste onderzoekers kiezen voor open source licenties zoals MIT, Apache 2.0 of GPL. Die geven duidelijke richtlijnen over gebruik, aanpassing en herdistributie.
Waarom doen we dit niet al?
Goede vraag. Er zijn redenen waarom FAIR software nog niet zo standaard is als FAIR data. Ten eerste: erkenning.
Onderzoekers worden beoordeeld op publicaties, niet op code. Er is nog te weinig stimulans om de moeite te nemen om code netjes te documenteren en te delen. Ten tweede: tijd.
Goede documentatie, het opzetten van containers, het schrijven van tests, dat kost tijd. En tijd is schaars in de academische wereld.
Veel onderzoekers zien het onderhouden van code als een last, niet als een kans.
En ten derde: cultuur. Er heerst nog steeds een mentaliteit van "mijn code is van mij". Het delen van code wordt soms gezien als het weggeven van een concurrentievoordeel, terwijl juist het delen van code leidt tot meer samenwerking, meer citaten en uiteindelijk meer impact.
Wat kun jij doen?
De goede nieuws: je hoeft niet alles in één keer te doen. Begin klein. Zet je code op een publieke repository.
Voeg een README toe. Kies een licentie. Documenteer je afhankelijkheden. Stap voor stap maak je je software een stukje FAIR-er.
En als je al verder staat, kijk dan eens naar tools als Docker voor het inpakken van je omgeving, of Zenodo voor het archiveren en DOI-registreren van je releases. De Nederlandse Open Science-community biedt ook steeds meer workshops en ondersteuning op dit gebied, via platforms zoals Research Software Hub en de Training-en-cursusaanbod van de VSNU. De boodschap is simpel: FAIR data zonder FAIR software is halverwege.
Als we écht willen dat onderzoek transparant, reproduceerbaar en herbruikbaar is, dan moeten we de software die het onderzoek draaiende houdt even serieus nemen als de data zelf. Want uiteindelijk is software niet alleen het gereedschap; het is het verhaal van hoe je tot je resultaten bent gekomen. Verdiep je daarom eens in de FAIR4RS-principes voor software om je code naar een hoger niveau te tillen.