Chapter 1: The Pint and the Problem

There comes a point in every production where you put down whatever you are holding — a lighting desk, a clipboard, a phone with four apps open on it — and you realise the whole show is being held together with string, goodwill, and four systems that have never once been introduced to each other.

Mine came on a Tuesday. In a pub. With a pint I had earned and a spreadsheet I had not.

Let me tell you what was on that table, because I suspect it will look depressingly familiar.

There was a light plot living in a WYSIWYG file. There was a sound design that existed mostly in one person’s head and partly in a QLab show file. There was a running order, which was a Google Sheet. There was the other running order, which was the stage manager’s paper prompt copy, covered in pencil and coffee. There was a call sheet, which was a Word document last edited by somebody nobody could quite name. There were three WhatsApp groups. And there was the venue’s own spreadsheet of rigging points and power capacity, which lived on a laptop in an office and which the lighting designer had never been shown.

Every single one of those things was, on its own, completely reasonable. That is the trap. A lighting plot belongs in a lighting tool. A sound design belongs in a sound tool. None of those decisions is wrong. And yet, taken together, they add up to a production where the left hand has no idea the right hand exists, and where the thing connecting all of it is a person — usually the stage manager — with a good memory and a phone.

We have got so used to this that we call it normal.

The tech is not the problem

We are not short of technology. Every department now has a serious, powerful, purpose-built tool, and most of them are genuinely brilliant at what they do. A modern lighting console is a computer that would have run the Apollo programme. A modern DAW can place a sound anywhere in a room to within a centimetre. Video switching that used to need a truck now fits in a lunchbox.

So the problem is not that we lack tools. The problem is that the tools do not know each other.

The lighting designer’s cue for “actor enters stage left” and the sound designer’s cue for “door slam” and the stage manager’s note for “this is the bit where the revolve gets complicated” are three descriptions of the same moment in the same show. And they live in three files, in three formats, on three machines, and none of them is aware that the other two exist.

We have solved the hard problems and left the easy one unsolved. We can simulate a beam of light through haze to within a plausible degree of accuracy — and we cannot automatically tell the sound department that the scene just changed.

The four walls

I have come to think of it as four walls, and every production lives inside them.

Per-department. Lighting owns lighting. Sound owns sound. Each is a kingdom with its own customs, its own file formats, and almost no shared vocabulary. Ask a lighting person and a sound person what a “scene” is and you will get two different answers, and both will be correct.

Per-version. Because the tools do not share data, the same fact gets typed in several times and drifts. The WhatsApp group says 6:30. The call sheet says 6:00. The calendar says 6:45 because somebody moved it and forgot to tell the other two. There are simply three truths, and finding out which one is real falls to whoever is standing in the corridor when the cast arrives.

Per-format. Even when two departments want to share, they cannot, because their tools speak different languages. You export a CSV and half the columns shift. Interchange that should be automatic is done by hand — and by hand means eventually it does not get done at all.

Between the paperwork and the show. Planning happens in one world — spreadsheets, emails, documents. Performance happens in another — consoles, cues, a stage, an audience. Information flows from the first into the second, badly, and then stops. Nothing flows back. The show is overridden seventeen times on opening night; nobody writes down what those seventeen fixes were, so on the second night they do it all again.

And then there is the bill

The tools that actually solve a department’s problem are, almost without exception, priced for institutions. A single professional lighting visualisation licence can cost more per year than a community theatre spends on an entire production. Audio, video, cue playback, venue management — each a subscription, each justified on its own, and together a wall most small companies simply cannot climb.

So the big venues buy the tools and get the silos anyway, because the tools were never built to talk to each other even when you can afford all of them. And the small venues do not buy them at all. They make do: free versions, the tools they already had, a spreadsheet, a bit of paper, a person who happens to be good with computers. The gap between what the big houses can do and what everyone else can do widens every year, and it has almost nothing to do with talent.

That is the problem in one sentence: the tools got better and more expensive, none of them learned to work together, and the people with the least money ended up with the most manual labour.

These pub conversations always end the same way. Somebody says “what we need is one system that does all of this”, everybody nods, somebody points out it would be enormous and that big companies have tried and made a mess of it, and we go back to the spreadsheet. For years I agreed with that last bit. Then two things happened — which is the next chapter.

Chapter 2: The Thing Nobody Warns You About

Nobody warns you that the hard part of putting on a show is not the show.

By the time the performance arrives, it is the least complicated part of the enterprise. Everything around it is where the difficulty lives. And most of that difficulty is not artistic. It is administrative, and it is generated almost entirely by the fact that the tools do not talk to each other.

Let me name the specific things, because “it’s inefficient” is too vague to be useful.

The re-entry problem

The same piece of information, typed in more than once, because there is no mechanism for it to travel.

A cast member’s emergency contact gets typed into the contact sheet, and again into the call sheet, and again into the venue’s access list. When they change their number, it changes in one of those places, because they only tell the person who happens to have their number, and the other two lists quietly rot.

The schedule is worse, because it changes. It always changes. A rehearsal moves from Tuesday to Wednesday because somebody’s day job intervened. The stage manager updates the calendar. But the rehearsal report template still lists Tuesday, and the printed call sheet still says Tuesday, and the room booking still says Tuesday — and on Wednesday morning, half the cast turn up to a room booked for a dance class, and the other half turn up on Tuesday to an empty room. Nobody’s fault. Four systems, one fact, no connection.

And the cost is not just an hour. It is the erosion of trust in the schedule itself. After it happens twice, people stop believing the call sheet and start texting to check — and now you have a second information channel on top of the first, which is the one that will be wrong next time.

The version soup

When the same document exists in several places, somebody has to decide which one is true, and the decision is usually made by whoever has the least patience.

You have all seen the folder. Script_v3.docx, Script_v3_FINAL.docx, Script_v3_FINAL_2.docx, Script_v3_FINAL_2_JH_edits.docx, and Script final use this one.docx. The one you want is almost never the one with the most reassuring name. It is the one that was emailed to you personally on Thursday at 11pm with the subject line “ignore the last one”.

In a production this is dangerous, because a script is not a document — it is the spine every other thing hangs off. Every cue, every set change, every costume plot, every entrance and exit is anchored to a line in that script. Change a line, and everything anchored to it is floating. Which is why, when a page gets revised, the first thing that happens is a flurry of activity to work out what just broke — and the second thing is that somebody misses one, and it only surfaces on the night.

The paperwork that never meets the performance

This is the deepest version of the problem, and the one that costs you learning.

A rehearsal report says what happened in the rehearsal — attendance, scenes covered, running times, notes, injuries, tech problems. It goes into a folder. It is read by about three people, briefly, and then never looked at again. Meanwhile the actual knowledge — the scene runs long because of the set change, the sound cue needs a second of silence, the actor needs a light on the top of the entrance — lives in the heads of the people who were there. All of it real, all of it written down, none of it connected to the thing it is about.

So the same lessons get re-learned. Not because anyone is forgetful, but because the record of the lesson is separated from the object it applies to. The note says “the revolve is slow”; the revolve does not know that. And so the tweaks made in rehearsal have to be made again in tech, and again on the first preview, and again on opening night, because each is a different group of people operating a different tool with a different copy of the same instructions.

The thing you actually lose

It is tempting to file all this under “theatre is chaotic, that’s the charm”. There is chaos in theatre, and some of it is delightful — the best moments in live performance are the ones nobody planned. But this is not the good kind. It is the grinding, low-grade friction of a system that makes you do the same work three times and still does not trust its own records.

And what it costs is not just time. It costs attention. Every ounce spent reconciling two versions of a call sheet is an ounce that did not go into the show. The industry runs on people who burn attention like it is free. It is not free. It is the rarest thing in the building.

Almost none of the friction I have described is inherent. It is not a law of nature that the lighting plot cannot know about the schedule, or that the sound cue cannot live with the script, or that the rehearsal report has to be a dead document. Those things are the way they are because the tools were built separately, sold separately, and never introduced. Which means they can be changed — if you have one place where a fact lives, every tool reads from it, every change flows to everything that depends on it, and the record of what happened stays attached to the thing it happened to.

Chapter 3: The Spark in the Dark

I need to tell you how the impossible part became possible, because for years it was the thing that killed the idea before it got started.

The objection always went like this. “Fine, you want one system that does lighting and sound and video and stage management and venue design and documents. Where are you going to get it? The big vendors have spent thirty years and hundreds of millions and they still cannot share a pen, and you are one person with a blog.”

Completely fair, and for a long time it was a killer. Because the real problem was never the idea — every producer I have met has had a version of it. The real problem was the sheer, grinding quantity of building. You would need a word processor, a spreadsheet, a presentation tool, a PDF tool, a vector editor, a photo editor, a motion graphics tool, a video editor, a CAD program, an audio workstation, a lighting visualiser, a cue engine, a comms system, a venue model — and then, on top of all of that, the one thing nobody has: the layer that actually connects them.

That is why the idea stayed in the pub.

Then I saw what Storytold were doing

Sometime in the middle of all this, I came across Storytold, and their suite of apps under the ArtCraft banner. And I am not exaggerating when I say it rearranged how I thought about this problem.

They are building clean-room reimplementations of the major proprietary creative apps, from scratch, in pure Rust. Not clones in the legal sense — clean-room, from public specifications and observed behaviour. And not prototypes. Real applications, shipped natively and to the browser, under a permissive licence.

Look at what the suite actually covers:

• WordCraft, GridCraft and DeckCraft — word processor, spreadsheet, presentations. The Office space.
• DesignCraft, VectorCraft, PhotoCraft and LightCraft — page layout, vector, raster and photo workflow. The Adobe design space.
• EffectCraft and FilmCraft — motion graphics and video editing.
• PdfCraft — PDF handling. CADCraft — 2D CAD and drafting, the AutoCAD space.
• SoundCraft — audio and a DAW engine, the Pro Tools space.

That is the entire creative suite. Adobe, Microsoft Office, AutoCAD, Pro Tools. The whole wall of subscriptions every small production is priced out of — reimplemented, open, in one language, by a small group of people, in the time it used to take a large company to schedule a kickoff meeting.

And — the part that made me sit up — a very large amount of it was built with Claude doing a great deal of the lifting. Which is not a small detail. It is the entire point. The reason something like this is now buildable by a small team is that the raw act of writing large quantities of correct, careful code stopped being the bottleneck. The bottleneck moved — to judgement, architecture, and knowing what the thing should be. Which is exactly the kind of bottleneck a small, opinionated, domain-obsessed team can win against a large one.

Why it fits us so precisely

It is not just that the apps exist. Three properties matter enormously, and the suite has all three.

The same stack. All pure Rust, with the same layering discipline across every app. Rust is exactly the right language for the parts of this problem that must not fall over in front of an audience — memory-safe, fast, and it does not crash quietly at the wrong moment.

A permissive licence. MIT or Apache-2.0. We can depend on it, embed it, build on it, and ship it — without a legal team and without a conversation with a vendor. For a project whose premise is “open, affordable, for the people who got priced out”, this is a precondition.

Every action is a command, and the architecture is swappable. Everything you can do from a menu you can also do from the keyboard, the command line, a control channel, and an agent interface — so an agent can drive the app and then inspect the result to check its own work. And strict crate layering, with a user interface designed to be replaced, means we can take the foundation — the DXF/DWG reader, the document model, the plotting, the DSP, the timeline — and build our own grammar on top without forking anything.

The raw materials for the thing I had spent years calling impossible were sitting there, in the open, in the right language, under the right licence, built to be combined.

The realisation, over a pint

I remember the exact moment it clicked, and it was, predictably, in a pub. I had been assuming that a production operating system meant building all those apps. And then I realised: no. It means connecting them.

Storytold are building the apps. The open-source world is building the engines. What nobody is building is the thing that ties it all together for a production — the shared graph of what the show is, the runtime that runs it, the mesh that keeps it alive, and the identity model that decides who is allowed to do what.

That is the actual product. Not eleven apps fighting for your subscription. One foundation, and a lot of tools that finally, genuinely, know about each other. And the moment you frame it that way, the difficulty changes shape. It stops being “we must rebuild the entire creative software industry” — which is fantasy — and becomes “we must build the spine, and connect the pieces that already exist” — which is merely very hard, which is a completely different category of thing.

The honest bit about the spark

I want to be careful here. Storytold’s suite is young. CADCraft is strong at the drafting and paperwork half of a lighting app and essentially absent at the 3D half — which is fine, because a lighting app needs a mesh scene, not a CAD kernel, but it matters when you decide what to build on. SoundCraft is a fantastic starting block for an audio engine, but it is not, by itself, a live-show engine; the live part is ours to build. And the same newness that makes it exciting could bite: if you build on someone else’s fast-moving foundation, you had better build it so the foundation can be swapped without the walls coming down. That ends up shaping the whole architecture.

So: the spark is real, and it is buildable in a way it was not five years ago. But “buildable” and “built” are different words, and between them sits every hard question in this post. Let me start answering them.

Chapter 4: What BackStageOS Actually Is

Right. Let me try to describe the thing without a sales pitch, because I have read too many of those and they all sound the same.

Here is the shortest version I can manage:

BackStageOS is one shared foundation for a production, that every department’s tools read from and write to — so that a fact entered once is known everywhere, a change made in one place flows to everything that depends on it, and the record of what happened stays attached to the thing it happened to.

That is it. Everything else is detail. But four words in that sentence do an enormous amount of work: foundation, read from and write to, everything that depends on it, and stays attached.

Foundation, not fortress

This is not a single app that does everything. It is a foundation — a shared core — and a family of tools that sit on top of it.

Think of it like an operating system. You do not open one application to use your computer. You have a core that provides the ground — files, permissions, networking, the screen — and then you choose which apps to run on it. The apps feel different because they do different jobs, but they all stand on the same ground.

BackStageOS is that ground, for a production. The tools on top are chosen per department, adopted one at a time, and each useful on its own — which is the reason this has any chance of being adopted by real companies with real budgets.

The three pieces

BackStageOS — the production OS. The core. Graph, runtime, mesh, identity. Everything from the first draft of a script to the curtain coming down and the debrief that follows.

VenueOS — the venue OS. The same foundation applied to a building rather than a show. Spaces, rigging points, power, network, signage, box office, building systems. It exists because a production and a venue are, when you get down to it, the same problem wearing different hats — and because a show that knows the building it is in stops discovering it the hard way.

Maestro — the console line. The commercial layer, deliberately last. A family of physical consoles — all-in-one, lighting, sound, AV, a stage manager’s station — that are really just surfaces onto the same foundation. They only exist once the software does, and because the surfaces are defined in software, you can prototype every one of them on a laptop and a cheap MIDI controller long before anybody tools a metal box.

All three share one core: the same graph, runtime, mesh and identity. A lighting change does not have to be translated between them. It is the same fact.

The principles that keep it from turning into a puddle

One shared graph. Every authored fact about the production lives in one connected structure — script, cues, schedule, budget, venue, assets, notes. Not one database per department. One graph, local to each device, that syncs peer-to-peer when devices meet.

Local-first, no single point of failure. This is the one that makes it credible for live performance. The system does not depend on a server somewhere being up. Every machine holds a working copy. Pull the network cable out and keep working; everything reconciles when it comes back. If a machine dies, another takes over. For a system that might be running the only copy of a show at 7:30 on a Saturday, this is not a feature. It is a requirement.

Two planes. Authored truth lives in the graph, where people are free to edit, experiment and collaborate. Deterministic execution lives in the runtime, which takes a frozen version of the graph and runs the show reliably, without any of the collaborative machinery in the way. The thing that makes the graph good at collaboration is exactly the thing that would make it bad at pressing GO. So we keep them apart on purpose.

Scales from one to N. The same system runs on one laptop for a one-person show, on a console for a single operator, on a hub and a handful of nodes for a venue, and federated across several venues for a festival or a tour. Not four products. One product in four shapes.

And one more, a posture rather than a principle: bridge first, own later. Where a good open tool already exists, connect it rather than rebuild it. Only build it yourself when connecting is impossible, or the user experience is a genuine wall, or nothing adequate exists. This is how you avoid building eleven mediocre apps instead of one very good foundation.

The two roads that led here

This idea is really two ideas circling each other, and they are two views of the same system.

The first is the single rich facility — one well-equipped building, deeply wired, running a production end to end, with its own appliances and console family. That view gives you VenueOS, Maestro, and the depth of a fully instrumented house.

The second is the distributed, resilient mesh — a system that can span a touring company, a festival, several venues, and survive the link between them failing. That view gives you the peer-to-peer mesh, the local-first graph, and the whole “a phone in a pub and a cinema camera arrive at the same hub as the same rectangle” philosophy.

Same graph. Same runtime. Same identity. Different scale. Build the core properly, and the single venue and the distributed festival are not two projects. They are two greenhouses for the same seed.

What it is not

A project with no edges is a project with no shape, so let me draw them.

It is not trying to replace the certified systems that keep people alive. It does not touch the fire panel, the structural rigging calculations, the automation interlocks, or the evacuation plan, except to read them, coordinate with them, and log what happened. Certified hardware executes. We advise.

It is not a “move everything to the cloud” play. It is the opposite — local-first, and the cloud, if it appears at all, is optional convenience, never the root.

It is not a walled garden. Open protocols, open formats, import from the proprietary tools wherever possible.

And it is not finished, or close to finished. Which is why the back half of this post gets honest about the walls. But first, the good bit — the bit I actually believe in. Let me tell you about the graph.

Chapter 5: One Graph, One Truth

If you take nothing else from this post, take this chapter. Everything else is downstream of it.

The heart of BackStageOS is a single thing: the production graph.

Not a database. Not a folder of files. A graph — a network of things and the relationships between them — that holds every authored fact about a production. The script, the cues, the schedule, the budget, the venue, the set, the props, the costumes, the rig, the fixtures, the sound and video sources, the assets, the notes, the paperwork, the people. All of it in one connected structure, with the connections as important as the things.

Why a graph, and not just “a shared database”? Because the difference is the whole point.

Things and the lines between them

A database table is a list. A graph is a web.

In a list, the fact that “Cue 47 is the door slam” is a row. In a graph, it is a node — the door slam — with edges going out to everything it touches: the script line it happens on, the scene it belongs to, the sound file it plays, the speaker it comes out of, the person who pressed GO on it last night, the note the director gave about it, the fact that it is ten milliseconds late.

Now somebody changes the script. They cut the line before the door slam. Because that line is connected to Cue 47, which is connected to the sound file, which is connected to the schedule entry for that scene, the change does not sit in a document waiting to be noticed. It ripples. Everything downstream of the cut can see that it has been affected, and the system can tell you, in advance, what is about to break.

That is the whole idea of “one truth”. Not that there is one file, but that there is one web of relationships, so a change made anywhere is visible everywhere it matters.

Why it matters for a live show

You are in tech. The director decides the revolve should come in one bar early. A small change, said out loud, in about four seconds.

In the world we have now, that sentence becomes a job for five people. The stage manager writes it in the prompt copy, which has to reach the lighting programmer, because the revolve light cue moves. It has to reach sound, because there is a cue that lands with the revolve. It has to reach the automation operator, who has to re-time the revolve. It has to reach whoever updates the running order. And then all of those people have to be told.

In the world I want, that sentence becomes one edit. You move the revolve cue. Everything connected to it — light, sound, timing, running order, note — is connected, so the system shows you exactly what just moved and flags anything that needs a human decision. The stage manager confirms. The cues shift with it. The automation operator gets a task. One sentence in, and the whole show adjusts.

That is not automation for its own sake. It is removing the translation layer — the layer where one artistic decision has to be transcribed by hand into five departments’ private languages, each time, all show, forever.

Everything gets an address

For a graph to be shared and merged, every thing in it needs a name that never collides with anybody else’s. So every object gets a stable, unique address, and it stays the same across every device, every save, every merge. Plumbing, but it buys three enormous things.

It lets the graph merge. If two devices both worked on the show while apart — a designer on a train, a stage manager in the venue — the graph reconciles them by address. Two edits to the same object are the same object. There is no “which file is newer”.

It lets the graph be a CRDT. Jargon, but the plain English is this: the graph is built so concurrent edits merge automatically and safely, without a central server and without anyone locking the document. That is what makes offline, peer-to-peer collaboration work.

It lets the graph remember. Because every object has an identity and every change is a record, you get version history essentially for free. Tag a point in time — “as performed, opening night” — and go back to it. Pull a cue stack from a show two years ago and lift the two or three cues that were brilliant. Designers have libraries; lighting designers do not, really, because their work is locked inside a show file in a proprietary format. The graph gives them a real library, and a real history, for the first time.

One graph, many namespaces

A graph that holds everything sounds like it would become an unmanageable tangle, and if you were not careful, it would. So the graph is organised into namespaces — one per department or domain. Lighting owns a namespace. So do sound, video, stage management, venue, finance, wardrobe, props, accessibility and music reporting. Each owns its slice and its vocabulary, and nothing in one namespace silently stomps on another.

But the namespaces are connected. The lighting namespace does not own “the door slam”. It owns the light on the door slam. The sound namespace owns the sound. The script owns the line. Because they all hang off the same moment, they can all see each other.

The one thing that must never drift

In an old-fashioned prompt copy, the stage manager holds a single sheet with the script and a line running down the middle, and everything is anchored to that line. Every cue, entrance, sound and light change is marked against the same spine. The prompt copy is the show’s shared coordinate system — how you say “everybody to the top of page 42” and mean the same thing in four departments.

The graph does the same digitally. There is one structure — the show position — that is the single timeline every department aligns to. Not the lighting timeline. Not the sound timeline. The timeline, and every department’s cues are pinned to it. When the show runs, everybody is reading from the same page — the follow spot, the sound operator, the automation, the video, the stage manager, all looking at the same position in the same graph.

Which is why the next chapter matters so much. Because here is the problem with a graph built for free and loose collaborative editing: it is a wonderful thing to author a show in, and a terrible thing to run a show from. And confusing those two jobs is the mistake that would sink the whole idea.

Chapter 6: Two Planes and the Maestro’s Baton

This is the chapter that decides whether the whole thing is credible or daft, so I am going to take it slowly.

BackStageOS has two planes. Two distinct things the system does, kept apart on purpose.

The authoring plane is where the show is designed. It is the production graph — collaborative, editable, mergeable, local-first. In this plane you want freedom: try things, undo things, three people editing at once, work offline on a train, merge when you get there. The authoring plane is meant to be loose.

The execution plane is where the show is run. It takes the authored show and performs it — fires the cues, drives the outputs, keeps time, fails over safely. Here you want the opposite of freedom. You want determinism. Given the same cue and the same trigger, it does exactly the same thing, every night, at exactly the same moment, with no surprises.

Here is the key sentence, and it is the one I would put on a poster:

The thing that makes the graph good at collaboration is exactly the thing that makes it bad at running a show. So we never run the show from the graph directly. We compile it.

Why you never run the live show off the CRDT

A collaborative graph is eventually consistent. That means: if two people edit at once, the system sorts it out, and after a moment, everyone agrees. “After a moment” is fine when you are designing a cue stack on a Tuesday afternoon.

At 7:30 on a Saturday, in front of an audience, “after a moment” is a nightmare.

Imagine the stage manager fires a cue at the exact instant a collaborator’s offline edits sync in from a laptop that was on the train. In a CRDT, both are valid, and the merge has to decide what the state is. On a desktop that is a millisecond of harmless bookkeeping. On a show it is a cue that fires late, or twice, or with the wrong values, because the thing it was compiled from was edited by somebody who is not even in the building.

That is not a risk you can design around with polish. It is inherent in what a collaborative graph is. So the only sane answer is: you do not run the live show off the graph. You run it off a frozen, compiled version, and that version is incapable of being surprised.

The compile contract: Draft → Rehearsal → Armed → Live

So the show has maturity levels, and who can change what depends on the level.

Draft is pre-production. Anything goes. Design, build, rearrange, scrap it and start again. Full collaborative freedom.

Rehearsal is tech and dress. You can still adjust, but you are adjusting armed values — timing, level, position — rather than the whole structure.

Armed is ready for performance. The compiler takes the relevant slice of the graph and produces a deterministic, versioned show file. Frozen. Validated. This is what will actually run.

Live is the performance. Locked — with one deliberate exception.

And the compiler is not just a copier. Its job is to validate. When you arm a show, it checks the things a human would miss: does this cue reference a fixture that is not patched? Does this sound cue point at a file that is not on this machine? Does anything depend on a value that was never set? Breakage is caught at arm-time, in the calm, with time to fix it — not at curtain-up, in the dark, live.

This is the same idea as a compiler for code, and it is not an accident. You write code in a loose, human way, then compile it into something deterministic a machine can run. Shows should work the same way.

The one exception: the override layer

Live performance has one thing a computer program does not: reality, arriving uninvited.

The actor misses an entrance. A prop is not where it should be. The revolve sticks. The show is not going to stop because the plan did not account for reality, and the person at the desk is going to have to fix it, live, with their hands, right now.

So the Live plane has an override layer: a place where the operator can reach in and change what is happening — jump to a cue, hold, adjust, take manual control — without unpicking the frozen show. The override is allowed. It is expected. It is what a good operator does.

But the override layer has a second job, and it is the one I love: it writes everything down. Every manual intervention is recorded as part of the show’s history, stamped against the show position. So the thing everybody does today and nobody captures — the seventeen fixes on opening night — becomes a permanent record. The next morning you can see exactly where the show diverged from the plan, and why, and decide whether to fold it back into the design. The live show feeds the authoring plane. The knowledge survives. That is the paperwork finally meeting the performance.

The Maestro’s baton: the show position

Everything above depends on one thing: that every part of the system agrees on when “now” is.

So BackStageOS runs on a shared timebase, and every department reads the same show position — a single cursor through the show that says, unambiguously, exactly where we are. Not the lighting operator’s position or the sound operator’s position. The position.

Think of it as the conductor’s baton. The baton does not play any of the instruments. It makes all of them agree on the beat, so what they each play lands together. The show position is that baton. It is what lets a light change, a sound cue and a video transition — three different technologies on three different machines — land as one moment instead of three near-misses.

Why this chapter is the whole architecture

I will say plainly what I believe: the two-plane split — authored graph for designing, compiled runtime for performing — is the single most important decision in the entire project. It is what lets the system be simultaneously flexible and rock-solid, a combination most production software has to choose between.

It is also why I trust it to work in a building. The go-live path is narrow, frozen, validated and clocked, and none of the collaborative machinery — no merges, no sync, no offline reconciliation — is anywhere near it when the curtain goes up.

Right. That is the engine room. Let me come back up to the building and talk about the things you would actually touch: the apps.

Chapter 7: The Department Apps

Right, let me come back up out of the engine room and talk about the things you would actually open and use, because an architecture nobody can touch is just a diagram.

The rule for every app is the same, and it is the rule that makes the whole family adoptable:

Every app runs completely on its own.

That is not a slogan. It is a hard design constraint. The lighting app must work with nothing else installed — no account, no server, no mesh, no other department, no internet. You can design, patch, program and run a show on one laptop, in a field, with the wifi off.

Collaboration is additive and optional, never a precondition. This matters more than any feature, because it means a small company can adopt one app, get real value from it, and never buy into a platform or migrate their whole operation. You do not have to believe in the grand vision to use the lighting tool on Tuesday.

Lighting

The beachhead. The clearest case of a department badly served by expensive, closed, disconnected tools.

The target is the job a WYSIWYG or a Capture does: venue and set geometry in 2D and 3D, fixtures placed on positions, pipes, trusses and booms, a light plot, a section, a patch, and — crucially — a real-time visualisation of what the light actually looks like. Beams, colour, gobos, haze. The thing that lets a designer see the show instead of imagining it.

But because it sits on the graph, it is more than a visualiser. The plot is a projection of the graph, not the source of truth. Fixture data, patch, positions and cues all live in the graph, and the drawing, the paperwork, the rigging plan and the cue stack are all generated from it. Change the graph, and everything regenerates. No more hand-editing a DWG that then drifts from the plot, which then drifts from the console. And it is honest about what it is not: the 3D you need for light is a scene mesh, not a precision CAD kernel — and the precision CAD belongs in the drafting tool.

Sound

The engine is an audio workstation — faders, EQ, dynamics, effects, a real mix engine. The show part is the live side: cue playback, the mix for the room, monitors and in-ear mixes for the performers.

The open-protocol move is AES67 — the open answer to the proprietary audio-over-IP that dominates installed sound. Because audio I/O is a network node rather than a dongle in a machine, a sound operator can fail over the brain of the system without losing the pipe that carries the audio. That brain-versus-pipe distinction is one of the quiet, important ideas in the whole design.

Video and stage management

Video is switching, playback, projection mapping, and the screens that live everywhere in a modern venue: confidence monitors, dressing-room feeds, front-of-house displays, signage. Sharing a graph means the video cue and the lighting cue and the sound cue for a moment are, finally, the same moment.

Stage management is where the whole graph earns its keep, because the stage manager currently spends their life being the human integration layer between every other department. The schedule, the running order, the script with its cues, the rehearsal reports, the notes, the calls, the comms — all in one place, all connected to the show position, all feeding the record. This is where the “rehearsal report that never meets the performance” problem finally gets fixed: the note you write is attached to the cue it is about, and the report is generated from the show, not typed up afterwards.

Venue

The building itself: spaces, rigging points, power, network, capacity, sightlines — the stuff that should be known to every production but currently lives in an office laptop nobody has seen. This app is the bridge into VenueOS, which I will get to properly later.

The domains nobody thinks of as technology

A show is not just lights, sound, video and stage management. A show is also: scenery moves and fly cues. Loads on rigging points. Costume quick-changes. Props. Front of house. Accessibility — captions, audio description, hearing loops. Music reporting, a legal obligation currently running on paper and goodwill. Wardrobe, wigs, makeup. The smoke and flame and pyro that have to be coordinated with the fire system. The audience.

Every one of these runs on paper, radios and muscle memory, and every one gets better the moment it shares the graph and the show position. The captioning knows which line we are on. The fly cue knows it comes with the light cue. The music reporting is generated from the running order instead of reconstructed afterwards.

Two rules govern all of them. The first is the adapter rule from the last chapter. The second is a safety boundary, not a marketing boundary: anything that can hurt somebody — motion, loads, crowd, fire — stays in certified hardware. BackStageOS advises, coordinates, visualises and logs. It is never the certified executor. It does not replace the automation controller that is legally allowed to move scenery over an actor’s head. It tells everyone else when that is about to happen.

The catch, which I will not hide

Every one of these apps is a serious piece of software. None is a weekend project. The plan is not to build all of them at once — it is to build the foundation, and the one app that proves it, then grow the family opportunistically, reusing everything, and connecting the tools that already exist wherever connecting is smarter than building. Which brings me to the question that decides whether any of this is realistic: how do you grow a family of apps without rebuilding the entire software industry? The answer is a rule, and the rule is the next chapter.

Chapter 8: Adopt One, Get the Rest Free

There is a version of this project that fails, and I want to describe it so we can all agree to avoid it.

The failure mode is called “we must build everything.” You decide the industry’s tools are siloed, so you set out to replace every one of them, and you end up with eleven half-finished apps that are each worse than the thing they were trying to replace, and no foundation underneath any of them. That is how big ambitious suites die. Not usually from a bad idea — from trying to be all things at once.

So there is one rule that governs how this grows, and it is a rule before it is anything else:

Bridge first, own later. If something good already exists, connect it. Build your own only when connecting is impossible, or when the user experience is a genuine wall, or when nothing adequate exists at all.

Let me break that into the three things you can actually do to somebody else’s tool.

Depend

Sometimes another project has built a piece of foundation you should not rewrite, and it is designed to be used as a library. The CAD reader in the Storytold suite is the perfect example: DXF/DWG parsing, hatches and linetypes, the document model, printing to PDF and SVG. That is the boring, painstaking, standards-heavy half of a drafting tool. It exists, it is well-built, and it is open. So we depend on it — pin a version, use it behind our own interfaces, and let the people who know that domain keep it excellent.

That is the move that stops us becoming a project that maintains its own font renderer.

Bridge

Most existing tools are not libraries, and you cannot just import them. So you bridge: you speak the open protocols they speak, on both ends, and let them keep doing their job.

This is where open standards earn their place, and it is why I get slightly evangelical about them. Lighting talks sACN and Art-Net. Audio talks AES67. Video talks NDI and ST 2110. Timecode talks LTC and MTC. Control talks OSC and MIDI and MIDI show control. Fixture discovery talks RDM. Every one is an open, well-documented language, and every serious console already speaks the ones it needs to.

So when a venue already owns a lighting console they love, we do not ask them to throw it away. We speak to it. The graph sends its lighting cues down sACN, or over the console’s own protocol, and the console does what it has always done. The rig keeps working. The operator’s muscle memory keeps working. What changes is that the console is now part of the graph — its cues connected to the script, the schedule, the sound and the record, rather than sitting on an island.

This is the promise in one line: you adopt one piece, and the rest of your kit joins up.

Fork, only when forced

Forks are a last resort, and I want to say that clearly, because open source has a bad habit of forking at the first disagreement and then maintaining a diverging copy of somebody else’s work forever. For a project that needs to be sustainable with a small team, forks are how you drown.

So: fork only when the user experience or the integration genuinely demands it, and you have exhausted depending and bridging. Even then, prefer to contribute upstream, or to wrap rather than diverge. Every fork is a bill you pay every month for the rest of the project’s life.

Why this is also the honest answer

I want to be straight about something. “Bridge first” is not only an engineering preference. It is the only way a plan this size survives contact with reality.

If the strategy were “replace everything”, the project would need to beat Adobe, Microsoft, Autodesk and Avid simultaneously, on their home turf, before delivering any value — which is fantasy. But if the strategy is “provide the missing spine, connect what exists, and build only where there is a real gap”, then it delivers value immediately, at the first app, in the first venue.

The lighting app is worth using even if nothing else ever ships, because it is an open, local-first WYSIWYG replacement a small company can actually afford. The sound app is worth using on its own. The stage management app is worth using on its own. And every one of them gets more valuable the more of the family you adopt — but none of them requires the rest.

That is the difference between a platform and a trap. A platform says “buy the whole thing.” We say: buy nothing, use the free app, and if you later want the integration, it is there.

Where the proprietary tools fit

We are not declaring war on the existing tools. A lot of them are genuinely good, and a lot of people make their living using them well. If a designer loves their console, or a venue swears by its CAD package, they should keep them. What we want is for their data to be able to travel — in through open formats wherever the vendor supports them, and through bridging where they do not.

The measure of success is not “how many people abandoned their old tools”. It is “how many venues can now share a single source of truth, whatever tools they happen to be standing in front of.”

The honest caveat

Bridging to a proprietary console you do not control is a moving target. Vendors update, protocols differ subtly by model and firmware, and something that worked on Tuesday can misbehave after a firmware update you did not choose to take. Every bridge is a small, standing maintenance obligation, and a family of bridges adds up.

That is precisely why the architecture is built the way it is — so a bridge is a replaceable part, not a load-bearing wall. If our bridge to a particular console rots, we can rewrite it, or a community member can, without touching the graph or the runtime. The foundation does not depend on any single vendor continuing to be nice.

Right. Enough about strategy. Let me talk about the shapes this thing takes when you actually put it in a building — or in several at once.

Chapter 9: Where It Lives

One of the questions I get asked, when I try to explain this over a pint, is where does it actually run? A server in a rack? A cloud service? A box under the desk?

The honest answer is: all of those shapes, but never requiring any of them. The system scales from one to N, and the “N” is a shape you choose, not a tier you buy.

The four shapes — from the single laptop of the Solo show, up through a Console desk, a Venue with a hub and network nodes, to a Multi-site festival mesh — are the same architecture at different sizes. That matters because it means a company can start on one laptop and grow into a venue without a migration, without a different product, without re-learning anything. You do not buy the enterprise edition to scale up. You just… scale up.

But the more interesting question is not the shape. It is the spaces, because “venue” here is a much broader word than a Victorian playhouse.

The spaces this has to survive

It is a black-box studio theatre. A school hall with a stage at one end and a badminton court at the other. A church with a listed interior and a two-hundred-year-old acoustic. A community centre with one power socket and no rigging points at all. A pub with a corner and a PA. A converted warehouse. An outdoor festival field with generators and a lighting tower. A pop-up in a shopping centre.

None of these should need different software. The same graph, the same runtime, the same apps — just running in a different shape and a different building. The system does not get to assume a proscenium, a grid, or a tamed power supply. It has to be comfortable in all of them, because that is where the shows actually are.

The Shape of a Venue, because it is the one that makes everything else possible

The Venue shape is where the mesh becomes real. A hub acts as the local coordinator, and around the building sit nodes — small, cheap boxes on the network, not dongles plugged into one machine. An audio I/O node near the stage. A DMX node up by the rig. A video output node for the dressing-room feed. A GPIO node for cue lamps and show relay.

Because output is a node on the network, the pipe survives the brain dying. The show keeps coming out of the speakers even if the machine that was telling them what to do has just expired. That single property is what makes failover honest instead of hopeful, and it is worth its own chapter. It gets one.

And the Multi-site shape

A festival. A tour. A group of venues only loosely connected. Each site runs its own local mesh; they share a production through a bridging link, and if that link goes down, no site stops being a site. It just stops exchanging updates until the link returns, and then the graphs reconcile. The festival across four sites is robust to the exact failure that festivals across four sites always suffer.

That is what “scale from one to N” actually means: the same architecture, comfortable on a laptop in a pub and federated across a town. Not four products. One, in the shape you need.

Chapter 10: The Mesh That Refuses to Die

If there is a single idea that separates BackStageOS from “a nice set of apps that happen to share a file format”, it is this one.

There is no server. There is a mesh.

Every machine that is part of a production holds a working copy of the graph. They find each other, peer to peer, on the local network. They exchange changes directly. There is no central box that everything routes through, and therefore no central box whose failure takes the show down. Which is a very different thing from “we have a server and we hope it stays up.”

Local-first means the network is a bonus, not a dependency

The first property is that every device is fully functional on its own. A laptop in the lighting position has the whole graph — not a thin client pulling from a server, but the actual data. It can read it, edit it, compile the show from it and run it, with the network cable pulled out.

This is not a fallback mode. It is the normal mode. The network makes things better — collaborators see each other’s edits, nodes are driven remotely, the show position is shared — but nothing requires it. Pull the cable, and the show carries on. Put it back, and the copies reconcile.

For live performance this is the only sane design. A system that stops working when the network wobbles is a system that will stop working during the show, because the network always wobbles during the show.

Failover: the show does not stop

The second property: if a machine dies, another one takes over.

Because every device holds the graph and the runtime is deterministic, a second machine can be standing by, continuously receiving the show position, ready to pick up the baton. If the primary fails — thermal shutdown, spilled beer, a firmware gremlin — the standby is already at the right position and continues from there. Not from a saved file from twenty minutes ago. From now.

And because the I/O lives on the network as nodes rather than inside the dying machine, the outputs themselves never notice. The node driving the speakers does not care which machine is telling it what to play. It just keeps playing. This is the brain-versus-pipe distinction again, and the reason the I/O architecture is network-native. You can fail over the brain all day long. The pipe keeps flowing.

Remote: two very different kinds of distance

There are two kinds of remote, and treating them the same is a mistake.

Remote authoring is a designer, stage manager or producer working on the show from elsewhere. Latency-tolerant, asynchronous. They can be on a train with no signal and it does not matter. Easy: it is just another peer that syncs when it can.

Remote operation is somebody actually running or observing part of a live show from a distance — a follow-spot operator in a booth, a producer watching from a hotel, a second venue in a festival. This is latency-sensitive and must fail safe. You cannot have a live cue depend on a WAN link behaving.

So the principle is: remote joins the control and authoring plane, never the real-time data plane. A remote collaborator can author, approve, observe, even propose a cue — but a WAN link cannot be trusted to fire a live cue, so a remote operator’s actions are mediated and confirmed rather than wired straight into the show. The venue LAN handles the real-time part; the internet handles the human part. Most of what people want to do remotely is talk and plan and watch, and almost none of it is “press GO from four hundred miles away.”

The communications layer is part of the record

One consequence of the mesh I did not expect to find so compelling is what it does to communication.

A production team talks constantly. In the old world, that talk happens on radios, in WhatsApp groups, shouted in a corridor, and almost none of it is attached to anything. It vanishes. The reason a decision was made is lost the moment it is made.

In the mesh, communication can live in the graph, attached to the thing it is about. The note about the revolve is attached to the revolve cue. The decision about the sound level is attached to the sound cue. You get a peer-to-peer comms channel that is also a record, and a software intercom matrix for the live moments — both part of the same production, both referenced to the same show position. The show’s history is not just what happened but why. For a production that will be revived in two years, that is worth more than almost any feature.

The honest bit about the network

Real networks in real venues are bad. Old buildings with thick walls. Wifi that drops in the corners. Switches with no management. A router somebody’s cousin installed. Interference from the kitchen. A venue where IT is a locked cupboard and nobody has the key.

A peer-to-peer mesh is a beautiful design, but it does not repeal the laws of physics or the state of a venue’s network cupboard. If the network is genuinely terrible, discovery gets flaky and sync gets slow — though the crucial point is that flaky discovery and slow sync do not stop the show, because every machine works offline anyway. The failure is degraded collaboration, not a dead production. That is the whole reason for local-first: so the weakness of the network cannot reach the live show.

But it does mean a venue’s network becomes part of the thing you have to get right — which is not a software project, it is an infrastructure one. Which is another reason VenueOS exists.

Chapter 11: Who Gets to Press GO

There is a question that every production system has to answer, and most of them answer it badly:

Who is allowed to do what?

In a theatre, this is not a formality. The difference between an editor and an operator at 7:30pm is the difference between changing the show and running the show. The person who can adjust a cue in rehearsal is not necessarily the person who should be able to adjust it live. The producer who needs to see the budget is not the same person who needs to see the cue stack. And the person holding the follow spot needs exactly one permission, and it should be trivially easy to give them that and nothing else.

So identity matters. But I want to get to it from an angle that is probably not what you expect, because the way most systems do identity is the exact reason people hate them.

No account. Ever. Not even once.

The first rule is: you never need an account to use the software.

You can install the lighting app, design a show, patch it, program it and run it, with no signup, no login, no email verification, no “continue with” anything. The app works because you opened it. That is the whole onboarding.

This is not just politeness, though it is that too. It is an architectural commitment, because it is what makes the “runs completely on its own” rule actually true. The moment using the tool requires a server to tell you who you are, you have built a dependency, and a dependency is a point of failure. So the default is: no identity required, ever, for the tool to work.

Identity only appears when you want to collaborate. And even then, it is as light as we can make it.

Keys, not passwords

When you do need identity, it is a keypair. A private key that never leaves your device, and a public key that identifies you. No password to forget, no password to leak, no shared secret in a database somewhere waiting to be stolen. You are your key.

You get a key. It is yours. It works offline, because it is local. And it is the thing other people point at when they want to give you access to something.

Sharing is one gesture

Here is the share experience I want, and it is deliberately boring:

Top menu → Share / Collaborate → type the person’s email, handle or invite → done.

That is the entire interaction the user sees. Underneath, three things happen.

First, the system resolves who — it turns that email or handle or invite into a public key.

Second, it issues a grant. A grant is a signed invitation that says: this person may access this production, at this scope (the whole show? one department? one single cue list?), in this role (viewer, editor, operator).

Third, it ships the grant — and then the two devices find each other on the mesh and start sharing.

One gesture. And note the scoping, because it is the important part. You can share a single cue list with one person in view-only. That is an enormously more useful primitive than “admin / member / guest” applied to an entire workspace. It maps to how productions actually work: access is specific, temporary, and per-person.

The roles that matter

Broadly, the roles fall into a few kinds, and they are about intent as much as access.

Viewer — can see, cannot change. The producer, the observer, the person who just needs to know what is happening.

Editor — can change the authored show. The designer, the programmer in pre-production.

Operator — can run the show, and use the override layer, but the compiled show is frozen. This is the crucial one, because it is the difference between designing a cue and firing it.

Approver — can sign off on a change. This is for the moments where a change to a live or armed show needs a human to say “yes”.

And underneath, the grants are per-field and per-department. You do not lock the whole show to make one thing safe. You lock the flown scenery cues and leave the colour palette editable. The lock is as narrow as the risk.

Why this matters for trust

I want to connect this back to the human reality, because identity systems fail when they do not respect how people actually work.

In a real production, power is distributed and situational. The stage manager runs the room. The technician owns the rig. The producer owns the money. The director, during rehearsal, owns the show. And at 7:30pm, on the night, one person is holding the responsibility to actually press the buttons — and that person needs to be able to press them without asking anybody’s permission, because there is no time.

A system that gets this wrong either over-restricts (and gets bypassed, because the operator needs to work now) or under-restricts (and lets somebody scupper a live show by accident). The grant model — specific, scoped, signed, local — is designed to thread that needle. Enough permission for the person who needs it, exactly where they need it, revocable the moment they do not.

The honest bit

The model I have just described is elegant, and elegance is a warning sign when it meets the real world.

Key management is genuinely hard to make friendly. Lose your key, and you lose your identity — we will have to solve recovery without building a central authority, which is a real research-grade problem. Revoking access across a peer-to-peer mesh, where offline copies exist, is not instant the way it is on a server; “you no longer have access” has to mean something even when the person is holding a copy of the graph. And there is a whole category of venues and companies for whom “no central account” will feel suspicious rather than liberating, because they have been trained by twenty years of SaaS to expect a login.

None of these is a reason not to do it. They are the reasons it needs someone who genuinely cares about this problem to work on it properly, instead of bolting on a “just sign in with Google” and calling it done. The identity model is one of the places where this project can either be genuinely better than what exists, or quietly worse. It deserves real care.

And it is worth it, because getting identity right is what makes the next chapter possible — because the same model that lets a person be granted access to a show is what lets a whole venue be understood as a thing in the graph. Let me show you.

Chapter 12: Beyond the Show

Everything so far has been about a production. But every production happens somewhere, and the somewhere has been, for the whole history of the industry, the least documented thing in the room.

So here is the second half of the idea: the same foundation, applied to a building instead of a show. We call it VenueOS.

The venue knows itself

Think about what a venue actually is, and how little of it is written down anywhere useful.

A theatre has spaces — the auditorium, the stage, the wings, the fly floor, the grid, front of house, the dressing rooms, the workshop, the loading dock. It has rigging points, each with a safe working load. It has power, and that power is not uniform. It has a network. It has acoustics. It has sightlines, and a capacity that changes depending on how you configure the room. It has fire systems, access routes, evacuation plans, licensing.

Almost none of that is a document. It is knowledge, held by the staff, in heads, as muscle memory and a laminated sheet and a shrug. When the technician who knows about the tricky rigging point goes on holiday — or leaves — the knowledge goes with them.

VenueOS is that knowledge, in the graph, as a first-class asset. The venue’s own document: its spaces, capacities, points, power, network, constraints. Not an afterthought typed into a production spreadsheet, but the authoritative model of the building itself.

Configurations: a venue is many venues

The thing that makes a venue model genuinely useful — and genuinely hard — is that a single venue is not one room. It is a set of configurations.

End-on tonight, in-the-round on Thursday, a flat floor for the standing gig on Saturday, a cabaret layout for the awards do next month. Each has a different capacity, a different rigging arrangement, a different power usage, different sightlines, different evacuation numbers. The venue is not one thing. It is a family of rooms that share a building.

So the venue graph holds configurations, and a production selects one. The lighting plot is drawn against a configuration. The seating capacity is a property of a configuration. The rigging loads are validated against a configuration. And the fire officer’s numbers, the ticketing system’s numbers and the lighting designer’s numbers all come from the same source — one truth for the building, just as the graph gives one truth for the show.

The production inherits the venue

Here is where it pays off, and it is a bigger deal than it sounds.

A production does not arrive at a building and discover it. It inherits it. The light plot knows the drawing already, because the venue model is in the graph. The rig knows the rigging points and their safe working loads. The power schedule knows what is available where. The accessibility features — the caption display, the hearing loop, the wheelchair routes — are known. No more finding out about the awkward column in the sightline on the first day of tech, because the model knew about it all along, and the plot could have warned you the moment you placed a fixture behind it.

The relationship runs both ways, too. When the show is installed, the venue’s model can record what was actually used, loaded, and where the power actually went — a real record of the production’s footprint, not a guess. Over time, the venue’s graph becomes a history of everything that has ever happened in it.

Why a venue and a show are the same problem

I said earlier that a venue and a production are the same problem wearing different hats, and it is the claim that makes VenueOS more than a bolt-on.

Both are, at heart, a graph of things and their relationships, with a shared timeline and a set of roles. A show has cues on a show position; a venue has states over time — configurations, licences, maintenance, events. A show has departments with namespaces; a venue has systems with namespaces. A show has grants that decide who may do what; a venue has exactly the same need.

So VenueOS does not need a second architecture. It needs the same architecture, pointed at a different object. That is why building the core properly is worth so much. You do not just get a show system. You get the foundation for the building the show is in — and, eventually, for the whole estate around it. A festival is a temporary venue. A tour is a show visiting a sequence of venues. A conference is a production with sessions instead of scenes. A school is a venue with a timetable. All the same graph of spaces, schedules, crews, resources and roles. The foundation is not niche-specific. The apps are. That is the right split.

The honest bit

Here is the difficulty with VenueOS, and it is a proper one: a venue’s model is only as good as the effort that goes into creating it, and venues are busy.

Getting the drawing in is the easy part. Keeping the model true is the hard part. Rooms get reconfigured. Rigging points get de-rated. A wall moves. The person who knew about the corner that always trips the breaker leaves. A venue model that drifts from reality is worse than no model, because people will trust it and be wrong.

So VenueOS lives or dies on whether it is easier to keep updated than to ignore — which means it has to be genuinely useful every day, not just at the start of a production, and it has to make updating almost effortless. That is a product problem, not an architecture problem, and it needs real design, not optimism.

But if it is met — if keeping the model true is easy — then the venue side is, I think, the thing that makes the production side inevitable. Because once the building knows itself, every production that walks into it is better off, for free, forever.

Right. That is the system, and the building it lives in. Now I want to be clear about who all of this is actually for — because a tool aimed at everyone is a tool aimed at no one.

Chapter 13: The People This Is For

I have spent twelve chapters describing a system. Now I want to be very clear about who it is for, and who it is not for, because a tool aimed at everyone is a tool aimed at no one.

The short answer: it is for the productions that the current market has quietly priced out.

Let me be specific, because “small production companies” is a phrase that hides a lot of people.

The community theatre and the am-dram society

Two hundred members, a rented hall, a budget that would not cover a single commercial lighting licence, and a production schedule built on the fact that everybody involved has a day job. They put on two shows a year, they are extraordinary at doing a great deal with almost nothing, and they currently run their entire operation on a spreadsheet, a WhatsApp group and the memory of one long-suffering stage manager.

For them, a production system is not a nice-to-have. It is the difference between the show being held together by one exhausted hero and being actually, robustly run. And because the software costs nothing, it is the first time that possibility has existed.

The school, the college, the youth theatre

A teacher with a laptop, a hall, and forty students. They are teaching production skills to the next generation on tools that are either free-but-limited or licensed-and-unaffordable. A real production system — real cues, real plots, real paperwork, real collaboration — is not just practical. It is educational. It is the thing you would want a student to grow up fluent in, and it currently does not exist in a form a school can use.

The not-for-profit and the charity

An arts charity running a venue, or a touring company, or a community programme. Every pound is accountable, every licence is scrutinised, and the tools that would make their operation run properly are always the first line to get cut, because the money is protecting the work instead of the admin. They are, frankly, the group I think about most, because they are the ones for whom good tools would go the furthest and who are least able to buy them.

The small production company and the indie producer

The people doing it for a living, but small. A lighting designer with their own rig. A sound company with three employees. An events producer running corporate gigs and small festivals. They can afford some software, but never all of it, and they spend their lives stitching together the gaps between the tools they can afford, in the evenings, unpaid.

For them, the pitch is not “free”. It is “you adopt one tool, and the rest of your kit joins up, and you stop doing the integration yourself.”

The venue that is not a theatre

The community centre with a hall. The church with a calendar. The village hall. The pub with a stage. The art centre. These are venues in every sense that matters — with spaces, rigging, power, capacity, configurations, events — and they are run by volunteers or a tiny staff on paper and goodwill. They are the reason VenueOS exists, and they are a massive, invisible, badly served chunk of the live events industry.

The festival and the touring company

The people who need the distributed shape: several venues, a shared company, a running order that has to travel. They are not the bottom of the market, but they are the ones most punished for being distributed, because the software that federates a festival across four sites is priced for an enterprise that only the biggest festivals can afford.

And — the honest part — the people this is not for

I do not think this is for the West End, or for the arena tour, or for the broadcaster with a purpose-built facility. Not because it could not help them, but because they have the money to solve their own problems, they have incumbents deeply embedded, and trying to win them first would be a distraction. If we ever earn our way there, fine. But the point is not to build a cheaper tool for the people who can already afford the expensive ones. The point is to build a first tool for the people who currently have none.

Where it would be used

And this is the other half of “who”, which is where.

The system should be comfortable in the theatre with a proper grid, sure. But it is built, first, for the places that do not have one. A school hall. A church. A community centre with two circuits and a dream. A black box. A field. A warehouse. A function room. A café with a corner stage. A festival site with generators and no wifi.

It should work whether there is one person or forty, one room or five, one machine or fifty. It should work on a laptop in a pub, on a mesh in a theatre, and federated across a town. The same graph. The same runtime. The same apps. Different shapes.

That is the target. Not “the industry” in the abstract. A specific, enormous, underserved population of people who make live events happen with energy, imagination and almost no budget — and who deserve tools that were actually designed for them for once.

Why this framing matters for the project

I want to say one more thing, because this chapter is also a constraint on the whole design.

If the target were the biggest venues, the right strategy would be to add features until we beat the incumbents, and to charge for it. That is a completely different product, and I am not interested in building it.

Because the target is the smallest companies, the right strategy is almost the opposite: make it free, make it open, make it run on the machine people already own, make it work with no infrastructure, and make the first app good enough on its own that somebody with no budget can adopt it tomorrow.

Every design decision in this post makes more sense when you know who it is for. The local-first architecture is because small venues have bad networks. The bridge-first rule is because small venues cannot abandon the one console they own. The free-and-open core is because small venues cannot pay. The “scales from one to N” is because small companies should not have to migrate to grow.

The people come first. The architecture follows. That is how it has to be.

Right. Now, before I get to the hard bit, there is one more thing I have to explain — because it is the question every one of these people asks first, and it is the right question: how on earth does something like this get paid for?

Chapter 14: The Maestro Consoles

By the time I have finished explaining all this over a pint, one question always comes, and it is the right one. “This all sounds lovely,” they say, “but who is paying for it?”

It is the question that kills most good ideas, so let me answer it properly — because the answer is also the part of this I find most exciting.

Free software has to be paid for by something

Open-source software does not fund itself. There are only a few honest ways it survives, and most of them are bad.

You can take venture money, and then spend the rest of your life slowly enclosing the thing you promised to keep open. You can run it on volunteers, and watch it rot the moment the volunteers get tired — the classic tragedy of the brilliant tool maintained by three exhausted people. Or you can find something adjacent that people are happy to pay for, and use that to keep the free thing free.

I want the third one.

The model I keep coming back to

There is one company that already does this, at scale, in exactly the industry next door to ours, and I think they are the template. Blackmagic give DaVinci Resolve away. Not a crippled version — the real thing. They gave Fairlight Live away too. And they are not a charity: they make their money on the hardware. Cameras, switchers, panels, converters, storage.

The software being free is not a loss leader in the grubby sense. It is the point. Free software makes the hardware more useful, and the hardware margins pay the engineers who write the software. The result is that a student in a bedroom gets the same colour tools as a post house, and the company still turns a profit. That is a business that happens to be fair, which is a much better thing than a charity that happens to be fragile.

So that is the plan here. The software is free and open. The money comes from the hardware.

And not just any hardware — the hardware nobody is making.

The stage is still dark

Here is the bit that makes me laugh, in a slightly bitter way. Blackmagic have solved the switcher, the mixer, the camera, the recorder, and the storage. You can build a broadcast of astonishing quality out of their boxes for the price of a family car. And after all of that — after they figured out SMPTE 2110 and thousand-channel audio on a laptop — there is still one thing missing from the ecosystem.

The lights. Nobody has turned the stage lights on.

There is a Blackmagic for broadcast. There is no Blackmagic for the stage. And that gap — a family of live-production hardware that is genuinely good and genuinely affordable, built around an open software core — is exactly the gap I want to fill with the Maestro line.

First, the boring boxes

The least glamorous part of the family, and the part everything else stands on: the nodes.

These are the small rack boxes that put every kind of signal onto the network. A lighting node, speaking DMX over sACN and Art-Net. An audio node, speaking AES67. A video node, taking SDI and 2110 in and out and wrapping it in IP. A GPIO node for cue lamps, show relay, and the general-purpose triggers every venue has and nobody documents. Power over Ethernet, so a camera or a node is one cable for signal and power both.

The trick — the thing that makes this work — is the one I have been going on about all post. The node is a pipe, not a brain. It does not care what the show is; it just carries the signal and, crucially, keeps carrying it when the brain is rebooting. Redundant links, so if a cable is kicked out in the dark the pixels take the other path without anyone noticing. Standards conversion on every input, so mixed frame rates and mixed worlds stop being a manual headache. One fibre where there used to be sixteen heavy cables and a labelling system held together with hope.

Boring boxes. Also the foundation of everything.

Then, the surfaces

This is where a console stops being a laptop and becomes a desk — and where the funding model gets fun.

The Maestro surfaces are modular. You do not buy the whole desk; you buy faders ten at a time and add more as you grow, the way you build a rack. Motorised faders, so the surface can show you the show and not just take your input. And on every surface: proper tactile buttons, because I have never once enjoyed cueing a live show off a touchscreen, and dynamic, legible labels, because the single most common piece of technology in every venue I have ever worked in is a strip of LX tape with “CAM 3” written on it in biro. The panel should know what is plugged into it and say so.

The little things matter as much as the big ones. The fans should be quiet, because a control booth is a place where people have to hear each other, and a rack that sounds like a jet engine is a rack nobody can work beside. The desk should have talkback built in, and the program video on it, so the operator is not juggling three boxes and a monitor to do one job.

And the surfaces come in the shapes a live show actually needs. A lighting console — the missing piece, the desk that finally gets built because it is part of the same family as everything else. A sound surface — a software mixer with real faders in front of it, scaling from eight faders to hundreds of channels, wired to the same graph, so a soundcheck can be run from the rehearsal record without making the band stand there for four hours. A vision surface for video and screens. A shading panel with the colour tools on the desk instead of buried in a menu. And, because I am a magpie, a rack panel that turns the front of the server rack from a blank radiator into a working second control point with a screen and buttons on it.

Why the two together beat either alone

Here is the part that makes this more than a side-business.

The console knows the show because it is on the graph. Not because someone exported a MIDI map, but because the surface and the runtime and the graph are the same system. The fader that says “Door Slam” is labelled that way because the show says so. The light the desk is fading is the light in the plot. The cue the operator is stepping through is the cue in the record.

And — the important bit — the whole thing speaks open protocols and open APIs. Buying a Maestro console does not wall you in. It does not stop you using someone else’s lighting desk, or someone else’s audio, or the gear you already own. It is an on-ramp, not a lock. That is the exact opposite of the silo model, and it is deliberate: a business that survives by making itself useful rather than inescapable is a business I can live with.

And so, the money

Three streams, plainly. First, hardware margins — the nodes and the surfaces, physical products with real, honest margins, and the engine of the whole thing. Second, paid support and integration for the larger venues and companies that want a hand. Third, managed hosting for venues that would rather not run their own hub.

The free tier is not a crippled demo. It is the whole product. The paid things are convenience, peace of mind, and the parts that genuinely cost money to run.

And the consequence I like best: when a large venue buys a rack of nodes and a console, that margin helps pay for the software a village hall uses for free. The institutions subsidise the community. Which is the exact reverse of how this industry currently works, and about time.

The honest caveat

Hardware is a different, harder business than software, and I am not going to pretend otherwise. Supply chains. Certification and electromagnetic testing. Repairs, spare parts, and the fact that a product you cannot service is a product you cannot sell twice. Margins that evaporate if you get the bill of materials wrong by twenty pence. And the hardest trick of all, the one that took Blackmagic years: making something both genuinely cheap and genuinely good. Get that wrong and it sinks the project just as dead as bad code ever could.

It also needs a different kind of person — someone who understands manufacturing, tooling, logistics and certification, not just software. That person exists, and they are not on my call list yet. But it is the most honest funding model I can find, because it asks nobody to pay for the software they use, and it earns its money from something people are glad to buy.

Which brings me, finally, to the part I have been putting off. The honest bit.

Chapter 15: The Honest Bit

Right. Deep breath. If you are still with me, you deserve the truth instead of the pitch. A project that cannot survive an honest list of its own risks is not a project — it is a mood.

Here is what could kill it.

The scale problem

The honest, boring, most likely reason this does not happen is that it is simply too big. Not “too ambitious” — I have argued all post that the ambition is the point. Too big in person-hours. The foundation alone — graph, runtime, mesh, identity — is a multi-year effort for a team that knows what it is doing. The lighting app is a year or two on its own. The sound engine, the video, the venue model, the consoles — each a serious undertaking. And every one of them has to keep working after it ships, forever, because a show does not care that you have run out of money.

The Storytold work makes this plausible in a way it was not before. But “plausible” is not “easy”, and I do not know the timeline. The method is unproven at this scale, and the first year or two is a bet that it works.

The sustainability problem

Free and open software is wonderful, and free and open software nobody can afford to maintain is a tragedy. That is the classic open-source failure: a brilliant tool everyone depends on, maintained by three exhausted volunteers, that eventually rots.

The model I lean towards is open core: the foundation is free and open, and the things that cost real money to run are the things that generate revenue. Commercial support. Hosting for venues that want a managed option. The Maestro consoles I described in the last chapter — physical products with real margins. Whether that adds up to enough to sustain a team is unproven. Getting it wrong in either direction — charging for what should be free, or funding what needs to be sustainable from nobody’s money — would kill the project just as dead as a bad line of code.

The adoption problem

Adoption is the graveyard of better tools. The industry runs on habit and trust. A technician who has used the same console for fifteen years is not going to switch because a newcomer is theoretically nicer. And — the cruel bit — a system whose main benefit is integration has a cold-start problem: it is most valuable when everyone is on it, least valuable when nobody is, and you have to get from nobody to everyone one department at a time. The only answer I have is the one I keep coming back to: make each app valuable alone, so adoption is a series of small independent decisions rather than one giant leap. That is a strategy, not a guarantee.

Reliability, and the safety boundary

A show has one shot. If the software fails once a season, that is not acceptable, because the one time it fails is the time the reviewer is in. Rust helps — memory safety, no quiet crashes. The two-plane architecture helps — the go-live path is narrow and frozen. Local-first and failover help. But none of it is a guarantee, and reliability is not a feature you finish. If we cannot make it boringly, reliably correct, we should not put it in a building where people are watching.

And there is a related limit that matters even more. Anything that can hurt somebody — flown scenery, moving automation, structural loads, crowd, fire — must stay in certified hardware, executed by systems legally allowed to do it. The moment a project like this starts to look like it could be the thing that moves the scenery, it becomes a liability and a danger. So we hold the boundary hard: BackStageOS advises, coordinates, visualises and logs. It is never the certified executor. That is the difference between a tool that helps people work safely and one that gets somebody hurt.

The identity problem

Keypairs, grants, peer-to-peer revocation, no central authority. Elegant on paper, genuinely hard in practice. Key recovery without a central authority is a research problem. Revoking access when someone holds an offline copy of the graph is not instantaneous, and “revoked” has to mean something. And some organisations will find “no central account” frightening rather than freeing. None of this is solved. It is one place where the project could quietly be worse than the status quo if we get lazy, and it deserves a specialist, not a weekend.

The AI problem, in both directions

I have leaned hard on AI as the thing that makes building this possible. That cuts both ways. In one direction, the tooling gets dramatically better and this becomes much easier than I assume. In the other, it plateaus and the build method stops being viable. I am betting on a technology moving fast in a direction I do not control.

There is a subtler risk too. If AI can generate a production system, it can generate competitors. The moat is not the code. It is the domain understanding, the opinionated design, and the trust — which is exactly why the people who understand live events matter as much as the people who write Rust.

The “why has nobody done this” problem

Part of the answer is that the big vendors are financially invested in the silos — per-department, per-seat, per-year, and integrating everything would cannibalise it. Part is that it is genuinely hard and the incentives were never aligned. And part is that attempts do exist, in pieces, and have mostly not finished. So it is not a refutation of the idea. But it is a warning. A lot of people have started down this road and stopped.

The thing that could actually kill it

If I had to name the single most likely cause of death, it is not technical. It is that this stays a blog post. Ideas of this size die because they remain ideas — because the person with the idea never finds the others who could make it real, and never takes the first step that produces something somebody can actually use. Everything in this chapter is a reason to be careful. None of it is a reason not to start. Which means the next move is not mine alone. It is ours. And it starts with a conversation.

I have written this from the assumption that it could fail. If you find yourself reading it thinking “no, wait, you have missed the bit where —”, then you are exactly the person I want to hear from.

Chapter 16: The People We Need

Here is the thing that finally made me write all this down. It was not that I worked out how to build it. It is that I realised I could not build it alone, and that this is fine, because the people I need are not all programmers.

Let me explain what I mean, because “I need help” usually means “I need coders”, and that is not what I am saying.

Code is the easy half to describe and the wrong half to start with

It is tempting to think a project like this needs engineers above all else. And it does need engineers — good ones, who understand Rust and memory safety and deterministic runtimes and distributed systems. There is no version of this without them.

But engineering is the translation step. It takes a clear understanding of a domain and turns it into software. If the understanding is wrong, the software is a very well-built mistake. And the understanding here is not something a programmer can get from a specification, because the specification does not exist — the knowledge lives in the people who have actually done the job.

So the first people I need are not the ones who can write the runtime. They are the ones who can tell me what the runtime is for.

The people who have actually run a show

This is the heart of it. I want to talk to people who have stood in a prompt corner. People who have programmed a lighting desk at two in the morning. Sound engineers who have mixed a show with one hand while fixing a broken cable with the other. Video operators who have watched a laptop die at the worst possible moment. Production managers who have built a budget for a show that changed shape three times. Stage managers who are the actual integration layer for four departments and have the notes app to prove it.

They do not need to know anything about code. They need to know about the job. Because every single chapter of this post is a guess about their world, and a guess from the outside is worth almost nothing.

Specifically, I want to ask them stupid questions like: what actually happens when a cue is late? What is the first thing you reach for when something goes wrong? Which piece of paperwork do you hate most, and why has nobody fixed it? What would make you trust a new system with a live show, and what would make you refuse to? What is the thing that every outsider gets wrong about your department?

That is the raw material. Without it, the whole thing is architecture fiction.

The people who know the standards and the pipes

Then there are the people who know the plumbing — the protocols and standards that keep the industry physically connected. The people who can tell me how sACN and Art-Net really behave under load, what AES67 actually costs to deploy, where ST 2110 is genuinely needed and where it is overkill, how RDM works in practice, what timecode does when it drifts. These people exist in every technical supplier and every large venue, and they are the difference between a system that speaks the language and one that thinks it does.

The venue people

I need the people who run buildings. Venue managers, technical managers, front-of-house leads, box office, the person who knows which socket trips the breaker and which rigging point everyone secretly avoids. VenueOS is a guess about their world in exactly the way the show system is a guess about the stage, and it needs the same interrogation.

The people who have been forgotten

And then there are the specialists who are almost always forgotten by production software, and whose absence tells you everything about how the current tools were built. Accessibility coordinators — audio describers, captioners, hearing-loop technicians — for whom a shared show position would transform what is possible. Music reporting people, who deal with a legal obligation that runs on paper. Wardrobe and wigs. Front of house. The people whose domains are invisible until they go wrong.

If this system is going to be different, it has to be built with them in the room, from the start, not bolted on at the end. And alongside them: designers and UX people, technical writers, people who can translate it, people who can test it on real shows with real stakes — and people who understand the money, because the difference between an open-source tragedy and a sustainable project is usually one person who understands economics.

What the ask actually is

I am not asking anyone to quit their job or commit to years. I am asking for a conversation.

A natter. Half an hour. A call, or a pint if you are local. Tell me about your worst production workflow. Tell me the one thing that, if software fixed it, would make your life genuinely easier. Tell me why the last tool you tried did not work. Tell me I am wrong.

Because the thing I am most confident about is that the knowledge to build this already exists — it is just scattered across thousands of people who have never been asked, and hidden in the tools and habits of an industry that has never had anyone build for it.

That knowledge is the project. I just want to help collect it.

Chapter 17: The Pint at the End

So here we are, back where we started. A pub. A pint. A show that needs to open.

Let me try to say the whole thing in a couple of sentences, the way I would say it out loud.

We have spent thirty years making every department’s tools brilliant and every department’s tools lonely. We have made the good tools expensive and left everyone else to hold it together with spreadsheets, WhatsApp and a stage manager’s memory. And we have reached a moment where — for the first time — the raw materials to fix that actually exist: open, permissively-licensed, same-stack applications, in a language built for reliability, with AI doing enough of the heavy lifting that a small team can build something that used to need a corporation.

What nobody has built yet is the spine. One shared graph of what a production is. One deterministic runtime that runs it. One mesh that keeps it alive when the network does not. One identity model that knows who is allowed to do what. And a family of apps, each useful on its own, that finally know about each other.

I am calling it BackStageOS. And I want to be completely clear: it is an idea. Not a product. Not a company with a roadmap and a logo and a Series A. An idea, with an architecture I believe in, backed by some genuinely encouraging early evidence, and a very long list of things that could go wrong — several of which I wrote down in the last chapter precisely because I do not want to pretend they are not real.

But I also want to be clear about the other thing. I think this has legs.

Not “it will disrupt the entire industry and we will all be rich” legs. I mean something smaller and, to me, more important: I think this could genuinely change things for the small productions. The community theatre. The school. The not-for-profit. The venue that is a village hall with a stage. The designer who works out of a bag. The people who make live events happen on energy and goodwill and a budget that would not buy a single commercial licence.

For them — for us — the gap between what is possible and what is affordable has been widening for years, and it is the people with the least money who end up doing the most manual work. That is the thing I would like to change. Not by building a fancier tool for the people who already have everything, but by building a first tool for the people who have nothing.

The ask

If any of this has landed, here is what I am actually asking for.

If you work in live events — in any department, at any level, in any kind of venue — and you have an opinion about how productions should run, I would genuinely love to hear it. You do not need to know anything about software. You need to be willing to tell me what you know, and to tell me when I have got it wrong, which will be often.

If you build things — Rust, distributed systems, audio, graphics, CAD, protocols, whatever — and something in here made you want to argue or contribute, the same applies. There is a foundation to build and bridges to write and a great many hard problems with no obvious answer.

If you run a venue or a small company and you have read this thinking “we could be the guinea pig for that”, I want to talk to you most of all, because a real production in a real building is the only test that counts.

And if you just want to have a natter about it — no commitment, no job offer, no joining anything — that is completely fine. That is, honestly, the thing I am asking for. Half an hour. A call. A pint. Tell me where I am wrong.

Because here is the truth I keep coming back to. The best ideas I have ever had did not survive contact with a spreadsheet. They survived contact with people — someone who knew the domain, someone who had tried it before, someone who said “no, but what if”. This idea is the same. It lives or dies on whether the people who actually do the work want it to live.

How to get on a call

The easiest way is to get in touch through the blog — there is a contact link, and comments work too. Say “I read the BackstageOS post” and tell me what you do and what you think is broken. I read all of them, and I answer the ones that make me think.

One last thing

I want to end on the honest note, not the triumphant one, because the honest note is the true one.

I do not know if this will work. I do not know if I will find the people, or the time, or the money, or whether the method holds up at this scale. There is a very real chance that this stays exactly what it is today: a long blog post, written by one person, about an idea that was probably too big.

But I have spent years waiting for someone else to build this, and they have not. The tools got bigger and the bills got bigger and the islands stayed islands. And now, for the first time, the pieces to do it properly are lying there in the open, in the right language, under the right licence, waiting for someone to connect them.

It might as well be us.

So — the offer stands. If you have the skills, or the stories, or just the interest, and you fancy a natter about a system that might, if we are lucky and careful and a bit stubborn, change things for the small productions and community groups and not-for-profits who have been priced out of their own industry — then get in touch.

I will get the first round in.