Publishing research software openly: Advice and best practices

Page reviewed:  11/04/2025

On this page, you can find information on how to publish research software openly. You can read about what to keep in mind when writing code, how to prepare your software for publication, where to publish, how to select a license, and how to make your software comprehensible, reusable and citeable.

Research software can be code used for generating, cleaning, analysing or visualising data. It can also be implementations of models, workflows, or software packages. Text files written in programming languages are called source code. Source code files in programming languages such as R and Python are sometimes referred to as scripts.

Even if your code was not originally written with the intention of being read or used by others, publishing it openly can still be valuable. Read more in this Nature article by Nick Barnes:

Reasons for publishing research software openly

There are many advantages to publishing research software developed within a research or environmental monitoring and assessment (EMA) project openly:

  • By publishing and archiving software in a good way, it will be safely and securely preserved for the future.
  • You and others can refer to the software with persistent links and also cite it in scientific publications.
  • Well-documented code serves as good descriptions of methods and workflows, facilitating for others to understand them.
  • You enable the validation and reproduction of scientific results.
  • Publication with version control makes it easier for both you and others to reuse or further develop the code.
  • You are able to meet requirements or recommendations on open sharing of code and data from journals or funders.

Things to consider when publishing research software

  • When you publish research software, it needs to be understandable and reusable by others. Use good coding practices from the start.

Select a repository, which can assign persistent identifiers, such as DOIs, to your software when you publish, to ensure that your code can be cited and linked to in a sustainable way. Ideally, publish related code, data, and documentation together in the same repository. Should these be published separately, ensure they reference each other using persistent links.

  • If you have a specific version of code and data associated with a project or article, consider publishing your files in a research data repository. At the Swedish National Data Service (SND), publications are assigned persistent identifiers, and your publication will be preserved and archived at SLU.
  • Software, which you plan to maintain and develop further, can be published in a code repository such as GitLab or GitHub. GitHub offers the possibility of assigning a DOI to a specific version of the code through an integration with Zenodo.
  • Software packages can also be published in a package repository, such as CRAN, PyPI, or Bioconductor.
  • To increase discoverability, you can register your published software in a community registry, such as rOpenSci.
  • You can also increase visibility of your published software by describing it in a scientific article. Some journals specialise in software descriptions (e.g., The Journal of Open Source Software), while discipline-specific journals may offer dedicated article types (e.g., "software notes" or "software articles"). Writing an article provides the opportunity to describe your software in greater detail, and you can encourage users of your software to cite the article.

Learn more

  • Organise files according to a logical folder structure that separates underlying data, code, and results.
  • Use descriptive names for files and folders to make it clear which file does what.
  • Version software and associated data separately. You can distinguish file versions by the file names or by using version control tools like Git.
  • Divide your code into modules or packages with clear purposes and boundaries.
  • Indent code blocks using tabs or spaces, following the conventions of the programming language you are using.
  • Use descriptive names for functions, classes, and variables to make it easier to understand what they contain.
  • Tidy your code before publication. For instance, remove code blocks you have disabled with comment characters if they no longer serve a purpose in the program.

Make it easier for others to understand how the software is used and what the code does, by documenting it thoroughly.

  • Include a README file, which is a plain text file directly readable by a user.
    • In the README file, describe how the software is run and used. Include any information that is useful for a user to know, for example if there are help commands available. If relevant, describe how the program is compiled.
    • Should the published code include multiple source code files, detail what each file does. Document whether the files are intended to be run as scripts, and, if so, if they are to be run in a specific order.
    • Include references to any other scientific publications, which the code or analysis methods are based on.
  • Add comments in the code to describe what the code does and why.
  • Begin each source code file with a header in the form of a comment that includes:
    • Title
    • A description of what the file does and how it relates to other files in the publication
    • Version
    • Date
    • Identifier for the code publication (e.g., DOI)
    • Identifiers or references to related publications (e.g., an article, report, or data publication)
    • Contact details of the creator (name, email, and if relevant ORCID and affiliation)
    • Licence information, if applicable
  • One way to document workflows is to employ so-called "literate programming". Here, programming code is interspersed with text written in natural language. This can be done by using the Markdown markup language. Using Markdown allows you to create reproducible reports containing text and analysis results, which can be converted into PDF or Word documents. Quarto is a popular system for combining code with Markdown, which can be used for literate programming.
  • Another way of documenting workflows is to use a script that automates the steps in the process.

Learn more

To ensure that the software can be used over time, it is important to describe the environment within which the program was created. Specify the version of the operating system, programming language, and any libraries, modules, or packages used by the program. This can be done in different ways:

  • Include this information in the README file. 
  • In R, you can use the command “sessionInfo()”  to retrieve the current information after running your program. You can save the output as a text file and publish it together with the code. 
  • Another way is to include the information in the form of a metadata file, which can be read by supporting software, for example Pipenv for Python or renv for R. 
  • To facilitate the recreation of the environment needed to run the software, you can make use of the so-called container technology. Thus, a tool, such as Docker, packages the code together with associated software libraries in order for it to be run in isolation in a controlled environment and, hence, work on different computers. 

Learn more

  • Docker, a platform for creating containers

Open source means that software is free to use, modify, and share. If possible, avoid making your published code dependent on non-open source software. Prior to publishing, it is important to ensure that you hold the rights to the software in its entirety and thereby have the right to distribute it.

  • Software that you have created yourself can be provided with a license specifying how it may be reused. Licences that meet open source requirements are preferable.
  • Include the licence information as a text file named LICENSE.txt (or LICENSE.md if using Markdown). Moreover, add a copyright statement in the header of the source code file. Alternatively, you can paste the full licence text into the source code file itself.
  • All persons involved in the creation of the software must consent to its publication.
  • When reusing parts of code created by someone other than yourself, you must comply with the licence provided. If the code has not been provided with a license permitting re-publication, you will need permission from the copyright holder before publishing your software.
  • Remember to cite when using code created by someone else.

Learn more

Ensure that the software runs successfully before publishing your code. It is recommended to test whether the program works as expected on a computer other than your own. If possible, ask a colleague to review and test run your code on their computer.

  • Make sure that all the files needed to run the program are included in the publication.
  • Check that the file paths point to files within the published folder structure, and not to locations specific to your own computer. This is referred to as using relative paths instead of absolute paths.
    • Example of an absolute path in Windows: "C:\Users\jdoe\research_project\analysis\article2024\mycode\data\data_file.csv"
    • Example of a relative path in Windows: "..\data\data_file.csv"
  • Some journals require that you make data and code available already during the peer review process of an article. Should you choose to publish via the Swedish National Data Service (SND), you can share your files with the reviewers, without publishing them openly until the article has been accepted.

Learn more

Do you need help?

SLU has a support service that assists staff with issues relating to the management of research and environmental assessment data. The support service includes data management specialists, IT experts, archivists, lawyers, research advisors, information security specialists and librarians

Learn more about good coding practice

Contact