1 of 14

Open Software

EIPOD Open Science training

Lisanna Paladin

Bioinformatics Community Project Manager @ Bio-IT

Photo: Octopus by Jim Swoger, Montserrat Coll/EMBL Barcelona, sample courtesy of Roger Villanueva, ICM-CSIC

2 of 14

Open Source Software (OSS)

Software distributed with source code (often publicly available).

With licence allowing anyone to reuse, inspect, modify, and enhance the code.

opensource.org/osd

3 of 14

Why Open Source Software

Modularity & Flexibility of key components, vs. proprietary software solutions that tend to be monolithic.

Lower total cost of ownership (TCO) and Reliability: Lower comprehensive costs. More trust.

Secure & Transparent: Empirically, open source tends to produce better quality software. Why? Community.

britewire.com/why-open-source/

4 of 14

Community development

Three advantages of Open Software:

tap the knowledge of a diversity of developers, not just those on one organization’s payroll.
the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger.
open source software gets adapted to a variety of use cases, not just the one the originally intended, surfacing bugs and edge cases much more rapidly.

Bonus: Sustainability.

5 of 14

Why Open Source Software

opensenselabs.com/blog/articles/open-source-sustainability

The benefits don’t stop at the project itself. There are benefits for everyone involved, both at the level of the individual developers and the institution.

Individuals will benefit from the interactions with the community of collaborators, get valuable experience and get recognised for their contributions.

The organisations, in parallel, will benefit from this wide networks and from the recognition of their employees, will save money and resources and will be guaranteed to keep ownership over their results.

This is particularly true in science, which should enable progress for the scientific community and society as a whole.

Software too, as it is increasingly recognised on its own as a scientific output: for example, the Journal of Open Source Software publishes peer-reviewed OSS.

I could add to this a personal story: when I was interviewing for my current position at EMBL there was someone in the panel that was using a tool I built (a sequence feature viewer) and shared as OSS. More than that: they were actually contributors to the tool, as they pull requested a feature which they needed, and since then my team was maintaining that feature too, along with the rest of the tool. This was mentioned, and recognised, during my job interview.

So, all of this said…

6 of 14

How Open Source Software

Make source code publicly accessible from day one
Make software easy to discover by providing software metadata via a popular community registry
Adopt a licence and comply with the licence of third-party dependencies
Define clear and transparent contribution, governance and communication processes

Software Management Plan

7 of 14

The Software Management Plan

Publication

Stage 5: publishing software and/or research results obtained with the software

Production

Stage 4: production software working on real-world data in a scalable and stable manner

Application

Stage 3:

release and quality assessment

Construction

Stage 2: prototyping, construction and implementing core functionality

Inception

Stage 1: concept, proposal writing, planning and inception

In what stage is your project?

github.com/elixir-europe/smp/tree/main/paper

8 of 14

Facilitating open collaborative work

Publicly accessible repository with version control
Semantic versioning semver.org/
Changelog
Citation guidelines
Contribution guidelines

Code of Conduct

Licensing choosealicense.com/

Inception

1.0.0-beta

Major pre-release

Minor

Patch

During the initial planning of a project, it is important to keep all the document linked to each other, and possibly in a version controlled repository.

Git is an example of version control tool, that helps in tracking the history of changes made to the repository, who did them and if there are multiple “branches” of your project what is their relationship. Speaking of project versioning, using a semantic versioning naming will help in navigating the type of changes that were integrated between each version. The changelog document should include details about this. This as regards the “code” setup itself.

However, don’t forget to include other documents that will help potential collaborators and users. Citation guidelines, for example, will help people that want to use you code to recognise your work. Contribution guidelines, also including the community Code of Conduct, will set some rules and practices for collaboration.

Finally, licensing. Licence protect you and everyone involved in your project from misuse of the code, and protects you as the intellectual proprietary of it. Different type of licenses are best fit for different scenarios, have a look at choosealicense.com to navigate them.

9 of 14

Facilitating open collaborative work

Different types of documentation

For users (tutorials, example, explanation of features, …)
For contributors (comments, docstrings, …)

Construction

10 of 14

Tests are of triple value

Unit tests
Integration tests
Functional test
Performance tests

…

Safety net

Documentation

Lower entry barrier

Application

11 of 14

Automate when possible

Open source resources: GitHub and GitLab
CI / CD pipelines
Bots

Production

Automation can make your life easier on many fronts. If you host your code remotely in GitHub or GitLab, that serve also as a remote backup solution. It allows remote collaboration, and these resources can do more.

Consider using Continuous Integration and Continuous Deployment pipelines, integrated in both in GitHub and GitLab. They will allow you to specify a list of operations to be done every time you push a new version of your software, e.g. to update a website if your repository includes the content of a website (yes, you can create websites from GitHub and GitLab). They can be useful also to send or retrieve data from other sources, or run your code to calculate data every time you update it.

The picture on the bottom shows the EMBL internal GitLab platform. The EMBL GitLab is managed and hosted internally by the Bio-IT community, so if you are really worried about hosting online your project will not leave EMBL by adopting this solution. You have no excuses for adopting best practices!

12 of 14

Be mindful of reproducibility & sustainability

The importance of packaging
… and of registries
Academic software ≠ poor quality
Community building

Awesome registries

Publication

13 of 14

Useful links

Publications

Funds and other

14 of 14

Questions?