Giving Back to the Open Source We Build On
Gabriel Devenyi, PhD
Every analysis we run at the Douglas Neuroinformatics Platform stands on software written by other people and given away for free. The scanner data becomes a paper because of ITK, ANTs, FreeSurfer, the MINC toolkit, RMINC, Nipoppy, Nextflow, nf-neuro, Dcm2Bids, jsPsych, and dozens of smaller libraries underneath them. None of it bills us. All of it needs maintenance.
Open-source tools do not maintain themselves. Compilers change, operating systems move on, dependencies break, and a package that built cleanly five years ago suddenly fails on a modern machine. Someone has to fix that. Too often the assumption is that “someone” is the original author, working alone, for free, in their spare time. When that person moves on, the tool quietly rots, and everyone downstream inherits the problem.
We decided a while ago that if we depend on a tool, we help maintain it.
What that looks like in numbers
We audited the public contributions our team has made to projects we do not own, since 2021. Excluding our own organizations and personal repositories, members of the platform have opened more than 200 pull requests across roughly 70 upstream open-source projects, over 130 of them already merged into the tools the wider community uses every day.
The bulk of that work comes from keeping the neuroimaging stack alive and correct:
Correctness fixes in foundational libraries. A patch to ITK corrected how MINC2 files are read, converting coordinates from RAS to LPS so that images land in the right orientation, a bug that silently affected anyone reading those files. Fixes to RMINC resolved rounding errors in world-to-voxel conversion and freed memory that valgrind flagged as leaking.
Keeping old code building on new machines. Modern compilers (GCC 15, C23) and build systems (CMake 4) break decades-old scientific code. We submitted fixes across libminc, minc-tools, the MINC toolkit, ITK, and older display tools so that this software still compiles and runs today, on Linux, on modern macOS, and on Apple Silicon.
New capabilities, not just repairs. The work is ongoing and
not only defensive: recent contributions add genuine four-
dimensional (x, y, z, time) MINC image support to ITK, fix a crash
in RMINC’s mixed-effects models under modern versions of lme4,
and correct how Bruker MRI raw data is read in the
brukerapi-python library.
Performance and reliability. We taught ANTs not to repeat an expensive bias-correction step on every iteration and to stop re-reading the same images from disk, and fixed segfaults that crashed it on missing files. Small changes, real time saved on every run, for every user.
Packaging, containers, and reproducibility. Docker and Singularity builds for FreeSurfer, DSI-Studio, and the scilus tools; conda-forge recipes; and container fixes that let these tools run inside Nextflow pipelines. We also published ready-to-use, reproducible Nipoppy pipeline configurations on Zenodo for FreeSurfer, mideface, and RABIES, so other labs can reproduce our processing exactly.
Not every contribution is accepted, and that is fine. Some of those pull requests are still open, some were declined in favour of a different approach. That is how a healthy project works: you propose, you discuss, you improve the tool or you learn why it is the way it is. The point is to show up.
Why this matters, and why we are asking you to care
Scientific software has a sustainability problem. The tools that underpin an entire field are frequently maintained by one or two people, funded by nothing in particular, competing for attention with the grants and papers that actually advance careers. Meanwhile thousands of labs build their published results on top of that unpaid work. When it breaks, science breaks with it, and the repair bill comes due for everyone at once.
You can help, whether or not you write code:
- Contribute back. If a tool you use has a rough edge, a broken build, a typo in the docs, fix it and send the patch. The first contribution is the hardest; after that it is a habit.
- Report clearly. A good bug report with a reproducible example is a real gift to a maintainer.
- Cite and credit the software you use in your papers, so the people maintaining it can point to its impact when they apply for funding.
- Fund maintenance, not just features. If your grant depends on a tool, a small amount of sponsorship or a maintenance contract keeps it alive far more reliably than hoping a volunteer has a free weekend.
We benefit enormously from the generosity of the open-source community, so we consider it part of the job to give back to it. If your group relies on scientific software and wants help maintaining it, contributing upstream, or building reproducible pipelines on top of it, get in touch at contact@douglasneuroinformatics.ca.