Biomedical Open Source Software: Crucial Packages and Hidden Heroes
This paper utilizes the CZ Software Mentions Dataset to map and analyze the upstream dependencies of biomedical research software across PyPi, CRAN, and Bioconductor ecosystems, identifying critical "hidden hero" packages through centrality metrics to highlight their often-overlooked importance to the scientific community.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine the world of scientific research as a massive, bustling city. In this city, scientists are the architects and builders who design new discoveries. But they don't build with bricks and mortar; they build with software.
For a long time, we've only been looking at the "skyscrapers" of this city—the big, flashy software tools that scientists mention directly in their papers. We know who built the skyscrapers, and we give them awards. But this paper argues that we are ignoring the foundation, the pipes, and the wiring that hold those skyscrapers up. Without them, the whole city would collapse, yet the people who maintain these hidden parts often get no credit, no funding, and no recognition.
Here is a simple breakdown of what the paper does and finds:
1. The "Invisible" Workers
Think of a software package like a recipe.
- The "Visible" Chef: A scientist uses a famous recipe (like
ggplot2orDESeq2) to make a dish (a research paper). Everyone sees the chef and the dish. - The "Hidden" Suppliers: That famous recipe actually relies on a dozen other ingredients: a specific type of flour, a special oven, and a unique measuring cup. These ingredients are other software packages.
- The "Nebraska" Problem: The paper uses a funny reference to a cartoon about a guy in Nebraska maintaining a critical piece of internet infrastructure that nobody knows about. These are the "Nebraska packages." They are the flour and the oven. They are rarely mentioned in the final paper, but without them, the recipe fails. They are the "hidden heroes."
2. How They Mapped the City
The researchers didn't just look at who got mentioned in papers. They built a giant dependency map (a family tree of software).
- They looked at 2.4 million biomedical papers.
- They traced every software package mentioned in those papers.
- Then, they asked: "What does this package need to run?" and "What does that need?" They kept digging down the rabbit hole, layer by layer, to find the deepest, most foundational tools.
They used a mathematical tool called Katz Centrality. Imagine a game of "Six Degrees of Kevin Bacon," but instead of actors, it's software.
- If a piece of software is used by a famous, highly-cited paper, it gets points.
- If a piece of software is used by other software that is also important, it gets even more points.
- This helps them find the tools that are critical to the whole system, even if no one is talking about them directly.
3. The Four Types of Software (The "Stokes" Map)
The authors sorted the software into four groups, like a map of a city:
- The "Pasteur" Packages (The Superstars): These are the famous ones. They are mentioned constantly in papers and they are the foundation for many other tools. Examples:
ggplot2,DESeq2,numpy. Everyone knows them, and they are crucial. - The "Popular" Packages: These are mentioned a lot in papers, but they aren't the foundation for much else. They are the "face" of the research, but not the engine.
- The "Majority" Packages: The boring, small tools that are rarely mentioned and rarely used by other tools. They are the background noise.
- The "Nebraska" Packages (The Hidden Heroes): This is the big discovery. These are tools that are critically important (high centrality) but are rarely mentioned in papers. They are the silent engines.
- Examples found:
vctrs(a tool for handling data types in R),withr(a tool for safely running code), andsetuptools(a tool for packaging Python code). - One specific find was
tifffile, a high-quality tool for handling image files, built by a single person. It's vital for many projects but almost invisible in the literature.
- Examples found:
4. Why This Matters
The paper argues that our current system of rewarding scientists is broken.
- We reward the people who write the "skyscrapers" (the visible tools).
- We ignore the people who maintain the "pipes" (the Nebraska tools).
- The Risk: If these hidden tools break, or if the people who maintain them quit because they aren't funded, the whole scientific city is in danger. It's like the power grid failing because the utility company stopped paying the line workers.
5. The Limitations (The "Fine Print")
The authors are honest that their map isn't perfect:
- Name Confusion: Sometimes software has the same name as other things (like a tool called "TopHat" vs. a hat you wear). The computer sometimes got confused.
- Missing Pieces: They only looked at open-source packages in specific "stores" (like PyPI and CRAN). They missed proprietary software (like Excel) and some very deep, low-level system code (like the Linux kernel) because those are harder to track.
- Time Travel: They looked at the software as it exists today. But software changes. A tool that was crucial 10 years ago might be obsolete now, but the map still shows it as important.
The Bottom Line
This paper is a call to action. It says: "Stop only looking at the tip of the iceberg."
To keep science moving forward, funders and organizations need to recognize and support the "Nebraska packages"—the invisible, foundational software that makes modern research possible. If we don't, we risk the entire scientific infrastructure crumbling from the bottom up.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.