Software Papers

Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.

1. 01Enquiry and requirement assessment
2. 02Technical scoping and proposal
3. 03Execution
4. 04Quality review and delivery, with an agreed round of revisions

Read the full project workflow.

In depth: how the work is done

1. Purpose and scientific context

   The paper opens with the problem the software addresses, how people currently solve it and why the software is needed. It identifies target users and use cases. We help authors state this clearly and compare with related tools.

2. Functionality and architecture

   Describing capabilities, inputs and outputs, algorithms implemented and software structure helps readers evaluate the work. Diagrams of architecture and workflow are useful. We help authors write at a level suited to the journal's readers.

3. Example use and tutorials

   Worked examples show how to use the software on realistic problems, with input files and expected outputs. We encourage examples that run from the repository with minimal setup, which also supports reviewers who test the software.

4. Validation, tests and benchmarks

   Evidence that the software gives correct results includes unit tests, verification against analytic solutions, comparison with other software and benchmark cases. Performance data on typical problems show scaling and limits. We help present these concisely.

5. Documentation and availability

   Software papers include availability statements: repository URL, version, archived release with DOI, operating systems, dependencies and licence. Documentation covers installation, user guidance and API reference. We help authors check completeness.

6. Licences and citation

   A recognised open-source licence clarifies reuse rights, and a citation file or statement tells users how to credit the work. Legal specifics should be confirmed with advisers. We help authors describe these in the paper.

7. Sustainability and community

   Reviewers consider whether software will be maintained. Plans for maintenance, issue tracking, contribution guidelines and release practices indicate sustainability. Authors should be candid about the support available.

8. Limitations and known issues

   Software has limitations. Listing known issues, unsupported cases and performance constraints helps users and builds trust.

9. Versioning and reproducible environments

   Results produced by software depend on versions of the code, libraries and operating environment. Authors can improve reproducibility by tagging releases, listing dependencies with versions and providing environment files or containers. The paper should state the version described and how later versions differ. We help authors write this information clearly and check that instructions work on a clean installation.

10. Comparing with existing software honestly

    Readers want to know how the new software relates to established tools. A fair comparison lists features, strengths and limitations of alternatives, and benchmarks on shared problems. It should acknowledge where other tools are better. We help authors build balanced comparison tables and avoid claims that cannot be supported by the tests performed.

11. Performance, scaling and resource requirements

    Users need to know how long typical problems take and what hardware they require. Reporting run times on defined machines, memory use, parallel scaling and the largest problem tested sets realistic expectations. Authors should distinguish measured performance from projections. We help present these results in compact tables or plots with the hardware and settings stated, so others can repeat the measurements.

12. Encouraging contributions and external testing

    Software gains credibility when others have tested it. Authors can invite beta testers, include contributor guidelines, label good first issues and acknowledge contributions. The paper can mention users and projects that have adopted the software, if the authors can verify this. We help authors describe the community around the software honestly, without implying adoption that does not exist.

Common pitfalls this service helps avoid

• Repository not public or archived. Reviewers and readers need to access the code.
• No tests or validation. Correctness must be demonstrated.
• Unclear licence. Users cannot know how they may use the software.
• Overstated capabilities. Describe what the software actually does.

What good reporting looks like

Support for a software paper is documented with an availability checklist, a documentation and test summary, a licence and citation note and a limitations statement. Authors are responsible for the code and its quality. We do not write or modify research software in this service, and acceptance is not promised.

An illustrative scenario

Hypothetical example written for explanation. It is not a client case, a result or a testimonial.

Suppose a researcher develops a finite element library for micromechanics. The software paper describes the problem, design and features, presents verification against analytical solutions and a benchmark against another code, and gives an example that users can run. The repository has documentation, tests, a licence and an archived release. Known limitations, such as lack of contact modelling, are listed.

Questions to settle before you begin

• Is the code public and archived?
• What tests demonstrate correctness?
• Can a user run an example quickly?
• What licence applies?
• What are the known limitations?

Key terms

Unit test

An automated test of a small piece of code.

Repository

A hosting location for source code.

Open-source licence

Terms allowing reuse of code.

Archived release

A permanent snapshot of a software version.

Dependency

Another package that the software requires.

Working together on Specialised Scholarly Article Formats projects

Specialised article engagements begin by confirming which format suits your material, since short communications, methods, data, software, protocol and replication papers each have conventions and length limits. We ask for the results, code or datasets that the article describes, the target journal's guidelines and your deadline. Drafting follows the format's structure, and reporting checklists are applied where they exist. Statements about data and code availability reflect what you can actually share. We do not fabricate results, and we do not promise acceptance.

Few projects need a single service in isolation. These are the services most often combined with this one.

• Data Papers

  Support for data papers that describe a dataset, its collection, quality and reuse potential, so that others can find, understand and reuse it.

• Methods Papers

  Support for methods papers that present a new or improved method, with clear algorithm or protocol description, validation and comparison to existing methods.

• Numerical Methods & Scientific Computing

  Selection, implementation review and verification of numerical schemes for differential and algebraic problems, including stability, accuracy and performance considerations.