What Happens to Open Source When the Roadmap Is Written in AI Hours?

Part 1 of 2. This one is about reading the artifact. The next is about what happened when I tried to contribute to it.

---

PhotoCraft is an open-source Photoshop alternative from the ArtCraft project, one of 13 "Craft" apps. Its ROADMAP.md opens with a line like this: alpha, next: beta, ~30 points away and ~1,100–1,800 h. Then it says what the hours are:

Hours are Opus 5.5 agent wall-clock hours for one agent working sequentially, calibrated from this repository's 1,004 merged PRs.

I have read plenty of roadmaps measured in quarters, story points or T-shirt sizes. This one is measured in how long a particular model would take, and it adds that about 80% of the work parallelizes. I wanted to know what that looks like from the human seat. So I read the repo closely, built it on my machine, and tried to contribute. All the numbers below are from the repo as of its 2026-10-13 update.

What PhotoCraft is

PhotoCraft describes itself as "an open-source, clean-room reimplementation of Adobe Photoshop, rebuilt in pure Rust": layers, masks, selections, brushes, filters, type, and PSD files. It's measured against Photoshop 2026, and AGENTS.md is firm about the stack: Rust only, with no JavaScript or TypeScript, and no Electron, Tauri or webview shell.

• UI: native, built on egui (via its eframe wrapper), not a web view.
• Rendering: a GPU compositor on wgpu, the Rust graphics API that targets Vulkan, Metal, DX12 and WebGPU. There is also a CPU compositor, which comes up again below.
• Web build: the same Rust code compiled to WebAssembly.
• Control: a JSON control channel that lets agents drive and screenshot the running app, plus an MCP server and a headless CLI.
• Licence: MIT or Apache-2.0, at your option. The ArtCraft name and logos are trademarks and aren't covered by it.

It's one of 13 "Craft" apps from the ArtCraft project, and it's the one this post is about. It's in alpha.

What the artifact says

Three files carry the idea.

ROADMAP.md gives the headline numbers. Feature breadth is about 76% (menus 628/628, tools 56/68). "Ready for real work" is about 45%. 22 of 25 performance budgets are missed, and 953 issues are open. The stage is "alpha", and the roadmap explains why instead of rounding up. It also gets specific about what is measured and what is estimated: each row is labelled "measured" or "estimated".

docs/gaps.md is the work list: "take the highest-ranked entry that nobody is working on." It has 17 numbered gaps, each with an estimate in agent-hours. G1, PSD fidelity and Photoshop acceptance, is 150–250 h. A Human marker flags "what an agent can't finish alone."

AGENTS.md is the contract for whoever picks up the work. Its title is "guide for AI agents and contributors", in that order.

The "Human" marker is the most interesting thing in the project to me. The plan is written for agents, and people show up as the exceptions: sign-off, hardware, languages a model can't check. That's a different division of labour from "humans write the code and a bot lints it."

What is genuinely good

Setting aside what you think of the premise, the rules in AGENTS.md are well made.

• Never crash. In Rust, calls like unwrap() and expect() abort the program when something goes wrong, so a bad file or a bad command can take down the app and lose someone's work. The rule here is "Non-test code never panics. No unwrap(), expect(), panic!…", and clippy (Rust's linter) enforces it. Every crash fix needs "a small synthetic regression test that panicked before the fix." A panic_hunt test throws adversarial parameters at every command.
• Layers are enforced. cargo xtask layers checks the direction of crate dependencies, so an agent can't quietly break the architecture.
• A CPU compositor is the oracle for the GPU one. When two renderers disagree, there is a reference to settle it.
• Parity checklists are generated and measured, not hand-edited, so the percentages can be checked.

For code that agents write, this is the right shape. The rules are mechanical, they fail loudly, and they don't depend on anyone remembering them. A contributor, human or not, finds out quickly when they've crossed a line.

Next

I'm running this on a tiling Wayland compositor, which the project's reporters seem to mention less often than KDE or X11 (an impression from issue titles, not a count). I built it there, found a bug, wrote the test first, and sent a PR. Part 2 covers how the project handled a first-time contributor, and what I'd copy from this approach.