{"slug": "the-clones-are-coming-home", "title": "The clones are coming home", "summary": "ArtCraft's Brandon Thomas is using Claude to build open-source Rust recreations of Adobe and Microsoft Office applications, including PhotoCraft, WordCraft, GridCraft and DeckCraft, with PhotoCraft's 11 October roadmap reporting all 628 menu items wired up but readiness for real work estimated at about 45%. WordCraft's own roadmap lists charts, SmartArt and embedded objects being silently dropped from documents, and a TechRadar review on 10 October found working basics alongside performance problems and broken workflows. PhotoCraft's public test corpus pins synthetic Photoshop-generated reference documents so the AI-written code can be checked against an independent standard rather than its own invented expected answers.", "body_md": "There is something extremely funny about watching people use AI to rebuild the software they are tired of renting.\n\nThe promise was that these models would make other people’s expensive expertise available on demand. Writing, illustration, programming: describe what you want and the machine will produce something resembling it. Now people are asking for the applications too.\n\nPhotoshop. Illustrator. Word. Excel. On my own computer, with the source code, please.\n\nBrandon Thomas’s [Crafting Apps](https://getartcraft.com/apps), from ArtCraft, use Claude to attempt just that. The Rust recreations of Adobe’s creative tools have been joined by [WordCraft, GridCraft and DeckCraft](https://www.tomshardware.com/software/microsoft-office/creator-of-free-adobe-clones-unveils-open-source-microsoft-office-excel-powerpoint-and-word-replications-autodesk-tools-and-other-subscription-based-services-may-come-next), targeting Microsoft Office. They have native desktop builds, familiar interfaces and public repositories.\n\nI love the ambition. The announcements of Adobe’s demise can wait.\n\nPhotoCraft’s [11 October roadmap](https://github.com/storytold/photocraft/blob/main/ROADMAP.md) reports all 628 menu items wired up, while estimating readiness for real work at about 45%. WordCraft’s [own assessment](https://github.com/storytold/wordcraft/blob/main/ROADMAP.md) lists charts, SmartArt and embedded objects being silently dropped from documents. A command appearing in a menu tells you much less than a client’s file surviving an edit.\n\nThe [Hacker News discussion](https://news.ycombinator.com/item?id=49958850) mixes detailed failure reports with accounts of simple work going surprisingly well. Later replies describe improvements without agreement about professional usability. [TechRadar’s 10 October review](https://www.techradar.com/pro/one-dev-is-recreating-7-adobe-apps-in-rust-for-free-so-i-tested-it-out) found working basics alongside performance problems and broken workflows. Builds are changing quickly enough that reports need a version and a task attached.\n\nSome of the hostility is deserved. Grand claims invite people to test them. Dismissing GIMP, Krita and LibreOffice also grates when their maintainers spent years doing work these newcomers promise to finish in weeks. Enthusiasm for an escape from Adobe does not require pretending the escape route is ready.\n\nWhat interests me is how that route might get built.\n\nA mature application gives its imitator a considerable advantage: somebody has already worked out what is useful. Its interface records product decisions; its files preserve behaviour that written specifications may leave ambiguous. Where access is lawful, the original can help establish both what to build and whether it works.\n\nPhotoCraft’s [public test corpus](https://github.com/storytold/photocraft-corpus) makes this concrete. Scripts create synthetic documents in Photoshop and save them with Photoshop’s own rendered composite. PhotoCraft can then check its rendering and file handling against those results. The reference data is pinned so it cannot quietly change what counts as success.\n\nAn agent that writes code and invents its own expected answers can congratulate itself on the same misunderstanding twice. An independent reference gives it something to disagree with.\n\nChoosing good tests still takes expertise. A synthetic document cannot stand in for every client project, and a correct image tells you little about how a brush feels on a tablet. But a discovered difference can become a repeatable check. Fix it, keep the check, and the next attempt has less to rediscover.\n\nThat collection could outlast the application. If PhotoCraft stalls, a successor could inherit code and an increasingly useful account of Photoshop’s behaviour. A properly licensed compatibility corpus could help established alternatives too. This need not be a bet on one team finishing an entire suite.\n\nAccess to the original is already a complication. As checked on 12 October, [VectorCraft’s instructions](https://github.com/storytold/vectorcraft/blob/main/CLAUDE.md) forbid contributors from running, scripting or measuring Adobe applications, even to create synthetic test files. They cite Adobe’s terms and direct contributors towards public documentation and permitted user material. PhotoCraft’s corpus still describes using Photoshop for reference results. The repositories’ approaches differ; their documents may be changing at different speeds.\n\nAdobe’s [terms, section 17](https://www.adobe.com/legal/terms.html), expressly include “monitoring or tracking the inputs and outputs” to recreate an application within their prohibition on reverse engineering. I have not established when that wording appeared or that it was a response to ArtCraft.\n\nAs implementation gets cheaper, reliable examples of correct behaviour become more valuable. Restricting observation can make a replacement harder to verify without anybody copying the original source. Part of the competition moves towards who is allowed to find out how software works.\n\nThe contract does not settle every legal question. In [SAS Institute v World Programming](https://curia.europa.eu/jcms/upload/docs/application/pdf/2012-05/cp120053en.pdf), the EU court held that program functionality was not protected expression under the Software Directive, and addressed a lawful user’s ability to study its operation under specified conditions. That does not decide ArtCraft’s position, but the distinction between a vendor’s terms and the law matters.\n\nDocumentation helps without resolving everything. Adobe [publishes a Photoshop file-format specification](https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/), despite a claim to the contrary in the HN thread. Its introduction distinguishes the format of the data from its interpretation. Knowing where a field lives is only the beginning of reproducing what Photoshop does with it.\n\n“Clean room” needs similar care. The intended separation is between studying behaviour and copying implementation. [WordCraft’s rules](https://github.com/storytold/wordcraft/blob/main/AGENTS.md) permit observing Word with synthetic documents while prohibiting inspection of its implementation and copying its assets. Those rules describe a process; they cannot establish what a pretrained model has encountered.\n\nEqually, an unknown training history does not prove a particular output infringes anything. “Claude has seen everything” is speculation. “We told Claude to be clean-room” is not a provenance audit.\n\nThe copyright irony is strong enough without exaggerating it. In [Bartz v Anthropic](https://cases.justia.com/federal/district-courts/california/candce/3%3A2024cv05417/434709/231/0.pdf), the June 2025 ruling found the training use at issue to be fair use while rejecting the justification for a separate library of pirated books. Acquisition, training and generated outputs raise different questions. Adobe, meanwhile, [says Firefly is trained on licensed and public-domain material](https://www.adobe.com/ai/overview/firefly/gen-ai-approach.html). Neither fact supports a blanket claim that all models were necessarily trained illegally.\n\nThe funny part is an industry selling machines that make other people’s accumulated expertise cheaper, then finding its own expensive products candidates for the same treatment. Software has no natural exemption.\n\nThe model vendors might profit handsomely. Anthropic can collect money from people trying to reduce their Adobe bill. We could end up moving spending towards an even smaller group of suppliers. Democratising development does not automatically democratise the infrastructure behind it.\n\nLocal software gives users something durable from that exchange. An editor built with a hosted model can keep working after its developer stops paying the provider. Moving a layer or saving a document need not require another inference request. The intelligence is rented during construction; the resulting program can be kept and shared.\n\nMaintenance still costs money, as I have [argued before](https://lord.technology/2026/01/31/what-becomes-expensive-when-code-becomes-cheap.html). Open source already offers this bargain. AI could make more applications affordable to bring into it, provided someone finishes the work.\n\nFamiliarity has value here too. Users have spent years learning their tools.\n\nA photographer’s knowledge of masks, shortcuts and presets belongs to the photographer. An alternative that requires relearning every interaction charges them in time before they know whether it can do the job. A compatible workflow lets that investment travel. The [Office discussion’s objections about retraining costs](https://news.ycombinator.com/item?id=50043110) are also an argument for making alternatives familiar.\n\nCloning can preserve bad decisions. But a familiar starting point lets users choose which parts to change. They can keep what they understand and fix what irritates them.\n\nIt is tempting to suggest everyone simply build the five per cent of Office they use. Then somebody emails them the other ninety-five per cent.\n\nYou choose the features you invoke, but not everything embedded in an incoming document. A narrow interface can still need extensive compatibility machinery underneath. Losing an object you never intended to edit is enough to disqualify an application.\n\nI expect adoption to begin where work has clear boundaries: a finished image export, a document generated from a known template, a batch conversion whose output can be checked. Exchanging complex, editable projects will be harder. Those are plausible footholds, rather than claims about what these builds can reliably do today.\n\nOrganisations also buy collaboration, identity, support and somebody to call when work stops. Replacing Word does not replace Microsoft 365. Smaller departures still matter, though. A credible alternative lets a team move one workflow, reduce some seats or refuse an unwanted change. A vendor can lose bargaining power long before it loses every customer.\n\nMaking open tools dependable could itself support a business. A design studio might pay for validated imports of its project files, predictable releases and responsibility for breakages. Several studios could share that expense. Collectively maintaining a reliable editor seems far more plausible than every designer nursing a private Photoshop fork.\n\nThat suggests a better use for some of the enthusiasm. Fund a public collection of troublesome documents. Pay for regression testing and careful releases. Existing open-source maintainers have years of knowledge to contribute. Treating them as obsolete because their applications took longer to build would waste precisely the expertise these projects need.\n\nNor will cheap imitation hurt only incumbents. A small developer who discovers a useful workflow may face copies sooner too. I do not want original product work to become unviable while the token supplier gets paid on every attempt to reproduce it. Paying people for thoughtful software is compatible with wanting the freedom to leave it. The difficulty of leaving should not be something a vendor is entitled to preserve indefinitely.\n\nCloning might also be a useful intermediate step. [WordCraft exposes its shared command system](https://github.com/storytold/wordcraft) to both the interface and automation tools, including MCP. A familiar word processor can become a programmable document engine.\n\nImagine adding a tool that prepares your particular client pack, checks it and exports the required files. The engine could be maintained collectively while that small addition serves one organisation. Your need would no longer have to be common enough to win space on Microsoft’s roadmap.\n\nThat is the democratisation I want: more people able to decide what gets built. Some will write changes, some will direct agents, and many will pay somebody competent. Software they are allowed to alter gives all of them somewhere to start.\n\nFor ArtCraft, the next convincing evidence will be people repeatedly completing real work, files surviving exchange and fixes staying fixed after the launch excitement fades. Another hundred menu items will tell us less.\n\nI want these projects to become good enough that leaving is practical. I want useful tests and components to survive failed attempts. And I would love to see more of our software budgets go towards improving tools we can keep.\n\nThe industry sold us AI as a way to make expensive work reproducible. It would be very funny, and very welcome, if users got to take that promise home.", "url": "https://wpnews.pro/news/the-clones-are-coming-home", "canonical_source": "https://lord.technology/2026/10/11/the-clones-are-coming-home.html", "published_at": "2026-10-11 19:00:00+00:00", "updated_at": "2026-10-12 20:21:15.880812+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-tools", "developer-tools"], "entities": ["Brandon Thomas", "ArtCraft", "Claude", "PhotoCraft", "WordCraft", "GridCraft", "DeckCraft", "Adobe"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-clones-are-coming-home", "markdown": "https://wpnews.pro/news/the-clones-are-coming-home.md", "text": "https://wpnews.pro/news/the-clones-are-coming-home.txt", "jsonld": "https://wpnews.pro/news/the-clones-are-coming-home.jsonld"}}