Software Competence, Self-Sufficiency, and Sovereignty through Open Science

Dr. Adina Wagner       @adswa@mas.to

Institute of Neuroscience and Medicine,
Brain & Behavior (INM-7),
Research Centre Jülich

DOI: doi.org/10.5281/zenodo.17249652
Science:
Its building blocks:
CC-BY Scriberia and The Turing Way

My path into research software

         
https://www.adina-wagner.com/posts/portcode

Research software & open, reproducible science go hand in hand

CC-BY Scriberia and The Turing Way Reproducibility Management in Neuroscience: Specific issues and solutions
(https://doi.org/10.5281/zenodo.4285927)

Just put the code on GitHub ...

Hardwicke et al., 2018:
  • Open data of 38% of N=174 studies were not "in principle reusable"
  • 24 out of 35 studies with reusable data: irreproducible main results without assistance of the original authors,
  • 13 out of 24: not exactly reproducible even with assistance
Obels et al., 2020:
  • N=62 Registered Reports
  • 36 articles shared both data and code to reproduce results
  • Out of those, main findings of 15 articles could not be reproduced


Data Management
  • multiple versions of code/data
  • suboptimal data curation
  • unclear execution order/entry points
  • non-portable code
    		•  Technical problems
  • wrong software
    environment
  • proprietary software
  • link rot/accessibility issues
    		•  Human errors
  • reporting (copy-paste) errors
  • ambiguous analysis specification
    		•

    How to write a reproducible research article
    (https://zenodo.org/records/5508797)
    "Works on my machine" derickbailey.com

    "good enough" software can be hard work



      10 essential guidelines for building
      high-quality research software:
    • Modular design
    • Clean and Readable Code
    • Use Version Control
    • Test regularly
    • Peer Code Review
    • Documentation
    • ...
    Eisty et al., 10 essential guidelines for building high-quality research software
    Barker et al., Introducing the FAIR Principles for research software
    Ivimey-Cook et al.,TADA! Simple guidelines to improve code sharing
    "This used to work on my machine..."
    Based on derickbailey.com

    When you write research software you increasingly get...

    • ... funding:
      • Open source as a requirement for grants
      • dedicated funding for research software e.g., DFG, Klaus-Tschira-Stiftung, Volkswagenstifung, Helmholtz, ...
    • ... recognition:
      • software is academic output: The San Francisco Declaration on Research Assessment (DORA), the Agreement on Reforming Research Assessment (CoARA), the DFG, and Helmholtz (soon).
    • ... citations:
    • ... careers:
      • Technical skills are valued
      • Research Software Engineer (RSE) positions

    ... Sovereignty?

    sovereignty (noun)
    sov·​er·​eign·​ty
    1a : supreme power especially over a body politic
    b : freedom from external control : autonomy
    c : controlling influence

    Synonyms:
    independence   freedom   independency   liberaty   autonomy   emancipation

    Antonyms:
    dependence   subjection   unfreedom
    https://www.merriam-webster.com/dictionary/sovereignty

    Your choice of tools influences your sovereignty

    Data Management Perspective

    Where do I put my stuff?

      Services
    • make *the* difference for advertisement, discovery, convenience, openess
    • often chosen based on (free) availability, customs in the lab or field, institutional requirement or offer
    • But: Imply dependencies

      • Make sure data/metadata are self-contained and portable
      to facilitate/enable transition to another service!

    Software Perspective

    What tools do you use?

    ...
    ...
    ...
    ...
    ...
    ...

    What tools do you rely on?

    • Who owns them?
    • What if they go away?



    Open Science practices fit digital sovereignty

      Open science principles for research tools
    • Accessible
    • Open formats and standards
    • Customizable
    • Interoperable
    • Open source
    www.sovereign.tech/, eu-stf.openforumeurope.org

    ... but isn't this often also more complex?

    Complex or unfamiliar, convenience or lock-in?

    Choose your tools wisely

    • Open source: You can have the code, customize, fork, self-host
    • Interoperability instead of lock-in: Favour open formats, extensibility; Community standards (e.g. BIDS) > idiosynchratic solutions
    • Unfamiliar does not necessarily mean unintuitive/complicated
    • Centralized things have a single point of failure
    • Where you can't choose, have a Plan B in place (Lab requires MatLab? Make sure coded also runs in octave!)

    Example: Open tools in medicine

    abcd-j.de: Collaboration between university clinics in NRW and researchers in INM-7. Provides open source research software stack for data acquisition/patient monitoring, RDM, and analysis

    Inclusive, collaborative, educational spaces



    Top left: OHBM Brainhack, Top right: Neurohackademy,
    Bottom left: DataLad Handbook contributor count, Bottom right: Turing Way bookdash

    Take home messages

    • Software is a key ingredient to a scientific result.

    • Sharable and shared code improves efficiency, accessibility, reproducibility of science - but more than anything else, the science in your next project. And: its good for your career.

    • Working on and with software is technical and complex, but neuroscience is a good place to learn and teach.

    • Open science and open source go hand-in-hand: For transparency and reproducibility, for science-specific requirements, for open formats, for re-use, and to enable interoperability across tools. And for digital sovereignty.

      Distribits 2025
    • 23.-25. October
    • International conference on distributed data management technologies
    • 2 day conference, one day hackathon
    • @ Haus der Universität Düsseldorf
    • In-person and remote via livestream
    • free!




    distribits.live

    Thank you!