The fourth post in our series exploring Openwater’s vision, technology, and community.
There is no playbook for building an open-source community around medical devices. Not because nobody has tried, but because the conditions have never existed before. Medical device development has been, for good institutional reasons, a closed discipline. Proprietary IP, regulatory gatekeeping, and the sheer liability exposure of building things that touch human bodies have kept the industry behind walls that most open-source communities never had to contend with.
So when Openwater decided to open-source not just software but hardware designs, patents, and safety data for devices that deliver focused ultrasound to the brain and use near-infrared light to detect stroke, the first question from almost everyone was: why?
The second question, which turned out to be much harder, was: how?
This post is about the how. Not the technology we’ve covered, Open-LIFU and Open-Motion, in detail in earlier posts. This is about the infrastructure, the evangelism, and the daily work of cultivating a community of developers, clinicians, and researchers who are collectively building something that none of them could build alone. It’s about what it actually takes to make open source work in a space where the stakes are human lives, and the regulatory environment was designed for a completely different model.
Communities don’t materialize from announcements. Before anyone will contribute code, share safety data, or build on your platform, they need to trust that the foundation is real. In open-source software, that trust comes from mature repos, clear documentation, and visible activity. In open-source medical devices, it requires all of that plus something else: institutional credibility that the platform is safe, well-engineered, and serious about regulatory pathways.
Openwater’s community infrastructure was built in layers, each one a prerequisite for the next.
The software repositories on GitHub are the community’s front door. For Open-LIFU, the core Python library (openlifu), the 3D Slicer extension (SlicerOpenLIFU), and the standalone desktop application give three tiers of entry depending on a contributor’s technical depth and use case. For Open-Motion, the SDK, the blood flow analysis application, and the console firmware provide a similar range of values. Each repo has documentation, contribution guidelines, and issues labeled for different skill levels.
Getting these repos to a state where an outside developer could realistically clone, build, and contribute took sustained effort. Kitware, the medical imaging software company behind 3D Slicer, collaborated on the architecture specifically to make it extensible. The MATLAB-to-Python migration for Open-LIFU was driven partly by the same logic: Python is where the open-source community lives, and meeting contributors where they are is not optional.
Open-sourcing hardware is harder than open-sourcing software. Mechanical drawings, 3D models, and hardware manuals for Open-LIFU’s transmit modules and headset are published in the opw_neuromod_hw repository. But hardware documentation is a work in progress. We’ve said this honestly in previous posts, and we’ll say it again here. Closing the gap between what’s in the repo and what a skilled engineer would need to fully reproduce the hardware remains a priority. Transparency about that gap, rather than pretending it doesn’t exist, is part of how trust gets built.
Code repositories are necessary but not sufficient. Researchers and clinicians typically don’t discover projects by browsing GitHub. The community hub at openwaterhealth.github.io/openwater-community serves as the entry point for people who want to understand what Openwater is building and how to get involved, regardless of their technical background. The wiki at wiki.openwater.health provides deeper reference material. Discord serves as the real-time conversation layer.
The structure is intentional. A researcher at the University of Arizona who just received an Open-LIFU device needs a different on-ramp than a Python developer in Berlin who found the repo through a conference talk. Both need to feel that the community is real, active, and welcoming, but the paths that get them there look very different.
This is where the medical device context fundamentally changes the open-source equation. Openwater champions sharing adverse event and safety data across all institutions using the platform. When a research team at one university generates safety data from their focused ultrasound trial, that data strengthens the regulatory foundation for every subsequent trial on the platform.
In traditional device development, safety data is proprietary; each company builds its own evidence base from scratch, even when the underlying questions have already been answered elsewhere. It’s an enormous duplication of effort that slows patient access to new treatments. Openwater’s approach pools this data, which means every new institution joining the platform benefits from the safety record that came before them, and every new trial contributes back.
This is the infrastructural foundation that makes everything else possible. Without shared safety data, each lab is on its own. With it, the community becomes a regulatory asset.
Building infrastructure is necessary work, but communities grow through relationships, not repositories. The evangelism work spans three very different audiences, each with its own language, skepticism, and entry points.
At open-source conferences, the novelty is the application domain. Developers who have spent their careers building web frameworks, databases, and operating systems are intrigued by the idea that the same principles of transparency, community contribution, and shared infrastructure can apply to medical devices. The pitch here leads with the community model: how contributions work, what the business model looks like (Red Hat for medical devices is a useful analogy), and why this approach can actually deliver safer devices faster.
The questions from this audience tend to be about licensing (the AGPL-to-Apache 2.0 transition gets a lot of attention), contributor agreements, and how you maintain quality control when anyone can fork the code for a device that goes on someone’s head. These are good questions, and answering them honestly, including the parts that are still being figured out, builds more trust than rehearsed talking points.
At neuroscience and medical conferences, the novelty is the openness. Researchers who have spent their careers working with proprietary equipment understand exactly what it means when you tell them they can inspect the code that plans where ultrasound is delivered to the brain, or adapt the analysis pipeline for a diagnostic imaging device to their own research question. Their eyes change. These are people who have been constrained by black-box tools for their entire careers, and the idea that it could be different is immediately compelling.
The pitch here leads with clinical results. The University of Arizona depression trial involved twenty patients, over a third reaching remission from treatment-resistant depression using focused ultrasound, published in Frontiers in Psychiatry. The Open-Motion stroke detection study reported 79% sensitivity and 83% specificity for large-vessel occlusion in a 151-patient cohort, outperforming the two most widely used prehospital stroke scales. These numbers get attention because they represent a real signal, and the open platform is what makes them reproducible.
The follow-up conversations matter more than the talks. A PI who comes to the booth afterward to ask about adapting Open-LIFU for their pain study, or a neurologist who wants to understand how Open-Motion could work in their stroke unit, these are the interactions that become partnerships. MIT Lincoln Lab’s consciousness research with Open-LIFU started from a conversation like that. So did the University of Birmingham’s stroke rehabilitation study with Open-Motion.
The medical device world is the hardest audience to reach. The regulatory environment was built around proprietary development, and for understandable reasons: accountability, traceability, and quality control are genuinely harder in open systems. The pitch here doesn’t dismiss those concerns. Instead, it argues that transparency can better serve those values than opacity.
When every researcher can inspect the code and hardware designs, bugs are found faster, and fixes are shared across the entire community. When safety data is pooled rather than siloed, regulatory timelines compress for everyone. When the platform is open, the barrier to entry drops from the ~$94M and 20 years that the HHS estimates for traditional complex device development to something closer to $3M and 3 years.
The infrastructure gets people in the door. The evangelism brings them to the door. The daily work of community cultivation is what keeps them engaged and turns observers into contributors. This is the part that doesn’t scale neatly and doesn’t lend itself to dashboards, but it’s where the community actually lives.
When a research lab receives an Openwater device, the relationship doesn’t end with delivery. It begins. The onboarding process connects them to the community: the GitHub repos, the documentation, the Discord, and the people who are working on similar questions at other institutions.
The follow-up conversations focus on their experience with what’s working, what isn’t, the modifications they’ve made, and what they wish the platform could do. These conversations are the primary feedback loop for platform improvement. A calibration procedure developed at one lab gets documented and shared. A protocol refinement at another institution strengthens the next IRB submission at a third. The platform is built through the work of many hands.
The institutions already engaged MIT Lincoln Lab, UCLA, the University of Pennsylvania, Brown, and the University of Arizona; ETH Zurich is not just a user. They’re co-developers of a platform that improves with their participation. The value exchange is genuine: they get an open, configurable research platform at a fraction of the cost of proprietary alternatives. The community gets its safety data, its published results, its protocol innovations, and its reputation.
For developers, the contribution paths are deliberately varied. The Python migration for Open-LIFU is an active project that welcomes contributors at all skill levels. The 3D Slicer extension is a natural fit for developers already in the medical imaging ecosystem. Test coverage, CI/CD, and documentation are contribution paths that don’t require deep domain expertise in focused ultrasound or optical physics.
What developers in this community do get is something most open-source projects can’t offer: direct clinical impact. A code contribution that improves the beamforming algorithm for Open-LIFU doesn’t optimize ad delivery or reduce page load time. It improves the precision of a tool that delivers therapy to the human brain. That matters to people, and it shapes the kind of developer community that forms around the project.
The Contributor License Agreement is a necessary part of the process, particularly during the AGPL-to-Apache 2.0 licensing transition. When it comes up, we frame it as what it is: straightforward, standard, and designed to protect both the contributor and the project. Making administrative overhead feel proportionate to the mission rather than a barrier is a small but important part of developer relations.
Clinicians occupy a unique position in the community. They’re not typically writing code or designing hardware, but their feedback is disproportionately valuable because they see the technology through the lens of patient care. When a clinician says the workflow for planning a focused ultrasound session has too many steps, or that the 70-second scan time for Open-Motion needs to be faster for emergency department triage, that feedback reshapes the platform’s direction.
The clinician's path into the community is often through research partnerships. A neurologist running a focused ultrasound trial for depression. An emergency medicine physician evaluating stroke detection tools. A rehabilitation specialist studying post-stroke recovery. Each of these clinicians brings clinical insight that pure developers and researchers don’t, and connecting their perspectives to the technical development process is where the community’s real value is created.
Some of the most compelling ideas we’ve encountered haven’t come from established labs or seasoned developers. They’ve come from university hackathons.
Openwater participates in university-sponsored hackathons where students from neuroscience, biomedical engineering, computer science, and other departments that don’t neatly fit into any single department get hands-on time with the platform and 48 hours to do something with it. The results are routinely surprising. These are people who haven’t spent a decade learning what’s supposed to be impossible in neurology, so they propose things that a more experienced researcher might dismiss before the idea fully forms. Novel sonication targeting strategies. Visualization tools that rethink how clinicians interact with treatment data. Signal-processing approaches borrowed from fields unrelated to medicine. Some of it is impractical. Some of it is genuinely ahead of where the field is headed.
What makes these events valuable beyond the ideas themselves is something harder to measure: these students are stepping into a world that they actually want to improve. They aren’t treating neurology as an abstract problem set. They’re the generation that will inherit the healthcare system’s most stubborn failures, the cost structures that lock out entire populations, the proprietary silos that slow research to a crawl, and the gap between what’s technically possible and what patients can actually access. They care about closing those gaps, and they bring an urgency to it that you don’t always find in more established settings.
For Openwater, hackathons serve a dual purpose. In the near term, they generate fresh thinking and occasionally surface ideas that make it into the development pipeline. In the longer term, they’re building a pipeline of a different kind: a generation of engineers, researchers, and clinicians who already understand open-source medical devices and are ready to contribute from day one upon entering the workforce. Every student who spends a weekend building on Open-LIFU or Open-Motion carries that experience forward. Some will end up in neuroscience labs. Some will build companies. Some will shape policy. All of them will know that this model exists and that it works.
None of this is charity. Openwater is a venture-backed company with $100M+ in funding from Khosla Ventures, Plum Alley, BOLD Capital Partners, Esther Dyson, and Peter Gabriel. The open-source strategy is a business strategy modeled on a proven approach: Red Hat.
Red Hat proved that you can build a multi-billion dollar business by giving away software and selling services around it. IBM acquired them for $34 billion. The structural parallel to Openwater is direct: the platform is free, and the revenue comes from hardware sales, integration services, regulatory consulting, training, and ongoing support.
The insight that translates from Red Hat to medical devices is this: the value isn’t in the code or the designs. It’s in the trust, reliability, and expertise that professional support offers. In healthcare, this is amplified because the stakes of regulatory compliance, patient safety, and clinical outcomes make expert support not just convenient but essential.
And the open-source model creates a dynamic that proprietary companies can’t replicate: the network effect of pooled safety data. As more institutions join the platform, the safety database grows, regulatory timelines compress, and the platform becomes more valuable for everyone. Customers aren’t locked in by proprietary technology. They stay because the community’s collective work makes the platform genuinely better than the alternative.
Success for Openwater’s community is not measured in GitHub stars or Discord members, though those numbers matter as signals. Success looks like a research team at a university in Germany receiving an Open-LIFU device, connecting with the community, and publishing results that strengthen the regulatory case for every lab that follows. It looks like a developer in Tokyo is contributing a feature to the 3D Slicer extension that a clinician in Arizona uses in their next trial. It looks like safety data pooled across a dozen institutions, compiled into a regulatory submission that creates a new device classification benefiting the entire field.
More concretely, success looks like the trajectory from where we are to where we’re going. Today, the community has a small but growing number of members. Open-LIFU and Open-Motion are deployed at leading research institutions. Published clinical results are generating genuine scientific interest. The community infrastructure is functional and growing. Our FDA regulatory path is clear.
The work ahead is in the doing: more institutions onboarded, more contributions facilitated, more safety data shared, more conferences attended, more follow-up conversations had. Community building is not a phase that ends when you’ve hit a milestone. It’s the ongoing, daily practice of connecting people who care about the same mission and making it easy for them to contribute.
The hypothesis that open source can reshape medical device development is being tested right now, in real labs and with real patients, by a growing network of people who believe the traditional model is too slow, too expensive, and too closed to meet the scale of human need. This community is the mechanism through which that hypothesis either proves out or doesn’t.
We think it will. But more importantly, the community is building the evidence.
Explore the code: github.com/OpenwaterHealth
Join the community: openwaterhealth.github.io/openwater-community
Get started: openwaterhealth.github.io/openwater-community/get-started.html
Questions? community@openwater.health
This is the fourth post in our series exploring Openwater’s vision, technology, and community. Previously: Inside Open-MOTION: How We’re Using Light to Detect Stroke in Minutes.
The platform discussed here is exclusively intended for research purposes and is not cleared or approved by the FDA for clinical use. It is solely available to researchers and research institutions who are able to customize it to address the specific disease state they wish to study. The safety and effectiveness of the platform have not been established through the FDA’s formal review process.