Written by Nathan Parker, GIG member since 2017, is back to walk us through four years of work most of the network has only heard about in fragments, the Open Hardware Manager. Nathan traces the story back to Kathmandu, where he met Geraldine de Bastion and Andrew Lamb. He had just come from two months in the Black Rock Desert, building temporary infrastructure for Burning Man, when the director of Burners Without Borders and Sam Block, running Communitere at the time, told him to come to Nepal for a project setting up a makerspace in shipping containers donated by the UN. He arrived with a vague idea he was calling MakerNet. Andrew was building something with the same name. Geraldine gave a talk on critical making that Nathan credits with a lot of why he is still on this path. The following year he came to Berlin for the GIG week, and the collaboration with Andrew led to a summit in Warsaw where a group of gig members agreed the field needed universal open hardware data standards.
Standards on their own, Nathan argues, do not get you far. He lays out a five layer model: standards at the base, in this case Open Know-How and Open Know-Where; tools on top, single purpose command line utilities that each do one job; an engine wrapping the tools into something usable; services letting someone remotely query the engine; and finally a platform. No one manually interacts with a data standard, he says. Until a project reaches at least the engine layer, it does not matter how good the standard is, no one will use it.
The path from idea to engine ran through the pandemic. Nathan spent most of the COVID lockdown coordinating with Open Source Medical Supplies and Helpful Engineering, part of the volunteer effort to make up for shortages of medical supplies in the U.S. and beyond. What he saw was people reinventing the same coordination systems every time, systems built fast under pressure that then fell apart the moment volunteers moved on, only to be rebuilt from scratch the next time a crisis hit the supply chain. That pattern, repeating itself, is what pushed him to build the engine himself.
Open Hardware Manager works by pointing at an existing open hardware project on GitHub or GitLab and parsing it, files, documentation, licensing, into a valid Open Know-How manifest. Nathan’s own instance currently holds 174 designs across eight pages, drawn mostly from a catalog of around 40 designs from Open Source Medical Supplies plus other projects he has found and converted himself. Complexity varies on purpose. Alongside simple printable parts sits the complete design for an open source Mars rover published on GitHub by NASA’s Jet Propulsion Laboratory, hundreds of parts, software, multiple fabrication processes, chosen specifically to prove the system can handle something hard.
The manifest itself stays light on purpose. It is a thin, flat JSON file recording who made a design, how it is made, what it can be used for, and a list of links out to the heavy files, the STL files for printing, the DXF files for laser cutting, the source code. Matching a design against a makerspace, or checking whether a space near you can build something, happens against the manifest alone. Only when someone is actually ready to build does the full package, all the heavy files together, need to move.
That split matters for the second problem Nathan is solving: a single point of failure. It would be simple to build one more website and ask everyone to upload their data there, trusting one person or one server to keep it safe. Nathan has watched that pattern fail before, projects losing funding, platforms getting bought out, data ending up with someone nobody trusts. Instead, Open Hardware Manager is built for federation. The software is already published on Docker Hub, so anyone can pull the image and run their own node on their own hardware today. Nathan explains it through the logic of a mesh network: no central trunk, just nodes that pass signal to each other, so if one goes down the rest heal around it. He is working toward the same structure for a supply chain of physical goods.
The demo folds directly into GIG’s own history. At re:publica, Nathan met Jason Petio from the Maps of Making project, built on the Open Know-How standard, and it took him about five minutes to write a connector pulling the project’s makerspace data straight into Open Hardware Manager. Antonio Anaya, who led gig’s mapping work on the Make project for three years, is on the call watching his own field reflected back. Fadia raises Careables, the older open hardware platform tied to GIG members that went offline, its data now scattered and unlinked, and wonders aloud whether some of that history could be resurfaced here.
Antonio pushes the conversation toward why adoption is hard in the first place. He draws a line between information preparedness, having your data ready to share, and operational preparedness, actually being able to produce something when asked. Most fab labs and makerspaces have neither in place, and people are cautious about contributing data they do not see immediate value in, often because they do not trust the systems asking for it. Federation helps, he says, but trust has to be earned before contribution follows. He points to disaster response, citing the recent situation in Venezuela, as the kind of mission that gives people a concrete reason to prepare and share before the moment they actually need to.
Fadia asks the harder question directly: who is responsible for spreading the word, for teaching people to document their own designs, for making sure the tool itself is known to exist. Nathan is honest about it. He has been, in his own words, deep in the tunnel just trying to get this built, and adoption strategy is something he is hoping the community can help carry. The system is not at version 1.0. Before opening it to the public, he wants three things finished: reliable federation between nodes, and working tools for onboarding a new design and a new space. Until then, he is inviting developers and people already fluent in this work to get involved as beta testers, not yet the general public.
The mesh network idea keeps surfacing from different directions. The MARC project, maker resilience kits being built by Eric and Vicy, is testing something similar for crisis scenarios with little or no internet, likely a Raspberry Pi running Open Hardware Manager over Meshtastic, preloaded with designs curated for the moment they are needed. Tomas Diaz at Fab City is exploring a parallel version aimed at climate resilience. Nathan has also applied for a grant to build on OuiSync, a secure protocol that would move the heavy files across a mesh without exposing them to anyone the data is not addressed to, useful in what he calls adversarial conditions, the kind he says makerspaces in Ukraine building drones for defense are already living in.
Andrew Lamb closes the call by naming what he sees taking shape: an idea people at gig talked about at re:publica a decade ago, connecting makers to markets and getting designs made locally on demand, now becoming real. Nathan asks for something simpler in return, feedback, feature requests, and a small group willing to spin up their own node and test what breaks once the federation tools settle down in about a month. Before signing off he drops one more link in the chat, digitalpublicgoods.net, a registry he only just found and thinks gig should be part of. Andrew answers before the call ends: a few gig members are already listed there. The thread, like the network itself, keeps finding its own connections.
If anyone wants to pull the docker image for OHM and play with ithttps://hub.docker.com/r/touchthesun/openhardwaremanager/tags
And the source code: https://github.com/helpfulengineering/supply-graph-ai
