Why academic bioinformatics software struggles to survive
Lee Katz, Andrew Page and Nabil-Fareed Alikhan discuss why academic bioinformatics software often loses support when a grant ends or its developer moves on. Drawing on their own projects, they contrast short-lived tools with sustained resources such as SAMtools, BLAST and Galaxy. They examine the work behind maintenance, the difference between a research prototype and reusable software, and how contributor credit might encourage community support.
Listen to Episode 24: Experimental projects lead to experimental software on SoundCloud
In this episode
Software tied to short-term employment
The hosts describe an academic development model in which software is a project for a PhD student or postdoctoral researcher, backed by short-term funding. They estimate a typical lifespan of three to five years, matching the grant or contract rather than the period for which users might need the tool. Publishing the software paper can be treated as the finish line, even though supporting users creates continuing work.
Andrew describes moving institution and leaving colleagues to handle bug reports and feature requests for his earlier software. He questions whether developers should be expected to maintain a previous employer’s tools, unpaid, during evenings and weekends. The problem is not simply a lack of goodwill: maintenance needs time that someone is funded to provide.
Databases and web servers need continuing care
Nabil draws on his work with EnteroBase to discuss the maintenance behind MLST databases. Reference laboratories depend on consistent schemes, and somebody must review the sequence types and alleles entering those databases. Yet this can be a service provided for free, with projects moving between grants and repeatedly finding a fresh research angle to support routine work.
Lee recalls a meningococcal MLST web server developed during his PhD with colleagues at CDC and Georgia Tech. It went offline after roughly five or ten years, when he had moved on and nobody remained to maintain it. He says its successor was better sustained. The hosts also stress that security updates, internal libraries, programming-language changes and user queries create work even when no new features are being added.
What sustained projects have behind them
Andrew presents SAMtools as a successful example, pointing to its development team, open-source approach, engagement with the community and multiple institutions, and long-term funding. Lee adds BLAST as a well-maintained, well-documented tool supported by government rather than a conventional academic project.
Galaxy illustrates another route: a substantial community working on a shared web-based workflow system instead of repeatedly building separate alternatives. The discussion identifies grants from different institutions and places, including the US, EU and Germany, as part of that support. FastQC is also mentioned as a long-standing tool. However, the hosts caution that many research niches cannot support such a large community, pointing to their impression of how few people had worked on coronavirus genomics before it attracted wider attention.
Funding maintenance instead of novelty
The hosts discuss BBSRC’s annual tools and resources call as an example of funding intended to keep important software and databases going, rather than only supporting something new. Andrew reports hearing that it is heavily oversubscribed. Nabil adds that some funding pots have restrictions favouring capital equipment, when the actual need is staff time.
They describe ways researchers try to fit maintenance into novelty-driven funding: rebranding a tool, adding a version number or buzzword, moving it to the cloud, or changing its application from bacteria to yeast to viruses. Moving from a desktop application to the web or a phone becomes another possible story. Their criticism is that continued support can depend on persuasive repackaging rather than the value of maintaining a useful resource.
A research prototype is not a finished product
The hosts distinguish experimenting with methods from producing software suitable for widespread use. Nabil argues that much academic software is effectively a prototype. Examples discussed include hard-coded folder paths and scripts that work only in the developer’s own environment. Time spent building a tool does not, by itself, establish its usefulness or readiness for publication.
At the same time, they recognise the educational value of taking apart an assembler and trying changes. The difficulty is presenting that exercise as a polished tool for other people. Publication remains a major route to recognition, so students and researchers have an incentive to produce a software paper even when the resulting package has no realistic maintenance plan.
Credit as an incentive for community support
Lee argues for acknowledging contributors generously: recognise people who make commits, and offer authorship for significant contributions. His reasoning is that community support is more likely when people receive credit for their work, and that support may improve a project’s sustainability.
Nabil describes a complication when a paper combines experimental science with software development. Someone may contribute to the software without participating in the scientific component. He suggests listing a community or development group as an author, with individual contributors identified in a footnote, as one way to recognise different contributions. The episode closes by linking experimental projects, absent maintenance plans and unstructured software to the difficulty of a community taking over. More detailed strategies for improvement are left for a later discussion.
Highlights
- 00:01:14 — Short-term grants and contracts shape the lifespan of academic software.
- 00:02:56 — Andrew describes moving institution and leaving software support behind.
- 00:03:38 — EnteroBase and MLST illustrate the funding problem for database maintenance.
- 00:05:01 — Lee recalls a meningococcal MLST web server that went offline after he moved on.
- 00:07:14 — SAMtools provides an example of sustained support through a team and long-term funding.
- 00:08:36 — BLAST is highlighted as well-maintained, government-funded software.
- 00:09:07 — Galaxy shows the value of a large community and funding across institutions.
- 00:10:44 — BBSRC’s tools and resources call supports existing software and databases.
- 00:13:03 — Research prototypes are distinguished from software ready for wider use.
- 00:16:20 — Lee argues that contributor credit can encourage community support.
- 00:17:24 — Development-group authorship is proposed as a way to acknowledge software contributors.
In their own words
It costs you nothing, really, to give credit to somebody.
— Lee Katz, 00:16:20
Who is talking
- Lee Katz (host)
- Andrew Page (host)
- Nabil-Fareed Alikhan (host)
Tools and resources mentioned
EnteroBase, MLST, SAMtools, BLAST, Galaxy, FastQC.
Questions this episode answers
How long does academic bioinformatics software typically remain supported?
The hosts estimate about three to five years, matching the lifespan of a grant or a developer’s contract. They describe support ending when students graduate, researchers move institution or funding priorities change.
Which bioinformatics tools are discussed as examples of sustained support?
The hosts highlight SAMtools, BLAST, Galaxy and FastQC. They connect SAMtools with a funded team and community engagement, BLAST with government support, and Galaxy with a large community and grants across institutions.
Why do MLST databases need ongoing maintenance?
The discussion explains that reference laboratories need consistent schemes, with sequence types and alleles reviewed as they enter the databases. Using EnteroBase as an example, Nabil describes the difficulty of funding this continuing service through successive research grants.
How can software projects recognise contributors and encourage support?
Lee recommends acknowledging commits and offering authorship for significant contributions. Nabil suggests development-group authorship with a contributor list as one option when software contributors were not involved in a paper’s experimental science.
This page was written from a machine transcript of the episode and checked against it. Listen to the episode for the whole conversation.
Show notes
Experimental projects lead to experimental software. We discuss the issues around the sustainability of academic bioinformatics software. How it currently works, why software dies, quality issues, and what we can do to keep it going.