RSE: Co-Author or Acknowledged Contributor?

A Research Software Engineer (RSE) who builds or maintains code for a study sits in a genuinely ambiguous spot on the authorship line. Unlike a data-entry technician or a routine core-facility service, RSE work can range from running someone else’s pre-built pipeline to designing the analysis algorithm the paper’s results depend on — and only some of that range meets the threshold research communities actually use for authorship. This guide applies the field’s standard authorship test, ICMJE’s four-criteria framework, plus the CRediT taxonomy and the FAIR4RS Software Citation Principles, directly to software contributions, so research teams can make that call consistently instead of by convention or seniority.

The authorship test, unmodified for software

The International Committee of Medical Journal Editors (ICMJE) sets the most widely adopted authorship threshold across the sciences, and it applies to software contributors exactly as written — there is no separate, lower bar for code. Per ICMJE’s current recommendations, authorship requires meeting all four of the following (not any one):

Substantial contribution to the conception or design of the work, or the acquisition, analysis, or interpretation of data for the work;
AND drafting the work or reviewing it critically for important intellectual content;
AND final approval of the version to be published;
AND agreement to be accountable for all aspects of the work, including ensuring questions about its accuracy or integrity are investigated and resolved.

ICMJE is explicit that a contributor who satisfies fewer than all four “should not be listed as authors, but they should be acknowledged” — and that determining who qualifies is the collective responsibility of the author group, not the journal or the PI alone. For an RSE, criterion one is rarely the sticking point: writing an analysis pipeline is itself “analysis of data for the work” in nearly every reasonable reading. The criteria that actually separate authorship from acknowledgement in practice are two, three, and four — substantive engagement with what the manuscript claims, sign-off on the submitted version, and accountability for the work’s integrity, not just its code. See CASRAI’s dedicated ICMJE Authorship Criteria guide for the full four-requirement breakdown outside the software-specific context covered here.

Where the line actually falls

Applying that four-part test to real RSE scenarios produces a workable, if not mechanical, split:

Contributions that typically clear the authorship bar

Designing the algorithm or analytical method that the paper’s central results depend on — not just implementing a specified method, but making the design decisions that shape what the analysis actually does.
Building novel software that is itself a research output — a new simulation framework, a new statistical package, a new pipeline architecture — where the software’s design choices materially affect the paper’s findings or its own software paper.
Substantial involvement in interpreting results that the RSE’s own code produced, including catching and resolving issues that changed the paper’s conclusions.
Reviewing and taking responsibility for the manuscript’s methods section, and reviewing drafts critically enough to request substantive changes — not merely proofreading for typos.
Willingness to be accountable if a methods or reproducibility question arises post-publication — agreeing to help investigate a data-integrity concern traced to the code, not just handing over a repository link and stepping away.

Contributions that typically warrant acknowledgement, not authorship

Running existing, unmodified software on a dataset with default or user-specified parameters, without contributing to how the analysis was designed.
Routine technical support: setting up a compute environment, debugging a script someone else wrote, migrating code between platforms, or general IT/HPC troubleshooting.
Maintaining shared infrastructure the study happened to run on, where the RSE had no role in the study’s design or the specific code that produced its results.
One-off consulting — answering a technical question or reviewing a code snippet — without ongoing engagement in the manuscript.
Any contribution where the RSE has no visibility into, or stake in, the manuscript’s actual claims and would have no basis to stand behind them if challenged (ICMJE’s fourth criterion is the one this category most clearly fails).

ICMJE’s own examples of acknowledgement-only roles are instructive by analogy: it lists “general supervision of a research group,” “acquisition of funding,” and “writing assistance” as contributions that alone don’t meet the bar — the same logic extends directly to “ran the pipeline” or “kept the cluster online” without deeper engagement in the work’s substance.

Two better options than a binary yes/no

The authorship/acknowledgement binary is ICMJE’s framework, but it is not the only recognition mechanism available, and RSE-specific software contributions are exactly the case where the binary undersells what’s actually available:

CRediT contributor roles

NISO’s CRediT (Contributor Roles Taxonomy) gives software work a formally recognized role — Software, covering “programming, software development, designing computer programs, implementation of the computer code and supporting algorithms, testing of existing code components” — that can be assigned to an RSE regardless of whether the RSE also meets the ICMJE authorship bar. A CRediT statement lets a journal or repository record precisely what an RSE did without forcing a single authorship/acknowledgement decision to carry all of that nuance. Many venues now expect a CRediT statement for every listed author; a growing number also accept it for acknowledged contributors, which is the more honest fit for software work that shaped a result without meeting all four ICMJE criteria.

Software citation as a third track

The FORCE11 Software Citation Principles, now maintained as the FAIR4RS Software Citation Principles, treat citation as a distinct recognition channel from both authorship and acknowledgement — software that a study depends on should be cited the way a dataset or a prior paper is cited, with its own persistent identifier where one exists (a Zenodo DOI, an entry in the Software Heritage archive, or a CITATION.cff file pointing to one). This matters directly for the RSE question: a tool an RSE built and released independently of the specific study — a general-purpose package the study happened to use — is usually a citation case, not an authorship or acknowledgement case at all. Citation and authorship are not mutually exclusive: an RSE can be both a paper’s co-author for their design and analysis contribution and have their released software separately cited by its own persistent identifier.

Practical guidance for research teams

Decide early, not at submission. The RSE role definition guide linked below recommends building CRediT/authorship expectations into a project’s plan from the start, precisely because resolving this after a manuscript is already in submission tends to produce disputes driven by who’s in the room rather than what was actually done.
Apply the same four-part test you’d apply to anyone else. There is no separate, lower authorship bar for RSEs, and there is no rule that automatically excludes them either — job title and pay grade are not ICMJE criteria; substantive contribution, drafting/review, sign-off, and accountability are.
Document contribution type, not just outcome, at the time work happens (a lab or project CRediT log, updated as work is done), so the eventual authorship decision is based on a record rather than a late-stage recollection.
Don’t let acknowledgement mean invisible. An RSE who doesn’t meet all four ICMJE criteria should still be named, with their specific contribution described — per ICMJE’s guidance, generic “technical support” acknowledgements without any description are exactly the pattern that under-credits substantial software work.
Consider institutional RSE authorship policy, where one exists. Several UK institutions and the RSE community itself (via the Society of Research Software Engineering) have pushed to formalize expectations around this precisely because inconsistent, case-by-case decisions were a recognized problem for the profession; check whether your institution or funder has adopted explicit guidance before defaulting to informal convention.

Frequently Asked Questions

Does writing code for a paper automatically make someone a co-author?

No. Writing code satisfies ICMJE’s first criterion (contribution to data acquisition, analysis, or interpretation) in most cases, but authorship also requires drafting or critically reviewing the manuscript, approving the final version, and agreeing to be accountable for the work. An RSE who writes code but has no further involvement in the paper typically doesn’t meet all four criteria and should be acknowledged instead.

Can an RSE be an author on multiple papers from the same shared codebase?

Yes, provided the RSE meets the four-criteria test separately for each paper — maintaining a shared tool doesn’t automatically confer authorship on every paper that uses it, but contributing to how that tool was applied, interpreted, and reported for a specific study can. This is a case where citing the underlying software by its own persistent identifier, alongside acknowledgement or authorship on the specific paper as warranted, is often the more accurate model.

What should an RSE do if they disagree with an authorship decision?

Raise it with the author group directly and early — ICMJE frames authorship-qualification as the author group’s collective responsibility, not something an editor, PI, or supervisor can unilaterally impose. Many institutions’ research integrity offices (in the UK, often via UKRIO-aligned policy) provide a process for resolving authorship disputes if direct discussion doesn’t settle it.

Is there a difference between an RSE and a general software developer for authorship purposes?

Not under ICMJE’s framework, which looks at contribution, not job title. In practice, RSEs are more likely to clear the authorship bar than a general-purpose developer because the role is specifically defined around embedded engagement in the research itself — but the determining factor is always what was actually contributed, not the position’s name.

Should software an RSE built be cited even if the RSE is also a co-author?

Yes, where the software has its own persistent identifier and is reused or referenced independently of the specific study. Authorship credits the RSE’s contribution to this paper; citation credits the software itself as a reusable output, and the two aren’t a substitute for each other.

RSE Co-Author or Acknowledged Contributor? Applying Authorship Criteria to Software Work