Perspective · Engineering
Open protocols used to need a developer.
We published our wire format for the usual reasons — outliving us, no lock-in, letting people build what we won't. Then something changed underneath that decision, and it is worth saying out loud, because it changes who "open" is actually for.
What "open" used to mean in practice
For most of the history of this industry, an open specification was a document that mattered to organisations with engineering teams. If you were a manufacturer, a broadcaster, or a software company, openness was leverage. If you were a two-person production team or a church with one volunteer who is good with computers, it was a PDF you would never act on.
So openness was real, but its audience was narrow. The gap between "the format is documented" and "I can use the format" was one salary.
What actually changed
Coding assistants are unreliable at architecture and genuinely good at transcription: taking a written, bounded specification and turning it into working code in a language you choose. That happens to be exactly the shape of implementing a small protocol.
The consequence is that the population who can act on an open spec grew by a lot. Not to everyone — you still need to run the result, read a log, and know when something is wrong. But it moved from "teams with a developer" to "people willing to spend an evening being careful." That is a much bigger group, and it contains most of the people who actually operate live productions.
How that shaped what we published
Knowing this, some design choices stop being neutral. A protocol that is clever is now worse than one that is boring, because cleverness is where assistants fail and where a non-specialist can't tell that the output is wrong.
- A fixed-size header rather than a negotiated one. Nothing to get subtly wrong.
- JSON for control, not a binary schema. Readable in a log, debuggable by eye.
- Unknown commands are ignored rather than fatal, so a partly-wrong implementation still runs and can be corrected.
- Two open reference receivers, because "compare against the working one" is the fastest debugging instruction there is.
None of this is generous. It is the cheapest way to get more integrations than we could ever write ourselves.
The part I'd rather not oversell
Three honest caveats, because this argument is easy to inflate:
- Assistants are confidently wrong about networking. Stream framing in particular — a TCP read is not a message. Code that looks right can work on a quiet network and fall apart on a busy one.
- Running something in production is a different skill from getting it to compile. Somebody still has to own it at 9am on a Sunday.
- This only holds for small protocols. Ours fits on a page. Nothing here says the same is true of a large specification with real state.
Why it matters for a product like ours
We are a small team in a category where the established answer costs tens of thousands and comes with a vendor's roadmap attached. We are never going to out-integrate that by writing integrations. What we can do is make the cost of someone else writing one approximately zero, and then get out of the way.
The practical form of that: everything needed to leave us is published. If we disappeared, the format is documented, the licence is permissive, the reference implementations are readable, and the assistant that would help you fork it is the same one that would have helped you build on us. That is a stronger guarantee than any promise we could put on a pricing page — and it is the reason the one thing we charge for isn't a feature.