Software Guidelines

Below you will find the guidelines for submitting software. Download the guidelines as a PDF here.

Mission and Scope of Software Submissions 

Aperture recognizes the essential importance of software to the advancement of science, especially in neuroimaging research. When submitting Software Research Objects to Aperture, authors are welcome and encouraged to think broadly beyond the traditional PDF of “Software” and “Toolbox” papers. 

As for any Aperture Research Objects, software submissions will be selected and reviewed based on their quality, impact, relevance, and their ability to increase connectivity among researchers in the field. The software should fall within the interest of the OHBM mission to advance the understanding of the anatomical and functional organization of the human brain with a strong focus on neuroimaging. Research Objects involving animal studies are also welcome. 

Submissions that report minor plug-ins for existing software or minor advancements of existing algorithms with limited breadth or impact are unlikely to be selected for peer review. However, submissions representing important changes (even if small) in a previous toolbox/library, but with great impact and utility, are very much welcome.

Almost every active researcher in the field of neuroimaging develops software in one way or another, and many research labs have their specialized in-house software. Aperture aims to publish code that is likely to have a broader utility (beyond one’s own lab). Due to the extensive workload for reviewers to assess code, not every submission may make it to peer review unless it is deemed to be of broader utility to the community. 

Types of Software Submissions 

Types of code submissions can be, but are not limited to the categories below: 

Software and toolboxes: Authors can submit stand-alone software packages and toolboxes for neuroimaging analyses.

Examples: AFNI, TDT Decoding toolbox, PMC Toolbox, CVMANOVA toolbox, etc.

Notebooks and pipelines: Authors can submit Notebooks (E.g., Jupyter, R) and scripts (e.g. Python, Matlab/Octave markup code). While Aperture would prefer open source software (i.e., Python, Octave), Matlab is welcome too (as it can be widely distributed and can be compiled). The editorial team will consider submissions of non-open software on a case by case basis.

Notebooks can be educational in nature, they can contain pedagogical tutorials, they can reveal insights into specific analysis steps, and/or they can be entire processing pipelines. Submissions should include as much supporting information as possible. Documentation should be included within the notebook/mockup file. 

Examples: BrainWavelet Matlab filters, Jupyter Notebook for simulating fMRI PSF, Python Pipeline HyPyP for hyperscanning, BV Notebooks, PrF fitting in Python, etc. 

Apps and Web tools: Submissions can be smartphone apps for Android/iPhones and/or cloud-based or browser-based software. Such apps could, for example, serve an educational purpose regarding neuroimaging data acquisition, data reconstruction, brain science, or other topics.

Examples: Phone apps Kspapp, BrainTutor. Web-based analysis tools: MRI-Cloud, GiraffeTools, BioimageSuite, etc. 

Brain imaging data acquisition and reconstruction code: Submissions can be open code related to MRI sequences, MR-signal simulation, and/or MRI image reconstruction (or other brain imaging modalities). Non-open sequence code that is confined to the programming environment of commercial vendors does not fall within the scope of Aperture’s code submissions. 

Examples: ODIN, Pulseq, TOPPE, JEMRIS, Gadgetron programs, etc.

Requirements of Software Submissions 

Authors are encouraged to submit software that is open-source and accessible via a trusted repository. Please link to this repository using the “Research Object Types” Form in the “Forms” tab on the Submission Platform. While any software that may have significant impact on the field may be submitted, Aperture encourages authors to submit software that fulfills the following criteria. Deviations from these criteria should be explained in the cover letter. 

1. Open source: Software should be Open Source as defined by the https://opensource.org/osd. If the software is not or cannot be open source, you are asked to provide the reason and the implications/interests involved.
2. License: Aperture software submissions require that the open source code is legally usable with an explicit license attached. Open source code is encouraged to be under an Open Source Initiative approved license. Full list of acceptable licenses.
3. No cost to readers: The software should be freely available for the reviewers and readers of Aperture. The software should ideally be executable in a free coding environment. Software submissions for non-free environments (E.g. MATLAB, IDL, etc.) will be considered, but may make reviewing more difficult.
4. Tested and Validated: At this time Aperture will only accept submission of software that have been heavily tested and validated. Authors should provide a detailed description of the test results and share the tested data. 
5. Dependencies: All dependencies of the submitted code must be documented, they must be listed with their respective software version, and they must be openly available too.
6. Timing of software availability: The software needs to be available at the time of submission, so that reviewers can test the software and potentially inspect the code.
7. Code versioning: The code should be versioned. Only the original time-stamped Research Object at the time of submission will be peer-reviewed. 
8. Reliable software hosting: The software should be hosted on a trusted repository that is both reliable and will maintain open access on a long-term basis (for at least 5 years). Authors should host the software in good faith that users will be able to access the software in the years to come. If the hosting site goes off-line, the authors need to resubmit/edit the Research Object. Hosting code via lab-operated, or personal websites is not recommended.
9. Anonymous access: The software should be available for peer-review without the necessity of the reviewer to disclose her/his identity. Examples of reliable and acceptable code hosting platforms are: GitHub, Zenodo, GitLab, SourceForge, NITRC, Figshare, Docker Hub, etc. 
10. Accompanying data: Authors may submit any relevant data along with the software submission (i.e., as examples or tutorials). The accompanying data need to comply with the General Data Protection Regulation (GDPR) of the EU or the laws governed by the country where informed consent was obtained. The Authors should explain the reasons for sharing the data along with the code and any relevant implications to consider.
11. Code efficiency: Inefficient software has financial costs for users and environmental costs for us all. Authors are encouraged to optimize their code prior to submission such that these costs are minimized.
Preparing Your Research Object