The perks and pains of open-source software

If you work in research, chances are you have used open-source software (OSS) before – software whose source code is available for you to read and play with. You might not know it, you might not care, but very likely that is the case. Have you ever used Zotero to manage your references? Or OpenOffice to write a paper? Or LaTeX? Have you ever created a program in Python or R? Besides, do you have an Android phone? Then, you do use open-source software.

In research, things get more interesting: we are not just OSS consumers, we are also creators. It is relatively common that researchers need to write their own little scripts – or more sophisticated programs – to analyse their data, run some calculations, or automate some analysis. Typically, there are four things that might end up happening to that software:

1. The software fades and dies in a forgotten hard drive once it has served its purpose.
2. The software is indeed useful and grows organically, with multiple (and very often) incompatible versions shared between researchers and collaborators privately.
3. The software is released as open-source, with proper documentation, versions, and (hopefully) a thriving community of users and developers.
4. The software is commercialised, maybe as part of a spin-out, or licensed to a bigger company that maintains it and keeps developing it, for a fee.

There are pros and cons on all these options – well, I honestly do not think there are pros in case (2) – but here I will focus on the outcomes of case (3): open sourcing your software.

As enthusiastic as I am about OSS – in fact, at my team at Imperial [1], we are all very enthusiastic about it! – this is a step that must not be taken lightly. Not everything is a bed of roses, and you should learn the pros and cons applied to your specific case before taking that decision. Here, I list a few things to consider, in no particular order, when releasing software as open source:

1. You might not have a choice but to release your software as OSS. There are two main reasons for this to happen. On the one hand, some funding bodies mandate that any software developed with their funds has to be released as open source as part of the global movement toward open science, open research, and reproducibility (keep an eye on the small print!). On the other hand, your software might depend on licences that require you to release your own code – a “derivative work”, as it is known – with the same type of licence (again, keep an eye on the small print!).
2. Open sourcing your software, and maintaining it in good shape, takes effort. My view – and it is totally debatable – is that open source is more than just putting your code out there available for everyone. Open source also involves the will to take care of your code, ensure its sustainability, and provide (within reason) support to those who need it to install or use it. As you can imagine, these tasks demand a substantial amount of your time, but they ensure your code is well maintained and up to date while supporting the community of users.
3. Creating a community of users and developers is key, but also takes effort. Having a community of users and – specially – developers with whom to share the workload of developing the software is the dream of any OSS, but that is hard work. Not only the software needs to solve the needs of many users (which is often difficult in some niche fields of research), but you need to reach out and engage with that community until it is self-sustainable.
4. Open sourcing your tools is not incompatible with commercialisation: it might even be desirable. There are several business models to make this work [2], being the most common one to charge for providing support, training, or custom features. Creating a community takes effort – and therefore time and money – so, to be sustainable, some income from those who benefit from the software (in contraposition to research funding bodies) is a perfectly reasonable request, especially in niche areas.
5. By creating a community of users, you can increase the impact of your research. When someone not only can read your paper, but have the opportunity to use the software you have developed and discussed in that paper, you increase the impact of your work. And you know how this goes: a higher impact leads to more citations, more opportunities for collaboration, and more chances of getting known in the field [3]. If you are in research and do not understand this, then I give up!
6. A community around OSS increases the quality and capabilities of the software itself. It is not just you, or other people in your same orbit, the ones who have to find and fix bugs, think and code new features, test them, etc. It is a whole cohort of stakeholders (potentially worldwide) with a range of use cases, skills, and knowledge the ones working on developing the software. Let’s not get it wrong: to make this work, a lot of coordination and having a clear roadmap and a strategy are required. If these points are met, you can gain much more with less effort! It is not by chance (or altruism) that big tech companies like Facebook or Google make big chunks of their products open source: they gain thousands of willing developers volunteering their time to make those products better for the benefit of everyone, so it is a win-win situation.
7. Working on OSS is fun and satisfactory. It is very fulfilling to know that you are contributing to something bigger than your own private research with such a clear and immediate impact. You work with others in distant places and learn new skills almost without noticing. And there are plenty of opportunities out there too. October is Hacktoberfest [4]: a celebration of OSS, a vehicle for creating and promoting communities and good quality tools. If you have some code that needs to see the light, now is the time to put it out there and exploit the momentum of such a wonderful community!

There are many other aspects that you should consider – I have not even mentioned the different types of open-source licences! – but, if you need to take home only one message, it should be this one: successful OSS requires a community of users and developers around it, so be prepared to invest in it if you want to make the most out of your open-source tool.

By Diego Alonso Álvarez (@[email protected]), Research Software Engineer Team Lead, RCS-ICT, Imperial College London.

More information:

1. Imperial College London, 2022, Research Software Engineer team. See how to contact them here.
2. Business Models for Open-Source Software. Source: Wikipedia. Available online here.
3. Making Research Software Open and Shareable (2022). Source: Imperial College London. Available online here.
4. Hacktoberfest (2022). Available online here.