Building software to support researchers

The “static paper” era is ending. For decades, science lived in the PDF—a flat, unchangeable report that described an experiment but couldn’t actually run it.

For Esha Nasir, a PhD candidate and Research Software Engineer (RSE), that model is obsolete. In her field of computational pathology, researchers analyze complex, multi-layered tissue images to hunt for disease biomarkers. Here, a traditional paper is just a snapshot; the real science lives in the code used to process those massive data sets.

Under the guidance of her supervisor, Dr. Shan Raza, Nasir realized that software is more than just a tool—it’s a vital piece of social and scientific infrastructure.

Today, she is helping lead the shift from science-as-a-story to science-as-software. In this new landscape, the code isn’t just supporting the research; it is the research. If you can’t see the code, you can’t verify the science. As our newest Ambassador, she isn’t just finishing a degree; she’s building the foundation for a more transparent, executable future.

Here, algorithms and software systems are not merely auxiliary tools that support analysis; they’re often the main mechanism through which scientific insights are generated. The quality of a cancer diagnosis or a treatment recommendation can hinge on the robustness and efficiency of the code developed to process histopathology slides. Despite this centrality, the academic reward system has historically lagged, prioritizing the quantity of publications over the quality, maintainability, and reuse of the software that underpins them. This disconnect creates a significant gap between the practical necessity of high-quality code and its academic recognition. The emergence of dedicated Research Software Engineer roles is a vital step toward bridging this divide, embedding robust engineering practices into research workflows, and elevating the visibility of software as a legitimate scholarly contribution.

The biggest misconception in research is that “open source” just means hitting the upload button. Simply putting code in a repository doesn’t make it open. If it lacks documentation or a clear list of dependencies, it’s effectively a black box. It might be public, but it’s still unusable.

Without structure, “open” code is just as impenetrable as closed, proprietary software. To have real scientific value, code needs to be more than just available; it has to be reproducible. Her work focuses on bridging that gap—ensuring that research software is built to be used, not just seen. True open source isn’t a “set it and forget it” release; it’s a long-term commitment to maintenance and community support.

There’s also a risky assumption that open source means low effort. In reality, creating high-quality research software requires intense engineering discipline. Without rigorous testing and thoughtful design, code can’t survive the transition from a single lab to the global scientific community. For Nasir, “open” is a standard of quality, not a lack of formality.

As software gains status as a legitimate research output, Nasir’s biggest surprise was discovering just how much critical infrastructure rests on the shoulders of volunteers. Seeing both the fragility and the resilience of that system is exactly what drove her to support Software Heritage.

For doctoral students and early-career researchers who aspire to achieve computational reproducibility but may lack a strong background in software engineering, the path forward can seem daunting. Nasir recommends treating reproducibility as a gradual process rather than an immediate, perfectible goal. The most effective starting points involve adopting foundational tools early in the research lifecycle. This includes using version control systems like Git from day one to track changes, writing clear documentation—particularly README files that explain how to run the code—and structuring analyses into reproducible scripts rather than relying solely on interactive notebook steps. Additionally, managing environments using tools like Conda or virtual environments ensures that the software runs consistently across different machines. As an RSE, Nasir often encourages researchers to think in terms of incremental improvement; each project should aim to be more reproducible than the last, fostering a culture of continuous refinement rather than demanding perfection from the outset.

At the University of Warwick’s Centre for Interdisciplinary Methodologies (CIM), the demand for this kind of expertise is surging. Nasir’s day-to-day involves helping researchers across different fields build and debug data pipelines, implement machine learning, and structure their code for teamwork. Much of her work is focused on making research code scalable and easier to maintain, particularly for complex datasets in imaging and biology. Increasingly, she’s also focused on the ethical integration of AI—ensuring these tools are used effectively without compromising research integrity.

The University is getting ahead of these shifts. By establishing open research and data management policies, the university actively encourages transparency and responsible sharing. These guidelines aren’t one-size-fits-all; they respect the nuances of different fields while ensuring that software is treated as a core pillar of open science. Crucially, institutional support from libraries and research services helps scientists meet funder requirements and adopt these new standards in their daily work.

For Nasir, the RSE is the missing link.

A great RSE doesn’t just write code; they bridge the gap between abstract scientific inquiry and hard-nosed engineering. It’s a role that requires a specific “translation” skill set—taking complex technical architecture and making it make sense to non-developers, all while maintaining a fanatical focus on reproducibility.

When Nasir first stepped into the world of open source, it wasn’t the code that struck her—it was the scale. She found a global, interdisciplinary engine fueled by researchers, engineers, policymakers, and activists. It’s a community where knowledge doesn’t just sit; it spreads at light speed because the barriers to sharing have been torn down.

At their core, RSEs need more than just technical chops—they need a genuine curiosity about the science itself. The goal isn’t just to write code, but to solve the problem.

The best RSEs strip away the technical friction, making complex methods so reliable and usable that researchers can stop wrestling with the tools and start focusing on the discovery. By treating software as a legitimate academic output and fostering a culture of open, reproducible work, we don’t just organize data—we accelerate breakthroughs in fields as critical as cancer research.

Software Heritage Ambassadors are volunteers who offer expert advice in various sectors and languages on how to use our services. Here’s more information on how to book one for a free consultation.

If you’d like to connect with Esha Nasir, please reach out via LinkedIn.

We’re also seeking passionate individuals and organizations to volunteer as ambassadors and help grow the Software Heritage community. If you’re interested in becoming an Ambassador, please share a bit about yourself and your connection to the Software Heritage mission.