As an open source software developer who is also an academic, I struggle quite a bit with getting my traditional peers and higher ups to make sense of software contributions. While developing and maintaining OSS is quite time consuming in and of itself, taking even more time to write a contrived journal article around a piece of software merely for academic credit is extremely frustrating and ridiculous. Arfon Smith and I have been brainstorming a new journal (yes, sigh) targeted squarely at research software engineers.
Ok, so what’d we come up with?
Enter the Journal of Open Source Software (JOSS). Any research software engineer developing software with a research application (the only scope limitation of the journal), will need to write a high level description of what the software does, along with brief descriptions of potential applications. This paper should be no more than 2-3 pages long and include a few influential citations. So the only noticeable change to a software engineer’s workflow will be to develop this
paper.md as part of the software development process. That’s it!
Well, ok, there’s a bit more. A few other key requirements to get a paper accepted:
- It must have a valid open source license.
- It must include valid metadata following our JSON schema.
- The version of the software described in the paper must be deposited in a repository like Zenodo.
We anticipate that all of this should add about one hour of additional time to development.
What reviewers are looking for
- Good software practices such as unit tests with substantial coverage, good documentation, some form of continuous integration, clear descriptions of usage, and ways to contribute/report problems. More information on our reviewer guidelines page.
What reviewers are NOT looking for
- Novelty - We’ll let software usage metrics figure out what’s useful and what’s isn’t.
- A full code review - This is very hard to scale and not a key part of this journal’s objective.
Our hope is that this will provide a mechanism for academic software developers to get formal credit for their work within their institutions, and perhaps more importantly, elevate the quality and usability of research software being released. Once the submission process becomes familiar, the practices we require should become a standard part of an academic engineer’s workflow.