💾 Archived View for nomadpengu.in › thoughts › agony captured on 2023-04-19 at 22:26:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Posted on 2022-02-18
The neuroimaging software ecosystem is an absolute mess. Much of it is written by people with no programming experience before they started their thesis project. Documentation is sparse. Massive source files with loops nested five or six layers deep abound. Even more problematically, much of it is written for use on single papers and thereafter abandoned. While most of it is "open source" in some form (I would exclude papers that say "code available upon request"), the FOSS community goodness you would expect is completely absent.
The most ubiquitous software package, FSL from Oxford, is not officially available on any git server. That means there's no seamless way for the community to contribute -- there are old school email lists, but I don't believe I've come across people sending patches. Again, most of the community are people with backgrounds in neuroscience and medicine, i.e. not hackers. Getting my lab to even periodically commit things to our GitHub has been a constant and uphill battle -- how does anyone expect the community at large to a) read and edit poorly documented C and b) navigate mailing lists to send patches? It also means that versioning is completely opaque to the users, all you get are binaries or loose source files. The preferred way to install FSL is through a nearly 3000 line python2 script [1] that inexplicably abuses OOP patterns.
Another keystone piece of software, freesurfer, has a weird non-FOSS custom license whose purpose seems to be to limit the legal liability of Massachusetts General Hospital. To use fs, you have to download a separate license.txt and point the package to it every time you invoke a command.
Even worse, huge chunks of the neuroimaging ecosystem are built on top of Matlab. There have been attempts to make them Octave compatible, but afaik, the performance of Octave is still nowhere near that of Matlab. Although I strongly believe that all scientific work should be carried out on FOSS only, the worst part of Matlab isn't its proprietary nature, it's the fact that Matlab tooling is completely nonexistent. CI/CD? Sure, in a toolbox that you can purchase separately. Packaging? Dependency management? Forget about it. Best you get are unmaintained scripts on the Matlab community forums.
There's been a decent push recently to make neuroimaging more open and developer-friendly. The nipy ecosystem [2] and BIDS [3] are not without their flaws, but I think they're doing an admirable (and often thankless) job. However, the very system of medical academia is stacked against them -- it's difficult to commit to using a new, well engineered piece of code when instead you could continue using an unmaintained piece of legacy code with more citations. There's a fundamental paradigm mismatch. As a developer, I automatically assume that a newer piece of software is more stable than a legacy code. (This isn't a good assumption all the time of course, but I do think it's generally true for good software.) But as a scientist, I place more belief in papers that are older and have more citations. There's no way to send in patch notes for your publication, no room for incremental improvement, no reward for bugfixes.
And that's all before Matlab dependencies come along and destroy any hope you ever had of containerizing your program.