By SSI Fellow Meag Doherty, Anja Eggert, Yomna Eid, Kjong-Van Lehmann, Christian Meesters, and Lennart Schüler.

At the recent Open Science Retreat, a group of us from across scientific domains dove into our issues of usability in scientific software. Below is a recap of the discussions and next steps.

The Sorry State of Usability in Open-Source Scientific Software

A large fraction of science depends on the reliability of community open-source software. Without reliably maintained software, without software which can be ported across systems, results are - by definition - not reproducible. All group members expressed frustrations about the usability of their current software. To find a way out, we asked ourselves:

What are the conditions that enable scientific open source teams to prioritise and focus on usability successfully? And who can effectively help change the status quo?

What constitutes usability in this context

As we started our discussion, it became clear that not everyone saw usability the same way. Is usable the same as maintainable? Does it only apply to Graphical User Interfaces (GUIs)? If I’m the only user of my software and I think it’s usable, is it so?

To find common ground for our three days together, we collected aspects of what constitutes usable free open science software based on our own experiences.

And while many of the following aspects seem obvious and are solved in many communities, they are often missing and do constitute a challenge in FOSS, particularly in smaller software projects that however provide key elements for analysis. Critical elements for usable software:

• License: A free permissive license is a prerequisite for the community to be able to use existing software packages.
• Documentation: Usage examples are an integral part of the documentation that is often ignored, but can make a significant difference for the user. Well-structured documentation such as (https://documentation.divio.com/) is essential for software to be usable. This allows the user to utilize the software according to the specifications and to prepare the input appropriately.
• Versioning: Code should be bundled in releases accompanied by changelog and release notes. This ensures reproducibility and makes the user aware of altered software behaviour.
• Deployability: For software to be usable, it should be deployable. In other words, there needs to be an installation routine available that takes care of compilation and dependency resolution in an automated fashion. Additionally, it would be desirable to have executable containers available so the user can get started immediately.
• Issue Tracker: Usable software should have a mechanism by which users can provide feedback and record potential bugs and issues, and ideally request support. This could take the form of a forum, chatroom or an email 'support' like process.
• Avoiding proprietary code base: For various reasons, some of which are historic, proprietary code bases are still popular (e.g., Matlab, Mathematica, SAS). However, any new software that depends on licensed code bases creates severe barriers to portability and adoption.

Pathways to achieving “Usable Software”

We will continue to raise awareness about these issues. By sharing personal stories that we drafted during the retreat, funders, principal investigators, and open science practitioners will more clearly see the usability problems facing scientists.

We also believe it is worthwhile to advocate for basic usability review criteria similar to those in the Journal of Open Source Software (JOSS) to be used on papers describing scientific software releases. In the coming weeks, some members of the group will circulate a letter advocating for this change.

If you are interested in this topic, follow the ‘Usable Software Ecosystems Research’ (USER) study by Superbloom Design Github repo for forthcoming research results on the considerations and practices around usability and design in open source scientific and research software.