Examples
Worked examples
- Is an instance
A research group with a mature, actively-used open-source Python package submits a short paper describing it to JOSS; two independent reviewers work through a public GitHub-issue checklist covering the license, documentation, tests, and installation instructions before the editor accepts it.
- Is an instance
After a successful JOSS review, the authors tag a release, archive it to Zenodo to obtain a version-specific DOI, report that DOI back in the review thread, and JOSS then assigns its own DOI to the paper and deposits its metadata with Crossref.
Counter-examples
Looks similar, but isn't
- Not an instance
A conventional research article that merely uses an existing, unrelated software package as a tool is not a JOSS submission -- JOSS reviews the software engineering artifact itself, not results produced with someone else's tool.
- Not an instance
A minor utility script or a thin wrapper around another library, without a substantial, feature-complete scholarly contribution, does not meet JOSS's acceptance bar even if it is open source.
Editorial commentary
JOSS, the Journal of Open Source Software, is a peer-reviewed, diamond open-access journal — no author-facing charges and no subscription fee — that publishes short scholarly papers describing research software. It was founded in 2016 under the Open Journals umbrella. Critically, a JOSS paper is not the software; it is a citable academic record about the software, distinct from any archive DOI the software itself carries.
What it actually publishes
JOSS papers are brief — typically 750 to 1,750 words — structured around a paper.md file that must include, at minimum, a Summary and a Statement of need, with author metadata (name and numbered affiliation; an ORCID iD is common but not a stated requirement). The paper documents software that solves a real research problem — JOSS explicitly excludes minor utilities or thin API wrappers — and must be feature-complete and designed for maintainable extension, not a first draft of an ongoing project.
Review model
Review is fully open and conducted on GitHub issues rather than behind closed doors. Two independent reviewers with relevant domain expertise work through a public checklist covering the paper and the underlying code together: an OSI-approved open-source licence, adequate documentation, evidence of tests and quality engineering, and installation instructions, among other criteria. Reviews stay publicly visible during the process and remain visible afterward.
On authorship specifically, JOSS’s own guidance states that ‘active project direction and other forms of non-code contributions’ can be sufficient for co-authorship, but that ‘purely financial … and organizational … contributions are not considered sufficient.’ The submitting author must be a major contributor to the software, is responsible for deciding who is credited as a co-author, and every co-author must agree to be listed and remains accountable for any later retraction or correction.
What happens at acceptance
Successful review does not by itself produce a DOI. After review concludes, the authors make a tagged release of the software, archive a copy with a data-archiving service such as Zenodo or figshare, obtain a version-specific DOI from that archive, and report it back in the review thread. Only then does JOSS assign its own DOI to the paper and deposit the paper’s metadata with Crossref; accepted papers are also archived with Portico for long-term preservation.
How it relates to the rest of the software-citation stack
A JOSS paper is a specific, journal-published instance of the broader software paper concept. It sits downstream of the other standards in this cluster: a well-formed CITATION.cff file gives reviewers and later readers machine-readable citation metadata for the software under review, and the two-DOI outcome of a JOSS submission — one DOI for the archived software (via Zenodo/figshare), one for the paper itself (via JOSS/Crossref) — is a direct, concrete application of the FORCE11 Software Citation Principles‘ requirements for unique identification, persistence, and specificity, and reflects the FAIR4RS Principles‘ emphasis on making research software itself findable and reusable, not just the paper describing it.
What this means for a researcher or research office
Assessment and credit: a JOSS paper gives software development work a citable, DOI-bearing scholarly output that can sit in a CV or grant report alongside conventional articles — useful in institutions and funders that recognise software as a first-class research output, and a concrete artifact for research offices building out software-inclusive assessment criteria consistent with initiatives like DORA or CoARA.
DMPs: where a project’s software output is intended to be substantial and reusable by others, a data management plan can name JOSS (or an equivalent venue) as the intended route to a citable software record, alongside the separate archiving/DOI plan the software itself needs regardless of whether a JOSS paper is pursued.
Interaction with ORCID/DataCite/Zenodo: the archive DOI JOSS requires before publication is commonly a DataCite DOI minted through Zenodo’s GitHub integration; author ORCID iDs on that archive record (and, where included, on the CITATION.cff feeding it) let both the software deposit and the resulting JOSS paper flow back into each author’s ORCID record.
Frequently asked questions
Does publishing in JOSS replace archiving my software with a DOI?
No — it requires it. JOSS’s process makes a version-specific archive DOI (from Zenodo, figshare, or a similar service) a precondition of acceptance, obtained after review concludes and reported back before JOSS assigns its own paper DOI. The two identifiers serve different things: one citably identifies the software release, the other citably identifies the paper about it.
Who counts as an author on a JOSS paper?
JOSS accepts active project direction and other non-code contributions as sufficient grounds for co-authorship, but treats purely financial support or general supervisory/organizational roles as insufficient on their own. The submitting author, who must be a major contributor, is responsible for deciding the author list, and every listed co-author must agree to be included and remains accountable for the work afterward.
Is a JOSS paper the same thing as a software citation?
Not quite — it’s one specific, higher-effort way to make software citable. A software citation (per the FORCE11 Software Citation Principles) can be satisfied by citing an archived software release directly via its own DOI; a JOSS paper is an additional, peer-reviewed scholarly wrapper around that same underlying software, useful where a citable, reviewed narrative about the software’s purpose and quality adds value beyond the archive record alone.
Will minor scripts or lab-internal tools get accepted by JOSS?
Generally not. JOSS’s stated scope excludes minor utilities and thin wrappers around other libraries; it expects feature-complete, actively maintained software making a substantial contribution, evaluated against a public reviewer checklist rather than accepted as a matter of course.
References
- joss.theoj.org/about — JOSS scope, review model, and cost.
- joss.readthedocs.io/en/latest/submitting.html — submission and post-review archiving/DOI process.
- joss.readthedocs.io/en/latest/paper.html — paper.md structure and length requirements.
Machine-readable encodings
Use in your systems
<role vocab="credit"
vocab-identifier="https://casrai.org/dictionary/"
vocab-term="JOSS (Journal of Open Source Software)"
vocab-term-identifier="https://casrai.org/dictionary/term/joss-journal-of-open-source-software" />{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"@id": "https://casrai.org/dictionary/term/joss-journal-of-open-source-software",
"name": "JOSS (Journal of Open Source Software)",
"identifier": "https://casrai.org/dictionary/term/joss-journal-of-open-source-software",
"description": "JOSS is a peer-reviewed, diamond open-access academic journal, founded in 2016 under the Open Journals umbrella, that publishes short papers (roughly 750-1750 words) about research software rather than the software itself. Acceptance requires an OSI-approved open-source licence, substantial and feature-complete engineering work, adequate documentation and tests, and a version-specific DOI from an archiving service (e.g. Zenodo or figshare) obtained after review; accepted papers receive their own Crossref DOI.",
"inDefinedTermSet": "https://casrai.org/dictionary/domain/publishing#set",
"url": "https://casrai.org/dictionary/term/joss-journal-of-open-source-software",
"sameAs": [],
"license": "https://creativecommons.org/licenses/by/4.0/",
"publisher": {
"@id": "https://casrai.org/#organization"
},
"author": {
"@id": "https://casrai.org/#editorial-team"
},
"datePublished": "2026-08-22T08:50:34",
"dateModified": "2026-09-04T07:25:30",
"inLanguage": "en-GB",
"isAccessibleForFree": true
}
