De FAIR4RS-principes voor software: een praktische uitleg voor onderzoekers
Stel je voor: je hebt maandenlang code geschreven voor een onderzoek. De resultaten zijn gepubliceerd, de wereld is blij.
▶Inhoudsopgave
Maar dan vraagt iemand om je analyse te herhalen. En… het werkt niet meer. De code draait niet, de afhankelijkheden zijn verouderd, en je eigen documentatie zegt zoiets als "zie main.py, daar gebeurt het allemaal". Klinkt herkenbaar?
Dan is het hoog tijd om het hebben over FAIR4RS. FAIR4RS staat voor Findable, Accessible, Interoperable, Reusable for Research Software.
Het is een uitbreiding van de bekende FAIR-principes — die je waarschijnlijk al kent van data — maar dan specifiek gemaakt voor onderzoekssoftware. En ja, dat is echt iets anders. Software heeft eigen uitdagingen: versies, afhankelijkheden, programmeertalen, installatiekuren. FAIR4RS geeft je een kader om al die dingen op een slimme manier aan te pakken.
In dit artikel lees je wat FAIR4RS precies inhoudt, waarom het voor jou als onderzoeker ertoe doet, en hoe je het in de praktijk toepast. Geen droge theorie, maar concrete tips die je vandaag al kunt gebruiken.
Waarom FAIR4RS? De achtergrond in een notendop
Onderzoekssoftware is de ruggengraat van modern onderzoek. Of het nu gaat om een Python-script dat genoomdata analyseert, een simulatiemodel voor klimaatonderzoek, of een webapplicatie voor enquêtes — zonder software kom je nergens.
Toch wordt software in de wetenschappelijke wereld vaak als bijzaak behandeld. Je publiceert een artikel, en de code?
Die staat ergens op een harde schijf of in een GitHub-repository zonder licentie of documentatie. Dat is een probleem. Want als software niet vindbaar, toegankelijk, interoperabel of herbruikbaar is, dan is het onderzoek dat erop gebaseerd is moeilijk te reproduceren. En reproduceerbaarheid is geen luxe — het is de basis van betrouwbaar onderzoek.
De FAIR4RS-principes zijn in 2022 formeel gepubliceld door de Research Data Alliance (RDA) als resultaat van een breed internationaal overleg.
Ze zijn geen verplichting, maar wel een steeds belangrijker wordende standaard. Funders, uitgevers en onderzoeksinstituten vragen steeds vaker om een softwaremanagementplan. FAIR4RS geeft je de taal en het kader om dat goed te doen.
De vier pijlers van FAIR4RS — en hoe je ze toepast
De principes volgen dezelfde letterlijke structuur als de originele FAIR-principes, maar zijn aangepast aan de specifieke aard van software. Laten we ze één voor één bekijken.
Findable: zodat anderen je software kunnen vinden
De eerste vraag is simpel: kan iemand jouw software vinden? Niet alleen jijzelf, maar een onderzoeker in een ander land, op een ander moment.
Daarvoor gelden een paar basisregels. Geef je software een duidelijke, beschrijvende naam. Niet "project_v3_final_FINAL", maar iets als "genexpressie-normalisatie-tool".
Voeg metadata toe: programmeertaal, versie, auteurs, een korte beschrijving, en een persistente identifier zoals een DOI. Ja, software kan een DOI krijgen! Platforms zoals Zenodo en Figshare koppelen automatisch een DOI aan je GitHub-repository. Publiceer je code in een publieke repository — GitHub, GitLab, of Bitbucket — en registreer het eventueel in een software-specifieke catalogus.
Accessible: zodat anderen je software daadwerkelijk kunnen gebruiken
Denk aan de Research Software Directory of het Software Heritage-archief. Hoe beter je software vindbaar is, hoe groter de kans dat anderen het gebruiken, citeren en bouwen op jouw werk.
Vindbaar is niet genoeg. De software moet ook toegankelijk zijn.
Dat betekent concreet: kies een open source licentie. Zonder licentie is jouw code juridisch gezien onbruikbaar voor anderen, ook als het publiekelijk staat. Populaire keuzes zijn MIT (simpel en vrij), Apache 2.0 (met patentbescherming), of GPL (als je wilt dat afgeleide werken ook open blijven).
Interoperable: zodat je software samenwerkt met andere tools
Schrijf installatie-instructies die ook iemand zonder jouw expertise kan volgen. Welke versie van Python heb je nodig? Welke packages?
Welke besturingssystemen worden ondersteund? En overweeg containerisatie met Docker. Een Dockerfile zorgt ervoor dat je software overal draait, ongeacht de omgeving.
Dat is een game-changer voor reproduceerbaarheid. Documentatie is hier het keyword.
Een README-bestand met een korte beschrijving, installatie-instructies, een voorbeeld van gebruik, en een verwijzing naar uitgebreidere documentatie.
Reusable: zodat je software blijft werken — ook over vijf jaar
Tools zoals Sphinx (voor Python) of Doxygen (voor C++) helpen om documentatie automatisch uit je code te genereren. Onderzoekssoftware bestaat zelden alleen. Je script leest data in, verwerkt het, en exporteert resultaten naar een ander formaat.
Interoperabiliteit zorgt dat dat soepel verloopt. Gebruik open standaarden voor dataformaten: CSV, JSON, XML, of HDF5 in plaats van eigen, ongedocumenteerde formaten. Maak gebruik van gestandaardiseerde API's als je software communiceert met andere systemen. En ontwerp je code modulair: kleine, onafhankelijke componenten die je makkelijk kunt vervangen of hergebruiken.
Een praktisch voorbeeld: als je tool data uit een database haalt, gebruik dan een standaard zoals SQL of een REST-api in plaats van een directe koppeling naar een specifieke database-instantie.
Zo blijft je software bruikbaar, ook als de onderliggende infrastructuur verandert. Herbruikbaarheid is misschien het belangrijkste principe, en tegelijk het lastigste.
Het gaat om het ontwerpen van software die niet alleen nu werkt, maar ook in de toekomst. Begin met versiebeheer. Gebruik Git, en doe het serieus: betekenisvolle commit messages, branches voor nieuwe features, tags voor releases.
Publiceer je software met duidelijke versienummers, bijvoorbeeld volgens semantic versioning (major.minor.patch). Schrijf tests.
Unit tests voor individuele functies, integratietests voor het geheel. Tests zijn geen extraatje — ze zijn de verzekering dat je software doet wat het moet doen. CI/CD-tools zoals GitHub Actions of GitLab CI kunnen tests automatisch draaien bij elke wijziging.
En documenteer niet alleen hoe de software werkt, maar ook waarom bepaalde keuzes zijn gemaakt. Die ontwerpbeslissingen zijn vaak waardevoller dan de code zelf.
De belangrijkste tools in een rijtje
Je hoeft niet alles zelf te bouwen. Er zijn fantastische tools die het toepassen van FAIR4RS een stuk makkelijker maken:
- Git met GitHub, GitLab of Bitbucket — voor versiebeheer en samenwerking. Dit is de absolute basis.
- Zenodo of Figshare — om je software te archiveren en een DOI te krijgen. Zo wordt je code citeerbaar.
- Docker — voor containerisatie. Verpak je software inclusief alle afhankelijkheden in een container, en het draait overal.
- GitHub Actions, GitLab CI, of Jenkins — voor geautomatiseerde tests en builds. Continuous Integration houdt je code gezond.
- Sphinx, Doxygen, of MkDocs — voor het genereren van documentatie. Automatisch, uit je code en commentaar.
- Package-managers zoals pip, conda, npm — voor het beheren van afhankelijkheden. Zorg dat anderen exact weten welke versies nodig zijn.
- Software Heritage — een archief dat open source code preserveert voor de lange termijn. Handig als je repository ooit verdwijnt.
Wat levert het je op?
"Klinkt als veel werk", hoor ik je denken. En ja, het kost initiële inspanning. Maar de opbrengsten zijn reëel:
Meer impact. Onderzoekers die hun software FAIR maken, worden vaker geciteerd. Software met een DOI telt als een publiceerbaar resultaat.
Sommige universiteiten en funders erkennen dat steeds meer. Betere samenwerking. Als je jouw onderzoekscode deelt op een herbruikbare manier, kunnen anderen erop bouwen.
Dat leidt tot nieuwe samenwerkingen, snellere innovatie, en minder dubbel werk. Reproduceerbaarheid. Dit is het belangrijkste. Als je kiest voor onderzoekssoftware volgens de FAIR-principes, kan iemand anders jouw analyse herhalen.
En dat is precies wat reviewers, lezers en funders steeds vaker verwachten.
Toekomstbestendigheid. Goede documentatie en versiebeheer betekenen dat ook jij over twee jaar nog begrijpt wat je code doet. Dat scheelt tijd, frustratie, en fouten.
Conclusie: begin klein, begin nu
Je hoeft niet alles tegelijk te doen. Begin met de low-hanging fruit: zet je code op GitHub, voeg een licentie toe, schrijf een fatsoenlijk README-bestand.
Dat al is een enorme stap vooruit. FAIR4RS is geen alles-of-niets-verhaal. Het is een spectrum. Elke verbetering telt.
En het mooie is: de meeste principes sluiten aan bij goede programmeerpraktijken die je toch al zou moeten toepassen. De wetenschappelijke wereld verandert.
Software wordt steeds belangrijker, en de verwachtingen rondom transparantie en reproduceerbaarheid worden steeds hoger.
FAIR4RS geeft je de tools om mee te bewegen — in plaats van achterop te raken. Dus: open die repository, kies een licentie, en maak je software vindbaar. Je toekomstige zelf — en je collega's — zullen je dankbaar zijn.