When I first started publishing geospatial code, I was not thinking about scale. I was thinking about friction. Too much hydrologic and geospatial research still depends on scripts that live on one laptop, workflows that only make sense to the person who wrote them, or figures in papers that no one can actually reproduce.

That is why I build open-source geospatial tools. I want the work to leave the lab. I want it to be installable, documented, reusable, and good enough that someone outside my immediate research group can apply it to a real problem.

By May 2026, that commitment has grown into a broader open-science ecosystem: FIMserv, FIMeval, msfootprint, RiverJoin, FIMbench, and the newer FIMbox testbed, along with public datasets and documentation that support flood forecasting, evaluation, hydrography integration, and geospatial decision support.

The Problem with Closed Research Tools

Academic research is often built on a paradox: we publish methods that cannot be reproduced because the code, data preparation logic, and operational assumptions are never released. A paper might describe a flood workflow in detail, but if the implementation is hidden, other researchers are left with a description rather than a usable method.

That is especially costly in geospatial water science. Flood forecasting, hydrography integration, and remote-sensing workflows are already complex. If the software is closed, the science becomes harder to validate, harder to extend, and nearly impossible to move into practice.

"A method that can't be reproduced is a method that can only be trusted by its authors."

What Open Source Looks Like in My Work

From the beginning of graduate school, I treated open source as a design principle rather than a final cleanup step. In practice, that means:

  • Code hosted on GitHub with clear README files and installation instructions.
  • Packages published on PyPI so anyone can install them with a single pip install command.
  • Documentation hosted on CIROH's developer portal with tutorials and usage examples.
  • Datasets deposited on Zenodo or HydroShare with permanent DOIs for citation.

That approach matters because open science is not just about code availability. It is also about usability. A public repository without packaging, examples, or documentation is still a barrier for most users.

"The purpose of science is to improve the world — and that's hard to do when the tools stay inside the university."

What Has Happened Since

The most meaningful change since I first wrote this post is that the tools are no longer just personal or lab utilities. They are now part of a wider workflow used by researchers, collaborators, and operationally minded users.

FIMserv has grown into a widely used open framework for generating flood inundation maps with NOAA's OWP HAND-FIM foundation, and its documentation is now publicly available through CIROH. FIMeval provides a reproducible evaluation framework tied to extensive benchmark databases. FIMbench adds a structured benchmark environment and web-access layer for comparative flood-model analysis. RiverJoin supports hydrofabric translation and bidirectional attribute transfer, while msfootprint makes global building-footprint extraction more accessible for local disaster and exposure studies.

Across those packages, the current portfolio now reflects more than 70,000 cumulative downloads. That number matters less as a vanity metric than as evidence that the tools are useful beyond the project that originally motivated them.

Why This Feels Different Now

What makes open source exciting to me is not just visibility. It is the shift from isolated research output to reusable scientific infrastructure. Once a tool is public, someone else can test it, improve it, adapt it to a different watershed, compare it to a different model, or integrate it into a workflow I never anticipated.

That is already happening. CIROH now hosts public documentation for the community flood-inundation tools and benchmark workflows. In August 2025, Yahoo News covered FIMserv as a breakthrough flood forecasting tool. In September 2025, the Alabama Water Institute highlighted the new satellite-derived river slope database and the open-source spatial joining workflow behind that integration. Those are not just media moments. They are signs that open work is becoming operationally legible.

Open Source Is Also About Accountability

Publishing code changes the standard you hold yourself to. When a tool is public, people can see your assumptions, your interfaces, your naming decisions, your edge cases, and your documentation quality. That can be uncomfortable, but it is healthy. It pushes research software closer to engineering discipline without losing scientific curiosity.

It also makes collaboration easier. Open repositories lower the barrier for students, collaborators, and agencies to contribute fixes, ask questions, and reuse parts of a workflow without starting from zero.

A Note for Early-Career Researchers

If you are a student or early-career researcher, publish your code before it feels perfectly polished. A documented, usable tool that helps even a small number of people is more valuable than a nearly perfect workflow that never leaves your machine.

Start with GitHub. Write a README. Add installation instructions. Choose a license. Package what you can. If you create data, give it a stable home with a citation path. Especially in geospatial science and in parts of the world where proprietary software remains a real barrier, open tools are not just convenient. They are part of scientific access.

Explore the work: Start with FIMserv, FIMeval, RiverJoin, and msfootprint, then follow the documentation and linked datasets from there.