The software paper is one of the few manuscript formats built around a research output that isn’t itself a document, and that creates a genuinely different authorship question than a standard journal article does. When the “work” is a codebase, who has done enough to be an author on the paper describing it? The Journal of Open Source Software (JOSS) is the most widely used venue for publishing short, peer-reviewed papers about research software, and its submission guidelines set out an explicit position on this question — distinct in wording from, but compatible in spirit with, the general-purpose ICMJE authorship criteria most journals rely on. This guide covers exactly what JOSS requires for co-authorship, what it explicitly rules out, how the submitting author’s role differs from a corresponding author’s under ICMJE, and how JOSS’s rule maps onto a CRediT Software role when a project also files a CRediT statement elsewhere.
What JOSS actually requires for co-authorship
JOSS’s author guidelines, published in its submission documentation, put the bar in terms of active contribution to the project rather than a fixed checklist of tasks. The guidance explicitly accepts a broad range of contribution types as sufficient, including “active project direction and other forms of non-code contributions” — meaning a project lead who designed the software’s architecture, or a contributor who wrote substantial documentation or tests, can qualify even without having authored large amounts of source code themselves. What JOSS does not accept is a contribution that is purely financial or purely organizational: its documentation states plainly that “purely financial (such as being named on an award) and organizational (such as general supervision of a research group) contributions are not considered sufficient for co-authorship.” A grant that funded the work, or a PI’s general oversight of the lab that produced it, does not by itself earn a byline — there has to be a substantive contribution to the software or the paper itself.
Who decides, and what co-authors are agreeing to
Consistent with how most scholarly-publishing authorship policies are structured, JOSS does not put itself in the position of adjudicating who qualifies. Its guidance states that “the authors themselves assume responsibility for deciding who should be credited with co-authorship, and co-authors must always agree to be listed.” That consent requirement matters in practice: everyone named on a JOSS paper needs to have actually agreed to be listed before submission, not simply be added because they touched the repository at some point. Being listed also carries an ongoing obligation, not just a one-time credit: co-authors “agree to be accountable for all aspects of the work, and to notify JOSS if any retraction or correction of mistakes are needed after publication.” That accountability language echoes the fourth of ICMJE’s four authorship criteria (see below) even though JOSS frames it in its own words rather than adopting ICMJE’s text directly.
The submitting author must be a major contributor
JOSS’s review process (conducted openly on GitHub, with reviewers working through a public checklist against each submission) specifically evaluates whether “the full list of paper authors seems appropriate and complete,” and requires that the person submitting the paper be “a major contributor to the software” under review — not, for example, a lab administrator or a co-author submitting on someone else’s exclusive behalf. This is a meaningful difference from journals where the corresponding author role is largely an administrative/communications point of contact who may or may not be the paper’s most substantial contributor. On a JOSS submission, the acts of submitting the paper and having done substantial work on the software are meant to be the same act, not two independent roles that happen to be filled by different people.
What a JOSS paper itself has to contain
Authorship criteria don’t operate in isolation from what JOSS expects the paper and the underlying software to look like, so it’s worth knowing the shape of a typical submission when deciding who has contributed enough to be listed. Per JOSS’s current submission documentation, the paper (a short paper.md file, not a full research article) should run between roughly 750 and 1,750 words and include, at minimum, a Summary section describing the software’s high-level functionality and purpose for a non-specialist audience and a Statement of need explaining the research problem the software addresses and who it’s for. The author-list metadata in paper.md requires each author’s name and a numbered affiliation; JOSS does not require an ORCID iD for each author, though many submissions include one voluntarily since it’s good practice for unambiguous attribution regardless of venue. The software itself has to be open source under an OSI-approved license, feature-complete rather than a proof of concept, and have a real history of public development — JOSS explicitly does not accept “thin” wrappers, single-function packages, or software with no public development history. None of this changes who counts as an author, but it does explain why “wrote the paper” and “built the software” are treated as inseparable at this venue in a way they sometimes aren’t elsewhere.
How JOSS’s criteria compare to ICMJE’s four-part test
Most non-software journals that set explicit authorship criteria use, or closely follow, the ICMJE’s four-part test: substantial contribution to conception/design or data acquisition/analysis/interpretation; drafting the work or reviewing it critically for important intellectual content; final approval of the version to be published; and agreement to be accountable for all aspects of the work. All four have to be met — someone who satisfies only some of them should be acknowledged rather than listed as an author. JOSS’s language is shorter and written specifically for software rather than adapted from a general biomedical-manuscript template, but it lands on the same underlying principle: substantial, verifiable contribution plus ongoing accountability, with financial support and general supervision explicitly excluded as sufficient grounds on their own. The practical difference is scope, not philosophy — ICMJE’s criteria were written with a drafted manuscript in mind, so JOSS had to translate “drafting the work” into something that makes sense when the primary research output is a codebase, not prose. See CRediT vs. ICMJE for how a parallel translation problem plays out between CRediT’s contributor-role taxonomy and ICMJE’s criteria more generally.
Where CRediT fits alongside a JOSS submission
JOSS itself doesn’t require a formal CRediT contributor statement — its author-list requirement is satisfied by the paper.md metadata described above. But research-software teams that also deposit the software itself (for example, via Zenodo, to mint a citable DOI) or that publish a companion paper elsewhere frequently do add a CRediT statement at that point, and the Software role in the CRediT taxonomy — defined as programming, software development, designing computer programs, implementation of the computer code and supporting algorithms, and testing of existing code components — is the natural fit for describing what a given co-author actually did on a JOSS-published project. Listing CRediT roles alongside a JOSS byline isn’t required by JOSS, but it adds a layer of specificity (who wrote the core algorithm vs. who built the test suite vs. who wrote the documentation) that JOSS’s binary “author or not” byline doesn’t capture on its own.
Practical guidance for research-software teams
- Decide authorship as a team, early. JOSS explicitly puts this responsibility on the authors, not on JOSS editors or reviewers — don’t assume the venue will resolve a disagreement about who belongs on the list.
- Document non-code contributions. Documentation, testing, architecture/design decisions, and active project direction can all justify co-authorship under JOSS’s stated policy; keep a record (commit history, issue-tracker activity, design discussions) so the case for each author is defensible if a reviewer asks about it during the open review.
- Don’t add funders or supervisors by default. A grant or general lab supervision belongs in an acknowledgments section or funding statement, not the author list — the same principle ICMJE applies to non-qualifying contributors elsewhere.
- Make sure the submitting author is genuinely a major contributor. JOSS’s review checklist checks for this explicitly; a submission made by someone peripheral to the actual software risks review friction.
- Get explicit consent from every listed co-author before submission — JOSS’s own guidance makes this a stated requirement, not a courtesy.
Frequently asked questions
Does JOSS require ORCID iDs for authors?
No. JOSS’s paper.md format requires a name and a numbered affiliation for each author, but an ORCID iD is not a listed requirement, even though including one is common practice and helps disambiguate authors with similar names.
Can a PI who only supervised the project be listed as a JOSS co-author?
Not on the basis of supervision alone. JOSS’s documentation specifically excludes “organizational (such as general supervision of a research group)” contributions as sufficient for co-authorship on their own; a supervising PI would need a substantive, direct contribution to the software or paper to qualify, separate from their supervisory role.
Is JOSS’s authorship policy the same as ICMJE’s?
Not identical in wording, but aligned in principle. Both require substantial contribution and exclude funding/general-supervision-only involvement, and both build in an accountability requirement for listed authors. ICMJE’s is a formal four-part test written for manuscript-based research broadly; JOSS’s is shorter guidance written specifically for software submissions.
Who should be the submitting author on a JOSS paper?
JOSS’s review checklist requires the submitting author to be a major contributor to the software itself, not simply whoever is available to handle correspondence — a meaningful difference from the more purely administrative corresponding-author role at many other journals.
What happens to contributors who don’t meet JOSS’s authorship bar?
JOSS doesn’t prescribe a specific acknowledgments format the way ICMJE does, but the same general practice applies: contributors whose involvement falls short of substantive (for example, one-off bug reports, minor typo fixes, or purely financial support) are typically credited in an acknowledgments section or the software’s own contributor file rather than as paper authors.
