Introducing Jamie Technology

Most software arrives as a sealed surface. It works, or it doesn’t, and when it doesn’t there is nowhere to look. The layers underneath — the ones that decide how a device boots, how a radio negotiates with a tower, how a scheduler picks the next thread — are the layers you are least likely to be allowed to read.

We think that is backwards, and we are starting a company on that premise.

What we are building

Jamie Technology builds systems software: the infrastructure it runs on, the experiences layered on top, and the developer tools that make all of it tractable. The through-line is not a licence or a business model: it is a property we want the software to have — that a sufficiently curious person can open it, follow it end to end, and come away understanding how it works.

Wherever we reasonably can, we publish the source. Most of what we build will be open source, because software that can be inspected, modified, and learned from is simply more valuable to the community. When something is not open source, we’ll explain why. It may be source-available under more restrictive terms, or it may remain closed if publishing it would compromise the sustainability of the business. We do not keep software closed because we think secrecy is a virtue.

What that means in practice

Four commitments, and we would rather be held to them than praised for them:

• We’ll explain our choices. Open source is our default. When we choose a different path, we’ll explain why.
• Documentation is part of the artefact. An undocumented protocol is not finished. If we reverse-engineer something, the write-up ships with the code.
• The interesting layer is the one we publish. It is easy to open-source the parts that cost nothing to give away. We are more interested in publishing the parts that were genuinely hard to work out.
• We would rather be corrected than be quiet. Building in public means being wrong in public, on a schedule.

Where to look

Our first sustained project is NodeKit, a node graph editor for SwiftUI.

We will post progress here as it happens, including the parts that do not go well.