Skip to main content

Open Science for Safe Water:
Building an Open Source Low-Cost Fluoride Detector

Within PathOS we are collecting stories on how Open Science (Open Access to publications, Open/FAIR data and software, collaborations with citizens) has made a positive or negative impact. Our ultimate aim is to highlight stories of Open Science practices and how these are linked to impactful outcomes. In this way, we hope to foster a learning experience and to inspire others to follow. Join us and read the first Open Science stories!

Could you briefly introduce yourself and what your Open Science story is about, including its time (e.g. year range) and location?

I am Eugenio H. Otal. I hold a B.Sc. and M.Sc. in Chemistry and a Ph.D. in Physics, and I have a stubborn passion for electronics and prototyping. I am an assistant professor at Shinshu University in Nagano, Japan.

This story began in 2019, when I visited Japan and pitched a simple idea: build a portable, open-source fluoride sensor for water quality. The road from idea to tool was anything but straight. I chose one sensing chemistry, then replaced it with another. I built the electronics, tore them down, and rebuilt them. I moved from quick breadboards to cleaner PCBs, redesigned the enclosure for real-world use, and wrote the scripts more times than I care to admit. I even learned enough mobile development to make the device speak to a phone. Some of this journey appears in manuscripts; much more lives in the hundreds of prototypes I retired along the way to a sturdier, easier-to-use design.

"What kept me going was a clear purpose: give communities a low-cost way to tell safe water from unsafe water right now, while large infrastructure projects catch up. Open designs, open data, and relentless iteration turned that purpose into a tool people can actually use."

What was the context or background in which this Open Science practice was used? What were the goals or expected outcomes?

Across parts of Africa, including sections of the west coast and especially along the East African Rift, fluoride in drinking water is a geogenic problem. It originates from local rocks and volcanic or geothermal systems, so concentrations can change sharply over short distances. In some communities, one well can exceed the WHO guideline of 1.5 mg/L while a nearby spring is safe, making the situation highly inhomogeneous and impossible to judge without testing. Excess fluoride in drinking water causes fluorosis. In children, long-term exposure during tooth development leads to dental fluorosis, seen as enamel mottling and discoloration. With higher or prolonged exposure, people can develop skeletal fluorosis, characterized by bone and joint pain, stiffness, reduced mobility, and in severe cases disabling deformities. It is rarely fatal, but it clearly reduces quality of life and forces households to spend time and money on care and treatment.

At the same time, population growth is outpacing water infrastructure in rapidly urbanizing and peri-urban areas, leaving many people without safely managed drinking water while systems struggle to catch up.

My goal is to provide an intermediate, Open Source tool that helps communities distinguish safe from unsafe sources now by testing each source and sharing results, while longer-term solutions (piped supply, centralized treatment) are planned and built. This is exactly what my Open Science Arduino fluoride detector is for: to put a simple, replicable test in the hands of rural populations where hotspots and safe points can coexist within walking distance, and to make results openly available to guide households, NGOs, and policymakers. As WHO stresses, modelling cannot substitute for actual water-quality testing; source-by-source checks are essential.

What was your role or relationship to this Open Science practice? Were you a direct participant, an observer, or something else?

I was on the front line of the project. That sounds glamorous, but in practice it meant acting as both translator and air-traffic controller between electronic engineers, industrial designers, and firmware and app developers. Getting function and form to meet is hard work.

Day-to-day, I wrote short design briefs, set non-negotiable requirements, and mapped user flows. Tradeoffs were constant. For example, a beautiful curved shell can block the USB-C port. I iterated in fast loops: breadboard, PCB rev A, 3D print, feedback, rev B. I kept a decision log so we could explain every change. When a stylish idea fought a reliability rule, reliability won. When form could improve function (better grip, faster vial loading), I took it.

In short, merging functionality and appearance is not a slogan. It is a disciplined process of setting sharp constraints, testing ruthlessly, and communicating across disciplines until the device that looks right is also the device that works right. That is the work I led on the front line.

How was this Open Science practice implemented, to your knowledge? Who were the key actors involved?

It is not rocket science. Every journal allows Open Access supplementary information. That is where we should place the sample-holder design, circuit diagrams, wiring maps, script code, calibration scripts, and raw data. GitHub exists to host long code, track versions, and manage issues. We talk about Open Science, but it is only truly "open" when others can reproduce it. A glossy PDF without clear details is not Open Science; it is marketing.

I am critical of a common pattern across science: papers that describe a synthesis, a characterization, or an analysis but omit the details needed for reproduction. Methods skip exact reagents and catalog numbers, instrument models and firmware revisions, calibration procedures, data-cleaning rules, and the full code that generated each figure. Without these elements, a skilled reader cannot rerun the analysis, rebuild the apparatus, or diagnose discrepancies. Pretty plots are not science; methods that let others independently reproduce the result are. If a diligent reader cannot replicate the work from the paper and its supplements alone, it is not Open Science. And there is a sad truth: too often the bibliography is treated as decoration, not as a roadmap to replication.

Were there any quantifiable outcomes or measurable successes linked to this practice? What metrics or indicators were used to evaluate these outcomes, if any?

Although this tool targets rural Africa, where many households live on about USD 1 per day, they typically do not have access to a 3D printer or even a basic laboratory. The path to scale is not altruism but a lean, local business model.

The real solution sits with small private groups and regional companies that want to improve their communities while earning a fair, transparent return. By keeping the design open and the bill of materials low, micro-entrepreneurs can assemble units locally, sell them through clinics, pharmacies, and schools, and fund training, maintenance, and spare parts.

The addressable market is large, on the order of 170 million people, so even a few cents of profit per device, amplified by volume and low-cost consumables, can sustain the ecosystem. The point is to align incentives: let impact and revenue reinforce each other, create local jobs, and keep prices within reach of households that need safer water now.

What impacts, both expected and unexpected, did this practice have? Were there any surprising developments or results?

From head-to-head tests and teardown comparisons, I found that my device is simpler to operate (no battery, phone readout), packs more functions (guided calibration, data logging, GPS tagging, offline queue), and is roughly 20x cheaper to build than comparable commercial kits. Many incumbents serve small, captive niches: they ship closed boxes, tie users to proprietary consumables, and optimize for service contracts, not broad access. With stable margins and a predictable customer list, they have little incentive to redesign for cost, let alone reach new users at the edge of the network.

What challenges were associated with this practice, from your perspective? What lessons can be drawn from its implementation?

Here is the not-so-secret truth: there is a canyon between idea and implementation. Companies look at a low-cost, open hardware water tool and cannot wedge it into their verticals, so they pass. Demo days often reward fashion over function; I once lost to a 3D printer for cookies. Apparently 170 million people without safe water cannot compete with warm pastries for breakfast in Manhattan. Then comes the startup paradox: deliver world-class science and a flawless business plan on day one, playing both CTO and CEO while incumbents have whole departments.

As my father says, experience is the brush life gives you when you start going bald. So keep going: learn to write the plan, run the numbers, watch the tutorials, find local partners, document results, and move forward. The cookies can wait; people need water.

How do you perceive this practice’s influence on the wider scientific community or society? Has it affected your own views or approaches to research?

I met with local governments. A few are willing; that is enough.

I trust reason and audit every decision. I keep a ledger of facts; what does not balance is cut. Each morning I allow one irrational indulgence: hope. Not the idle kind, the active kind—a wager that effort can bend outcomes. I meet the day, pick up the plan, and move the next stone. The results judge me; I welcome the verdict.

Based on your experience or observation, would you recommend this Open Science practice to others? Why or why not?

Yes, challenge is necessary. In every aspect of life, find a challenge.

Choose a worthy challenge, shoulder it, and face chaos voluntarily. Stand up straight, tell the truth, and put your house in order, one room, one habit, one promise at a time. Aim at the highest good you can name, and march toward it even when you are afraid. You will still suffer, that is the aim of challenge; you will be the one who turns challenge into strength and drags order from the abyss.

 

Stay tuned with PathOS updates

Sign up for our newsletter!

Follow us on LinkedIn & Twitter!

Do you want to share your own OS story? Join us and share your story here.