The fork tax

Forking an editor is a wonderfully efficient way to ship the first screenshot. You inherit years of keyboard shortcuts, file trees, language tooling and familiarity. Put a chat panel on the right and the product already looks finished.

The invoice arrives later.

Every upstream security release becomes a merge. Every deep interaction you change becomes a patch you own. More importantly, the inherited editor keeps voting on what the product is. A document becomes a text file with decorations. An interface becomes source code with a preview. An automation becomes another configuration language. The host keeps pulling every problem back towards code.

That is sensible when the product is an editor. It is disastrous when the product is a project.

Miton was built from the ground up because Chat, Canvas, Writer, Automation and Code need equal architectural standing. Chat is the constant. The other workspaces split out when the work needs a specialised instrument, then merge back into the same project. No inherited shell gets to declare itself the centre.

This choice is not heroic. It is expensive. Editor depth takes time. Platform behaviour has to be earned. Familiar details that arrive free in a mature fork must be designed, implemented and tested. Anyone who needs a particular editor extension tomorrow should use the editor that already has it.

But ownership compounds too. Miton’s routing system can understand the same project as its goals and permissions. A workflow can become a document and a code change without crossing a product boundary. The safety model can sit beside the runtime that invokes tools. The interface can be designed around agentic work rather than accommodated inside an extension slot.

The fork tax is not merely merge conflict. It is the cost of spending years arguing with somebody else’s answer to “what is this product for?” Miton chose the slower bill: build the answer once, then own the direction.