Developing Open Source Tools for Research

Reflections and Learnings from 20 Years with FOSS in Scientific Research

Adam H. Sparks

adamhsparks@gmail.com

Curtin University, Centre for Crop and Disease Management

September 14, 2026

About Me

Dependency - https://xkcd.com/2347/

Corne v4.1 Custom Keyboard

That xkcd comic on the left is called “Dependency” — it shows all of modern digital infrastructure balanced precariously on a tiny block maintained by one person in Nebraska, where I used to live BTW, who’s been thanklessly keeping it going since 2003. I find it relatable because it’s basically my origin story in reverse: he started writing R code to solve his own plant disease epidemiology problems at Kansas State, and somehow that code ended up as part of the infrastructure other researchers depend on, from rice disease modelling at IRRI in the Philippines to wheat pathogen work in Australia.

I’m now a Professor of Biometry and Agricultural Data Analytics at Curtin University, where I lead a team of biometricians, mathemeticians and bioinformaticians in their work on agricultural data science, and reproducible research — and I co-founded Open Plant Pathology with Dr Emerson Del Ponte to build exactly the kind of community that stops science from depending on one person’s lonely block. I am also an associate editor, currently acting as editor in chief, supporting scientific software through rOpenSci.

The keyboard on the right is one of my Corne keyboards, a split, open-source, mechanical keyboard I customised from the switches to the keycaps to the QMK code myself. Also, note that the Catppucin colour scheme I used with the keyboard. I use that palette as much as I can, everywhere I can.

This tells you pretty much everything else you need to know about me: I’m someone who, when given the option between using a thing and understanding and customising the thing, will always choose the latter. I’ve spent lots of time under the hood or in the shop rebuilding engines, carburetors, replacing camshafts, axles, transmissions, rewiring a whole vehicle and more. That instinct is what drives my interest in open-source tools, reproducible methods, and software as scientific infrastructure.

I still find it quite remarkable that code written on my own computer ends up being used by people around the world. I would, however, be very surprised if any of you were familiar with any of my software.

I’m approaching this evening’s topic from two perspectives.

The first is as a scientist working in agricultural data science, epidemiology, and decision support.

The second is as someone who has spent over twenty years using free and open-source software and roughly fifteen years contributing back to it.

Like many people, I started as a user.

I used Linux because it gave me access to tools I couldn’t otherwise afford. I used open-source statistical software because it was flexible, transparent, and reproducible.

Eventually I started contributing bug reports.

Then patches.

Then packages.

Then maintenance.

And that’s when my perspective changed.

Publishing a paper has a relatively clear endpoint. You write it, submit it, revise it, and eventually it appears in the literature.

Maintaining software is different.

People keep using it years later.

Dependencies change.

Operating systems change.

Standards change.

Users discover edge cases you never imagined.

The work never really finishes.

That experience led me to appreciate that many of the systems underpinning modern research are not static outputs. They are ongoing community efforts that require engineering, coordination, governance and maintenance.

Scientific Infrastructure is Also Software

The infrastructure of science has changed

controlled experiments

ground truth + context

scale + simulation

packages + workflows

Setonix Supercomputer at Pawsey Centre

Use this slide to contrast visible, capital-intensive infrastructure with less visible digital infrastructure. The key point is not that software replaces laboratories or field work, but that it has become a dependency layer beneath them. Packages, repositories, build systems, code review and automated testing are now part of how agricultural data science, crop health modelling and reproducible research function day to day.

Open by expanding the audience’s mental model of infrastructure. Acknowledge that laboratories, field stations and supercomputers are still essential, but argue that the everyday software systems researchers depend on now play the same enabling role. The personal frame is important: this is not a generic talk about open source, it is grounded in more than twenty years of agricultural research, plant disease epidemiology, modelling and data analytics, and in about fifteen years of contributing to open-source research software.

When we hear the term scientific infrastructure, most of us picture something tangible. We think about laboratories, field sites, research vessels, glasshouses, sequencing facilities, or large computational resources like Setonix at the Pawsey Supercomputing Centre.

Those things absolutely are scientific infrastructure.

But I would argue that this picture is now incomplete.

A growing proportion of modern science depends on infrastructure that is much less visible. Infrastructure that most researchers interact with every day, often without thinking about it. Software libraries, package repositories, continuous integration services, version control systems, community-maintained codebases, issue trackers, and the people who maintain them.

In many disciplines, including my own work in agriculture and plant health, it’s increasingly difficult to separate the scientific results from the software systems that make those results possible.

What’s interesting is that this infrastructure doesn’t generally belong to a single laboratory or institution. It’s often distributed across universities, government organisations, industry partners, and individual contributors spread around the world.

And unlike a microscope or a supercomputer, this infrastructure evolves continuously.

My goal today is to make the case that open-source software is no longer simply a tool used by science. It has become part of the infrastructure of science itself.

Let me make this idea concrete.

Much of my work involves agricultural surveillance systems, epidemiology, spatial analysis, and decision support for crop production.

In these projects, software isn’t simply generating figures for publication.

The software itself becomes operational infrastructure.

For example, consider resistance surveillance.

We’re collecting data from multiple organisations, standardising those data, processing them through analytical pipelines, generating maps, and potentially providing information back to industry stakeholders who are making management decisions.

The software pipeline becomes part of the operational system.

If the software stops working, the capability effectively disappears.

Similarly, reproducible analytical workflows increasingly depend on package ecosystems rather than individual scripts.

If you use R, you’re already part of this.

Very few analyses depend on a single package.

Instead they depend on networks of packages.

Those packages depend on other packages.

Those packages depend on still more packages.

What emerges is an ecosystem.

And ecosystems are infrastructure.

The same is true in Julia, Python, and many other scientific computing environments.

The result is that scientific capability is increasingly assembled from reusable community-maintained components rather than developed independently by every research group.

This is an enormous strength.

It also creates a shared responsibility.

Because once other researchers depend on your software, you’re no longer simply maintaining a project. You’re supporting infrastructure.

Many researchers are familiar with using open-source software but less familiar with how it is built.

The reality is that most mature projects follow structured engineering practices.

Development is distributed.

Contributors may be spread across multiple countries and time zones.

Most work revolves around version control systems such as Git, just as with the Linux kernel.

Changes are proposed through pull requests.

Those changes undergo review.

Automated tests run.

Documentation is updated.

Only then are changes merged and released.

What’s interesting is how different this is from traditional academic workflows.

Rather than working privately and revealing a result at publication, development is visible throughout the process.

The discussions are visible.

The code history is visible.

The rationale behind decisions is visible.

Anyone can inspect how a feature evolved over time.

The process also scales surprisingly well.

Open-source communities routinely coordinate hundreds or thousands of contributors without requiring everyone to be located within the same organisation.

Many of the ideas researchers encounter today as “modern research software practice” actually emerged from broader open-source communities long before they became common in academia.

Version control.

Code review.

Automated testing.

Continuous integration.

Release management.

These aren’t just software development practices.

They’re mechanisms for building reliable scientific infrastructure.

My path: plant pathology, modelling, software

Twenty years. 5 institutions. Always turning data and code into reusable scientific capability

The through-line across five institutions isn’t a crop or a disease. It’s the same instinct every time: turn data and code into something other people can depend on. That’s what brought me to open source, and that’s what keeps me there.

Open-source work

• Professor of Biometry & Agricultural Data Analytics
• Editor rOpenSci & Tropical Plant Pathology

• 3,109 contributions year to date
• Contributed to 84 repositories
• 3 reviews (editor)
• 2 packages for review

• R and Julia package authoring, maintenance and contributions

• rOpenSci
• AAGI-AUS
• CRAN Task Views (agriculture)
• r-devel

It’s not the scoreboard that matters. It’s the pattern: showing up, building, maintaining, contributing.

It’s not the scoreboard that matters, it’s the pattern. Showing up. Building. Maintaining. Contributing.

The GitHub profile makes invisible maintenance partly visible — but what it actually shows is twenty years of the same instinct: if something is broken, fix it; if something is missing, build it; if something is useful, keep it working.

That’s the through-line across every repository, every review, every PR.

Scientific Research Software and Reproducible Research

Weather and climate data packages became research infrastructure

{GSODR}

global daily weather data (stations)

{nasapower}

global daily weather data (satellite and modelled)

{weatherOz}

Australian weather and climate data

{chirps}

CHIRPS precipitation data

{getCRUCLdata}

CRU CL 2.0 climatology data

{SPIChanges}

improves interpretation of SPI under changing climate

Weather and climate data packages became research infrastructure. This slide links the audience to familiar scientific software: data clients that hide unstable, heterogeneous external data systems behind an R interface. GSODR, nasapower and weatherOz are concrete examples. These are not just utilities for one project. They are infrastructure because other analyses can be built on them, cited, tested and maintained. Emphasise that the package becomes a stable boundary between changing data providers and reproducible research workflows.

• The infrastructure pattern: APIs change, data providers change, user needs change. The package mediates that instability for science.

Science needs reproducible software

Basic Concepts

• {epifitter}: analysis and simulation of plant disease progress curves
• Ecology and epidemiology in R instructional series (~2006)

Epidemic Simulation

• {ascotraceR}: spatiotemporal spread of Ascochyta blight
• {epicrop}: simulation modelling of crop diseases using a SEIR model
• Global potato late blight modelling (dissertation) (2009)

Pathotype Analysis

• {hagis}: pathotype complexity, distribution and diversity
• A rabiei collection dashboard

Science needs reproducible research

Analysis

Aerial spread of smut spores during peanut harvest (Paredes et al. 2024)

Synthesis

Mungbean powdery mildew meta-analysis (Melloy et al. 2021)

Reproducibility

Openness and Computational Reproducibility in Plant Pathology (Sparks et al. 2023)

The recurring question is: can someone else inspect, reuse, extend or challenge the analysis after the paper appears?

Plant disease epidemiology has always involved observation, modelling and uncertainty, but modern workflows also need traceable data and code. The reproducibility paper gives the conceptual foundation, while ascotraceR and hagis are concrete software outputs. The mungbean powdery mildew meta-analysis is a nice example of a study where open computational workflows matter for synthesis and decision support.

At Curtin, software sits inside an applied analytics mission

CBADA Focus

Biometry, statistics, bioinformatics and genetics, spatial analytics and modelling.

AAGI Mission

Use data analytics in grains RD&E to help Australian grain growers be more profitable and globally competitive.

Research Translation

Researcher-facing analytics and grower-facing systems both depend on reusable software.

Use this slide to root the talk in current work. AAGI is a useful example because it is not a software project in the narrow sense. It is an analytics programme serving the grains industry. Yet the mission is impossible without software infrastructure: pipelines, packages, reports, Shiny applications, templates, analysis code and data systems. This is where the audience sees that open-source practice is not separate from applied agricultural impact.

The AAGI stack: an internal distro for agricultural analytics

Like a Linux distro bundles tools around a coherent purpose, AAGI’s software stack standardises how data moves from paddock to report across every project.

{rippo} IPPO register preparation

{AAGIThemes}, {AAGIPalettes}, AAGIQuarto Consistent graphics, tables and reports

{nert}, {fifo} Data retrieval and extraction

Shared components. Replaceable parts. Maintained by the team, not one person.

Think of it as an internal distro: not a monolith, but a set of composable tools with a shared philosophy. The names don’t matter here, what matters is that no single project reinvents the data pipeline, the report template, or the branding. That’s what makes it infrastructure rather than a collection of scripts.

Reproducible on-farm experimentation is a software workflow

R scripts, spatial features, package-based workflows and repeatable setup

Linear mixed models, pseudo-environments and geographically weighted regression

Tables, maps, diagnostics and templates for independent analysis

The method is no longer just “what model did we fit?”

It is “can the whole analytical process be repeated and maintained?”

This example is useful because it is very close to current AAGI practice. The OFE SOP is a practical demonstration of R scripts and workflows for statistical analysis of large strip trials. It emphasises loading, preparation, analysis and reporting using reproducible R code and open-source tools. Use it to argue that reproducibility is not an abstract virtue. It is what lets collaborators conduct independent analysis, compare approaches and maintain analytical standards beyond a single consultant or student.

The stack is polyglot by necessity

Whole Farm Liming Decisions

Monte Carlo model using real farm data for investment decisions

Architecture

Julia interfaces with a .NET API based on an existing decision-support app

Infrastructure

Docker, cloud-hosted workflows and Pawsey/Nimbus context

The point is that real scientific infrastructure is polyglot. R, Julia, Python, .NET, Docker, databases and APIs often coexist because each solves a different part of the system.

That’s where I came from.

Now, what does it mean to build and maintain this infrastructure?

Engineering workflow

How open-source projects actually work

The workflow is a quality system: history, review, tests and release discipline make reuse possible.

This is the generic engineering slide. Explain that mature open-source development is not simply editing code in public. It involves an explicit workflow: problems become issues, changes happen on branches, automated tests and checks run, reviewers discuss maintainability, and releases create stable points for users. Tie back to your GitHub activity and rOpenSci editing: review is not a ceremonial step, it is where quality, maintainability and community norms are negotiated.

Maintenance in practice: one bug report, three root causes

• A macOS user, a server, a missing package
• All hit the same silent failure
• Review kept the fix proportionate

This is a real PR from three weeks ago. One user, one bug report, three completely separate root causes all coexisting silently.

The report was straightforward: on macOS, get_key() couldn’t find a key that was definitely there. What the investigation turned up was more interesting.

Root cause one: the code asked keyring for a keyring named “nert” by name. On macOS, a named keyring is a separate keychain file — not the login keychain. That file locks when the machine sleeps or restarts and demands its own password, not the login password. So a key that was correctly stored in the login keychain was permanently invisible. Not wrong — just unreachable.

Root cause two: on a server or CI runner, the backend holds a single set of credentials and has no concept of named keyrings. Every single call was printing “the keyring argument is ignored.” Not a failure — just noise on every run, which is the kind of thing that trains people to ignore warnings entirely.

Root cause three: keyring is a suggested package, not a hard dependency. If it wasn’t installed, the installation error was caught by the same handler that catches a missing key. The user got “No TERN_API_KEY found.” Totally wrong diagnosis. They went to fix a key they already had.

Two commits to fix it. Commit one: fall back to the default credential store when the named keyring has nothing. Commit two: carry each store’s own error message up to the user instead of collapsing everything to “key absent.”

Then review kept the fix proportionate. The reviewer pushed back on wrapping a single requireNamespace() call in its own function — don’t need a framework for a one-liner. Four NEWS bullet points for what is functionally a small bug fix — cut it down. Documentation that explained too much — shorter. R CMD check: 0 errors, 0 warnings, 0 notes.

The three things the diagram shows at the bottom are the ones worth taking away. Users surface problems that tests and CI never anticipated — the macOS keychain behaviour was perfectly correct, it just wasn’t what the code expected. One symptom produced three distinct root causes, all quietly coexisting. And review kept the fix proportionate — not every problem needs a new abstraction.

That last point is where open review earns its place. The temptation when you find three root causes is to build something general. Review said: fix what’s broken, ship it clean.

The Peer Review Process

Academic peer review	Open-source engineering review
Evaluates claims	Evaluates implementation
Usually pre-publication	Continuous through issues, PRs and releases
Often anonymous and hidden	Often public and inspectable
Publication can be an endpoint	Maintenance begins after release

Traditional process

Open process

The point isn’t that one form of review is better — they’re optimised for different questions. Academic review asks whether a claim is supported. Engineering review asks whether a change can safely become part of a shared system. For research software, both matter, and the open-source version has been running continuously for decades without most researchers noticing.

The project is bigger than its authors

• The project is bigger than its authors.
• Contributors span institutions, disciplines and career stages
• Credit, authorship and review become governance questions
• Open code creates paths for reuse, teaching and contribution
• Long-lived projects need maintainers, not just founders
• Distributed development is not a side effect. It is the operating model.

Examples, rOpenSci bomrang/weatherOz, OPP hagis, AAGI nert

Credit and authorship are part of maintenance culture, not an afterthought.

Maintenance is where infrastructure survives or disappears

Dependencies

Security + Privacy

Users

Documentation

Landslide, Mountain Province, PHL, Adam Sparks 2011

• Dependencies - APIs, packages, operating systems and authentication change
• Security + Privacy - Data access, credential handling and deidentification become design concerns.
• Users - Bug reports, teaching use, support requests and edge cases appear
• Documentation - Examples, vignettes and onboarding need care

This slide should be practical and slightly candid. You can say: a successful package creates future work. Users find edge cases; APIs require authentication; dependencies change; documentation gets stale. The recent nert GitHub activity is a useful live example, including work around API keys and keyring. The argument is that maintenance is not cleanup after scholarship. It is scholarship’s durability mechanism.

If I had to identify the biggest challenge facing research software, it would be maintenance.

Not development.

Maintenance.

Many grants reward creating something new.

Few incentives exist for keeping something useful.

Yet maintenance is where infrastructure lives or dies.

Dependencies need updating.

Documentation needs improvement.

Security vulnerabilities appear.

Operating systems change.

Users ask questions.

Bugs need fixing.

This isn’t glamorous work.

It’s rarely publishable work.

But it’s often the work that determines whether a tool remains useful five years later.

Many research software projects effectively disappear once a student graduates or funding ends.

Others become long-lived infrastructure because somebody keeps investing effort into maintenance.

The irony is that maintenance often contributes more long-term value than the original development.

Yet maintenance remains one of the least recognised forms of scholarly contribution.

A publication can have an endpoint

Infrastructure cannot.

Academia vs. Business — xkcd.com/664

The invisible work determines whether infrastructure survives

Funding

Who pays for maintenance when the grant ends?

Governance

Who decides what the project becomes?

Maintenance

Who fixes the issue three years later?

Community

Who keeps contributing when incentives change?

This is the heart of the abstract’s final paragraph. Stress that good code is necessary but not sufficient. A project persists when funding, governance, maintenance labour and community contribution align. Link this to AAGI as a partnership model with formal governance, and to rOpenSci as a community review model. In both cases, the infrastructure depends on people and institutions as much as technology.

The final topic I’d like to discuss is sustainability.

We often focus on technical quality.

But technical quality alone isn’t enough.

The projects that survive tend to develop governance structures.

They define how decisions are made.

They establish community norms.

They attract contributors.

They create pathways for future maintainers.

Funding is another challenge.

Most research funding models prioritise innovation.

Infrastructure requires continuity.

Those are not always the same thing.

We have well-established funding mechanisms for physical infrastructure.

We understand why laboratories need ongoing support.

We’re still figuring out how to treat software infrastructure in the same way.

The Linux ecosystem provides one model.

The R ecosystem provides another.

Different governance approaches exist.

But all successful examples recognise the same basic truth: sustainability depends as much on people and institutions as it does on technology.

Sustainability is not a technical property

It is a social, financial and institutional arrangement

2016 rOpenSci Unconf, Brisbane, Qld, courtesy of Jessie Roberts, Miles McBain, Nicholas Tierney

Recognition

What changes if institutions treat software as infrastructure?

Universities, government agencies, research bodies — the problem is the same.

CVs

Research assessments

Infrastructure funding

Promotion systems

This isn’t just a university problem. State government has the same issue in a different wrapper.

I’ve seen it from both sides. In government, the software that runs operational systems — surveillance pipelines, decision support tools, analytical workflows — is invisible in performance reviews. What gets counted is publications, project delivery, stakeholder reports. The code that makes all of that possible doesn’t appear on any form.

In universities it’s the same instinct dressed differently: papers count, grants count, software doesn’t — unless there’s a paper about the software, which is a workaround, not a solution.

The question on this slide — what changes if institutions treat software as infrastructure — applies equally to DPIRD, to CSIRO, to any government research body. The promotion and recognition systems weren’t designed with research software engineers in mind, and they haven’t caught up.

The difference is that in government you often can’t even publish the software, so the workaround isn’t available either.

If other researchers depend on it, it is not just an output

It is infrastructure

Who maintains the block your infrastructure stands on?

Infrastructure is defined not by what it’s made of, but by whether others depend on it. Modern science increasingly depends on open-source software.

Three words: open, distributed, maintained.

Close with the xkcd callback — the question on the slide is the question for the room. Then take discussion.

Reserve discussion prompts if needed: governance, funding, recognition, what agricultural research can learn from Linux and rOpenSci.

Adam H Sparks

Professor of Biometry and Agricultural Data Analytics
Centre for Crop and Disease Management
Curtin University

https://adamhsparks.netlify.app

https://foss-scientific-infrastructure.netlify.app/