Software is inherently dynamic; it cannot be written once and expected to remain unchanged indefinitely, especially if it’s to remain functional over time. Dependencies evolve, programming languages advance, bugs are discovered, and new features are often required. This fundamental characteristic of software introduces one of the most significant challenges scientific software confronts: maintenance.
Software developed within the scientific ecosystem typically arises from either (i) the intrinsic motivation of its contributors or (ii) external funding support (ref). In both scenarios, the sustainability of the software is jeopardized once the contributors’ interest shrinks or the funding ceases. And this phenomenon has been documented to occur relatively quickly (ref).
Efforts to preserve valuable research processes and results have increasingly centered on the FAIR principles —Findable, Accessible, Interoperable, and Reusable— along with Open Access initiatives and comprehensive workflow documentation (ref). In particular, the FAIR Principles for Research Software (FAIR4RS) were published in 2022 to enhance the sharing and reuse of research software (ref).
Despite these efforts, a critical question remains: How can we ensure that the software being produced, and tentatively preserved for posterity through Open Access initiatives, is well-written, or at least sufficiently robust to be useful for future users? Alternatively, how can scientists, already burdened with demanding schedules, find the time to pursue a degree in computer science to ensure that their software adheres to the latest standards and practices?
As a result of these complexities, many scientists learn to code through peer collaboration and self-study, rather than from formal education and training (ref).
Furthermore, survey data reveal (concerning?) trends: only half of the surveyed postdocs reported receiving formal software development training, while 75% of NSF-funded researchers indicated they lacked time for such training. Also, only about half of scientists possess a foundational understanding of testing, and teams can “waste” up to 25% of their development time on maintenance due to technical debt, among other issues (ref).
But worry not! New students are likely to be better prepared with each successive generation as they confront these challenges. However, this process requires time. In the interim, we could devise two pragmatic approaches:
- Scientists should collaborate with software advisors as a support to enhance their codes.
- Scientists should foster greater integration into collaborative practices, recognize the advantages of free software, and appreciate that each hour invested today in optimizing code will yield significant time savings in the future.
However, free software (as in freedom, not necessarily as in money) mustn’t be confused with open-source (ref). Making the source code visible, but failing to provide power to the contributors, will always result in zero collaboration. On the other hand, free software could bring into play advantages like sharing expenses and resources with other contributors on building, maintaining, and adding features to the software.
Collaboration in open source works because the collaborators, all representatives of different institutions, are incentivized to work together for mutual profit. No one is incentivized to work for you, for free, for your own exclusive profit.
— Drew DeVault
Leave a Reply