What I sell is not the code

Have your published code copied wholesale and people assume the business has lost. I think the opposite is true, because what I am selling was never the code.

What I sell is not the code

A library can be read in an afternoon. The algorithms are in the papers, the data structures are in the textbooks. Keeping code secret protects far less value than people imagine. Anything worth copying has usually been thought of before.

So what does anyone actually pay for? That it keeps running, that the data has not gone stale, that it does not fall over, that a reply comes when something breaks. They pay for the operated surface. The code is the library; the product is the surface that gets operated. Where to draw that line is the whole of what I am thinking about when I decide what to build.

Code is a blueprint. You can hand the blueprint over and still keep the factory, the monthly shipments, and the replacement of defective parts. That is the part worth guarding.

So jpzip is MIT

jpzip is an API that serves every Japanese postal code as CDN-hosted JSON. The SDKs and the protocol spec are released under MIT. There was not a single reason to put a gate here.

A spec earns its value by being copied. Nobody benefits if turning a postal code into an address comes with my own private dialect attached. Friction is the enemy of adoption. The decision to run with no API key, no registration, and no rate limits was a decision to make "widely used" the value itself.

Where the value lives in jpzip is not the SDK code. It is the operation: normalizing Japan Post's KEN_ALL every month and serving 120,677 entries as static JSON, indefinitely. You can show the entire engine and the operated surface still stays with you. Here, MIT was not weakness. It was honesty.

Sonir: the experience is the product

Sonir has a similar shape. It is an acoustic-measurement app, and the DSP runs entirely on the device. There is no server, so there is no surface to defend across a network in the first place.

The product is the experience of the app, not the secrecy of the code. Recording under the same conditions and comparing under the same conditions. Keeping every measurement aligned through gear profiles, calibration files, and room tags. The value lives in how it feels to use, which is exactly why keeping the code secret would buy so little.

Operating is the hard part

What remains once the code is public: the monthly updates, the delivery that does not fall over, the simple fact of having kept it running for a long time. The genuinely hard work, I have come to feel while building, is operating something well.

If there is a moat, it sits outside the code, not inside it. Showing the engine does not fill that moat. If anything, it is a test of whether the design holds up once it is shown. If you can stand on the operated surface, you can publish the code without worry. That is all I am doing with these two products.

Common questions

If everything is MIT, don't you lose your moat? If you think the moat is the code, perhaps. I think the moat sits outside the code: the monthly updates, the operation that does not fall over, the simple fact of having kept it going for a long time. jpzip's value does not waver no matter who copies the SDK. Putting value where it cannot waver was the design from the start.

If operation is the value, why publish the code at all? Because publishing does not give the operated surface away. It lowers the friction of adoption and turns wide use straight into value. I would rather have the facts that accumulate from being used than the comfort of hiding.

Would a product with a server follow the same approach? The exposed surface changes there, so the line I draw changes too. Sonir and jpzip today do not expose their operated surface across a network. When I build something that does, I will think it through against that surface then. I will write about it after I have built it.