Here is a sentence from a project that Eric Raymond and Naval have both used this week to talk about the end of closed software. It is from PhotoCraft’s own roadmap, in an assessment from the first week of October: real Photoshop parity “is still well below 50%.” The team put the chance a professional could switch for daily work at roughly 25 to 35%. On October 10 they re-measured: after about 700 merged PRs, they now put it near 45%, in a 40 to 50% range. Still short of half.

They wrote that about themselves. Read it before you react to the noise.

What PhotoCraft claims

PhotoCraft is an image editor in Rust with layers, masks, styles, filters and real PSD file support. It is open source under MIT or Apache-2.0, and flagged “early alpha.” The README calls it a clean-room reimplementation, “implemented from public specs and observed behaviour only. No proprietary code, shaders or assets.”

Its contributor rules forbid copying proprietary code or using decompiled or leaked sources, and the roadmap says some camera formats stay blocked “by clean-room limits.”

Fairness matters here, to both sides. I can read the rules and the claims. I cannot audit whether they were followed, and nobody can from a README. A strict clean-room process keeps the people who study the original apart from the people who write the new code, and I did not find that separation documented. I did not find evidence it was broken, either.

What Raymond and Naval said

Raymond wrote that “the end of software secrecy is almost upon us,” and described using AI to decompile an old DOS game. An explainx analysis separates what Raymond speculated about PhotoCraft, that it came from decompiling Photoshop, from what the project documents. The project says it worked differently, and the analysis found its development process not documented in that detail.

On October 7, Naval quoted the exchange and wrote: “Models are the last moat in software.” AI can rewrite essays, decompile software and recode it, he said, but models themselves do not want to be “distilled,” meaning copied by training another model on their outputs. He expects more software to “retreat to the server” to resist it.

That is a reasonable bet for a product that is a model. For most software it has a hole. Moving code to a server hides the code. It does not hide the behavior, and behavior is exactly what a reimplementation from the specification copies.

Copyable and not copyable, in PhotoCraft’s own numbers

Take what they got done. Every one of the 169 files in their round-trip test set reopens identically after saving. That is public specification plus hard work.

Now take what the same document says is missing. Fourteen Photoshop tools. No generative AI at all. Plug-ins that do not run Photoshop’s, only sandboxed WebAssembly ones. And my favorite line: many fixes passed their tests but have not been validated by users, and the first days of public use turned up basic breakage their tests had missed.

None of that is in a specification. It is years of real users hitting edge cases and a team fixing them. A competitor can copy the visible behavior in weeks.

My reading, with medium confidence: if your product can be described completely in a document, it can be re-implemented today. What you can defend is what does not fit in that document. The accumulated data of your customers. Integrations into their systems. Edge cases discovered together with them. Support, and the contractual accountability that it works. And the people who know why the product behaves the way it does.

I covered one version of this in the runtime being a commodity, where the workflow is what is left. PhotoCraft confirms it from the other side. Copying an interface is easy. Copying the workflow a professional repeats ten thousand times is not.

If you sell software

Take your product and list what it does. Split the list in two. Column one: what a competitor could rebuild by reading your documentation and using your product. Column two: what they could not. If column two is short, that is next year’s work.

IQ Source’s Technology Partner service is built for software companies that want to keep product design and domain knowledge in-house and buy the construction. That split makes more sense when building gets cheaper to copy, because what is worth protecting is what already sits inside. Start with the two columns. If you want a second pair of eyes on yours, we will go through it with you.

Split what is copyable from what is defensible in your product