Building in Public
Table Of Contents
- The Gap Between “Released” and “Useful”
- Some Specific Failures
- Why Share the Failures?
- What GrowGood Is Actually Attempting
- An Invitation, Not a Warning
- The Longer Project
- The Shadow Work of Maintenance
The GitLab commit message says “fix RS485 timeout on startup.”
It doesn’t say that finding that fix required four hours in 38°C heat, sitting at a folding table in a polytunnel with a laptop balanced on a seed tray, running serial monitor output and trying to understand why the sensor readings stopped arriving approximately 47 seconds after boot. It doesn’t say that the fix was changing a single number — the default timeout value — from 500 milliseconds to 1,000 milliseconds. It doesn’t say that the sensor’s documentation mentioned the requirement in a footnote on page 23 of a PDF that was only available in Chinese until someone on a forum translated the relevant section.
This is what open-source agricultural technology actually looks like. Not the clean repository with well-structured documentation and clear versioning. The real work that produces it.
The Gap Between “Released” and “Useful”
There’s a version of open source that is genuinely open: the code is public, the licence is permissive, and anyone can technically access it. And there’s a version of open source that is usable by another person — someone who wasn’t there when the decisions were made, doesn’t know the failure modes, and can’t just ask the developer what that variable name means.
The gap between those two things is real and large and often underacknowledged.
A repository that contains working firmware but no wiring diagram requires every new user to reverse-engineer the pin assignments. Documentation that describes the happy path but not the error states leaves the next person stranded when something goes wrong. Code that works on the developer’s exact hardware configuration but not on the slightly different revision of the same board that arrived in a different person’s order is technically open but practically closed.
Building in public — genuinely building in public, not just releasing code in public — means doing the unglamorous work of making the thing understandable to someone who isn’t you. That work takes longer than the development itself, and it’s often invisible in the project metrics that people use to evaluate open-source health.
Some Specific Failures
Honesty about the gap requires honesty about specific failures. Here are some from our own projects.
The RS485 sensor bus configuration for the LoRaWAN irrigation controller initially had no documentation for the termination resistor requirement. If you build the system without the 120Ω termination resistor at the end of the bus, it works perfectly in a test environment with a short cable run. It fails intermittently at longer cable runs — the kind of run you’d actually use in a garden — in ways that are extremely difficult to diagnose because the symptoms look like software problems, not hardware problems. We spent a day and a half on this before identifying it.
The documentation now includes a specific note about termination, with a wiring diagram. But someone who built the system before that note was added may still have a sporadic sensor issue they haven’t resolved.
The first version of the VPD monitoring firmware stored all sensor data in RAM and lost it on every power cycle. This was fine for development, where we were restarting the device frequently anyway. It was not fine in the field, where a power interruption meant losing the historical data needed to evaluate whether the control thresholds were working. The fix — writing to SPIFFS flash storage — took an afternoon. The failure cost a fortnight of data from a glasshouse pilot.
The irrigation terminal’s zone discovery relied on a specific MQTT topic structure that changed in a Home Assistant update. Users who updated Home Assistant before we updated the terminal firmware found their zone lists empty. We documented the Home Assistant version dependency after the fact, not before.
Why Share the Failures?
Because the failures are where the knowledge lives.
A fix document that says “increase the timeout to 1000ms” is only useful if someone can recognise their situation as the same as mine. That recognition requires knowing what the symptoms look like (sensor reads arriving for 47 seconds and then stopping), what the initial diagnostic hypothesis was (software buffer overflow, MQTT connection issue, power supply noise), and what ruled those hypotheses out before arriving at the actual cause. The commit message tells you what changed. The story tells you whether that change applies to your situation.
This is also why the regenerative agriculture community’s emphasis on farmer-to-farmer knowledge sharing is more than a philosophical position — it’s an epistemological one. The knowledge that accumulates through practice, in specific conditions, on specific land, with specific varieties and specific microclimates, is not fully transferable through protocols and specifications. It requires narrative. Context. The story of what went wrong and how you figured it out.
Building in public means sharing that narrative alongside the code.
What GrowGood Is Actually Attempting
GrowGood — the open-source farm planning tool we’re building — has a specific ambition that goes beyond the software itself. The Blueprint system, the ValueFlows integration, the data sovereignty architecture — these are important. But the deeper ambition is to create a commons of farming knowledge.
When a market gardener builds a Bed-Based Growing Blueprint in GrowGood, they’re not just configuring software for their own operation. They’re creating a template that another market gardener — in a different climate, growing different varieties, on different soil — can adopt, adapt, and improve. The specific workflow becomes a contribution to a shared library of practices.
This only works if the knowledge embedded in each Blueprint is legible — if the choices made in building it are explained, not just implemented. Why does this succession planting schedule start seed 28 days before transplant date rather than 21? Why does this Blueprint flag bed preparation as a separate task from transplanting, with a two-day gap? The implementation is in the data structure. The reasoning needs to be in prose — in the description fields, in the community forum, in the documentation.
GrowGood is an attempt to make farming knowledge persistent and shareable in a way that respects the complexity of that knowledge. That’s a harder problem than building the software.
An Invitation, Not a Warning
None of this is intended to discourage collaboration or contribution. The opposite.
The projects described in this site — the irrigation controllers, the VPD monitoring systems, the fermentation equipment, GrowGood — are better for every person who engages with them and reports back. Not just contributions of code: reports of what doesn’t work, questions about what things mean, suggestions from people who are using these tools in contexts we haven’t encountered.
When someone reports that the RS485 termination note was unclear, that’s a contribution. When someone asks why the soil moisture thresholds are set the way they are and whether those defaults make sense for clay soil rather than loam, that’s a contribution. When someone tries to deploy the MQTT proxy on an architecture we haven’t tested and reports what broke, that’s a contribution.
Building in public is an invitation to this kind of exchange. It requires accepting that the work is never finished and never perfect, that the documentation trails the code, and that the failures are part of the public record. In exchange, you get collaborators who understand the real situation rather than the idealised version of it.
The Longer Project
The irrigation controls, the VPD tools, the fermentation equipment, GrowGood — these aren’t separate projects that happen to share a website. They’re parts of a longer project: building the open infrastructure for a different relationship between people and food.
That infrastructure is technical — firmware, protocols, databases, open hardware. It’s also epistemic — knowledge commons, shared practices, documented failures and their fixes. And it’s social — communities of growers, makers, and technologists who find it useful to work on the same problems together rather than in isolation.
Building in public is how that longer project becomes real. Not through the release of perfect, finished tools, but through the ongoing, imperfect, specific work of making things that function in the world and sharing what we learn.
The commit message says what changed. This is the rest of the story.
The Shadow Work of Maintenance
Building in public often celebrates the “new” — the first sensor reading, the first successful valve actuation, the first public repository. But the real public service is the shadow work: the unglamorous maintenance of things that already exist.
It’s the pull request that updates a dependency to fix a security vulnerability. It’s the two sentences added to a README because someone on Discord found a confusing step. It’s the decision to refactor a messy but working script so that the next person can read it without a headache.
When we share our maintenance work, we’re sharing the true cost of ownership. We’re showing that open source isn’t just about a one-time release; it’s a commitment to stewardship. If you’re using our tools, you’re not just a user; you’re part of the team keeping the infrastructure standing.
Report the bugs. Clarify the typos. Help us keep the paddock tidy.
Discussion in the ATmosphere