About the journal

Aims & Scope

VERSIONICS is an international, peer-reviewed, open-access journal for versioned research software from every discipline. The journal publishes software tools, executable pipelines, reusable benchmark suites and substantial version releases, and it evaluates them above all on two qualities: whether the software is genuinely useful in practice, and whether a stranger can use it.

The journal is founded on two premises. The first concerns time: research software is released, patched, refactored, ported, deprecated and superseded, and the version that a researcher executed is the only version whose behavior can be verified. VERSIONICS treats the version, rather than the project, as the unit of publication, review and citation, and provides a continuing venue for software as it evolves.

The second concerns people: most research software is written for its authors and dies with its project. The software worth publishing is the software that other people can adopt — installable in minutes, documented for newcomers, forgiving of mistakes, and useful beyond the laboratory that built it. VERSIONICS therefore places practical utility and user-friendliness at the center of review, ahead of technical novelty.

The journal aims to

1. establish versioned software artifacts, executable pipelines and reusable benchmark suites as first-class, citable scholarly outputs in any field of research;
2. make practical usability a reviewed, evidenced property of published software — not a promise in the abstract but a standard checked by a reviewer at a keyboard;
3. give sustained maintenance, substantial re-engineering and long-term stewardship an identifiable form of academic credit, rather than rewarding only first release;
4. verify claims by execution — every accepted article is accompanied by an artifact that an independent reviewer has installed, run and checked;
5. bind the scholarly record to the technical record through persistent identifiers, so that a citation resolves to an exact, retrievable state of the software;
6. hold benchmark and comparison work to a standard of fairness, disclosure and reproducibility commensurate with its influence on research and engineering practice.

Scope

VERSIONICS is discipline-agnostic. The journal welcomes software from the natural sciences, engineering, medicine and the life sciences, the social sciences, the humanities, education, and cross-cutting or domain-independent computing alike. What defines scope is not the discipline but the character of the artifact. A submission is in scope when it is:

• useful — it addresses a real, recurring task faced by identifiable users, and does something those users could not do, or could not do as well, with existing tools;
• usable — a competent newcomer can install it, run a first meaningful example and interpret the output without contacting the authors;
• reusable — it has a general interface (API, CLI, GUI or web front-end), accepts users' own data, and is free of hard-coded paths and private dependencies;
• maintained and versioned — it has a release history, an identified current version, and a credible statement of continued stewardship.

Tools that lower the barrier to entry are especially welcome: graphical and web-based front-ends for capable but forbidding command-line software, workflow tools that automate error-prone manual processes, and interoperability tools that move data cleanly between ecosystems. Domain-independent infrastructure — visualisation, data management, measurement, reproducibility tooling — is explicitly in scope.

The Usability Standard

Usability at VERSIONICS is a review criterion with defined evidence, applied to every submission:

• Time to first result. An independent reviewer, following only the public documentation, must reach a working installation and complete a first meaningful example in well under an hour; one-command installations that run their quick-start in minutes set the expected norm.
• Documentation for newcomers. A quick-start, a worked example with sample data, and reference documentation for every user-facing interface — reviewed as part of the artifact, not as a courtesy.
• Interfaces matched to real users. A library needs a clean API; a tool for non-programmers needs a GUI or web interface, sensible defaults and readable error messages. "Intended for non-specialists" claims are tested against non-specialist use.
• Graceful failure. Invalid input, missing dependencies and common mistakes should produce comprehensible messages, not stack traces.
• A path to help. A public issue tracker or support contact, and honest statements of limitations and supported platforms.

Out of scope

• conventional research papers whose principal contribution is a new algorithm, model, theory or empirical finding, where the software is merely an implementation;
• analysis scripts or notebooks written for a single study, with hard-coded paths, private data dependencies and no independent interface;
• thin wrappers over existing libraries that add no capability in function, performance, interoperability, workflow or usability;
• software that reviewers cannot install and run from the public documentation — whatever its technical merit;
• dataset descriptions as a primary output;
• performance rankings, vendor comparisons or marketing benchmarks that ship no reusable workload, harness, configuration or raw results;
• closed-source software that reviewers cannot execute, except under a narrow controlled-review exception with guaranteed long-term access;
• version announcements without demonstrated increment, and repeated submission of the same software with no identifiable new contribution;
• generic tutorials, repository announcements, and generated code the authors cannot evidence they understand, test and will maintain.

Submit your software