PhotoCraft and the price of free software in the AI era
An independent Photoshop reimplementation raises a bigger question: when AI makes software easier to build, who pays for reliability, maintenance and the next breakthrough?
Original editorial illustration by Telli.sh. The diagram presents the article's argument, not project measurements.
A familiar creative application, rebuilt in public and available without a subscription: it is hard not to feel excited about that possibility. For students, occasional creators and people priced out of professional tools, free access can mean the difference between having an idea and actually making it. But excitement is only the beginning of the story. If AI substantially lowers the cost of recreating software, it also forces us to ask who will keep developing the capabilities that are worth recreating.
PhotoCraft makes that question concrete. It is an independent Rust image editor in the ArtCraft family, built with AI-assisted development and designed to work with layered Photoshop documents. The important shift is that a small team can now attempt a broad, technically demanding application in public. Its advertised capabilities make the ambition tangible; the remaining question is whether they hold up in the documents and workflows readers depend on. PhotoCraft project, Phoronix, October 7, 2026
PhotoCraft rebuilds familiar editing workflows
PhotoCraft is an independent project, not an Adobe release. Its repository advertises layers, masks, adjustment layers, editable type, vectors and PSD/PSB workflows. As of the project's October 10, 2026 parity assessment, it remains alpha: the maintainers estimate readiness for professional work at about 45%, and say PSD exchange with Photoshop is not yet reliable enough for beta. Those are the project's own measurements and estimates, not an independent evaluation. PhotoCraft repository, parity assessment, October 10, 2026
Reimplementing Photoshop-like behavior is different from publishing Adobe's source code. PhotoCraft describes its approach as a clean-room reimplementation. A familiar interface can make an alternative easier to learn, but compatibility still depends on the documents, plug-ins, fonts and production pipeline a reader uses.
The source is offered under MIT or Apache-2.0 terms, while notices, bundled assets and branding require separate attention. A permissive code license does not grant rights to every trademark or artwork in a repository. Anyone redistributing the project should read the actual license and attribution files; reverse-engineering rules also vary by jurisdiction. License and credits, attribution file
Compatibility is a workflow, not a menu count
Feature breadth is only one part of compatibility. The project's October 10 assessment reports 133 of 256 Photoshop-authored PSD oracle files passing its current fidelity check, and describes open gaps in performance, stability, interaction and ecosystem support. These are useful signals of active testing, but not independent ratings of every workflow. PhotoCraft parity assessment
Imagine a designer testing an alternative with a simple poster. It opens, a text layer remains editable and the export looks correct. That is meaningful progress. Now imagine the same designer receiving a client document with unusual color profiles, linked assets, plug-in effects and carefully tuned typography. The second task asks a different question. It asks whether years of accumulated expectations survive an exchange between people, machines and versions.
Start with duplicate files and one narrow workflow. Try a layered poster or product image: preserve editable text, adjust a mask, export a PNG, then reopen the saved project and PSD in the tools your collaborators use. For client work, add a representative color profile, linked asset or effect before trusting round-trips. Check how unsupported features are handled so missing behavior does not silently flatten or discard information.
That is a practical way to explore an ambitious alternative without risking the original files. For a hobby image, the threshold may be a clean export. For paid work, the threshold includes repeatability, recovery, file exchange and support when something goes wrong.
Free access creates real opportunities
The strongest argument for open source begins with the people who could not participate before. A recurring subscription may be reasonable for a studio but difficult for someone producing a school project, a community newsletter or occasional illustrations. An accessible editor lets those users practice, make mistakes and develop skills without turning every month of learning into a financial decision. That matters even if the tool initially covers only a fraction of professional needs.
Source availability adds another kind of access: local communities can improve language support, accessibility specialists can inspect barriers, and institutions can preserve a useful version. Those benefits depend on contributors and maintainers having the capacity to do the work; an open license alone does not deliver them.
Competition also changes the questions that established vendors must answer. If an alternative handles everyday tasks well, customers can ask more clearly what a premium product adds: deeper capabilities, better support, dependable collaboration or an unusually strong ecosystem. A subscription is no longer justified merely by the absence of alternatives. It must explain the value of the continuing relationship.
There is no need to pretend that all users want the same arrangement. Some people value an offline tool they can keep indefinitely. Others want managed updates and support. A small organization may combine both. Open source is valuable partly because it increases the available choices, rather than forcing everyone into a single theory of how software should be funded or delivered.
A cheaper replica does not make innovation costless
My concern is not that users can get useful software for free. That is a benefit worth protecting. The concern is that reproducing an existing workflow and discovering the next valuable workflow are different investments. A replica can learn from a product that already solved many hard design problems. Someone still has to identify new problems, make uncertain bets and absorb the cost of experiments that fail.
The same distinction applies after the first release. Maintaining compatibility with a changing operating system is not a one-time task. Neither is investigating a rare data-loss report, responding to a vulnerable dependency or checking an obscure import format. AI may assist these jobs, but assistance does not make responsibility disappear. Somebody must decide what is correct, verify it and remain accountable when a fix creates another problem.
An ecosystem can look healthy while relying on a small amount of invisible labor. Users see new features, not necessarily the exhausted maintainer triaging hundreds of reports. An organization may happily depend on free code while never funding its upkeep. If cheaper reproduction reduces revenue without replacing the mechanisms that support maintenance, the result could be more available applications and fewer dependable ones.
That is a risk, not a prediction that open source inevitably destroys innovation. Open projects can create businesses, receive grants, attract sponsorship and share development across organizations. Commercial projects can also neglect maintenance or lock users into poor service. The relevant question is not which label guarantees virtue. It is whether the funding model rewards the work users need over time.
What should users pay for when code is abundant?
Original editorial framework. The three responsibilities can belong to one team or several; none is automatically completed by generating code.
One answer is to separate access to a capability from the assurance around it. A free local editor may offer substantial value. A supported distribution might charge for signed releases, tested upgrades and help with difficult files. A collaborative service could charge for storage, permissions, synchronization and recovery. These are possible business models rather than PhotoCraft's current product offerings.
I find the infrastructure layer especially important. A feature can be impressive in isolation and fragile as part of daily work. Reliable service requires backups that can actually be restored, clear access rules, observable failures and a plan for incidents. When several people depend on the same information, the cost of an unavailable or inconsistent system can exceed the price of the feature itself.
But "infrastructure" should not become a vague excuse for another subscription. A provider should be able to describe what it operates, what happens when it fails and how a customer can leave. Storage without export is a potential trap. A backup promise without a recovery process is incomplete. Trust is earned by concrete commitments and repeated delivery, not by putting the word "managed" next to open-source code.
Service and ownership can coexist. Users can retain standard-format files and local copies while paying for dependable collaboration. Businesses can contribute improvements upstream while earning revenue from operating the software. The healthiest arrangement may make the source available and the service optional, with switching costs that come from genuine convenience rather than withheld access to a person's own work.
Personal software could become more practical
If implementation becomes less expensive, smaller problems become worth solving. A photographer might want an interface organized around one repeated export task rather than a universal tool palette. A teacher may need a review screen tailored to one class. A research group may prefer a workflow that keeps a specific validation step visible. These are plausible directions, not a claim that a personal agent can already build every application safely.
Previously, a requirement this narrow often became a spreadsheet, a macro or a compromise inside a larger product. AI-assisted development could make it easier to turn those compromises into purpose-built interfaces. That would change the role of customization. Instead of selecting among settings someone anticipated, a user could describe a workflow and help shape a small piece of software around it.
The difficult part is preserving the qualities that make shared software useful. A personal modification can become incompatible with future updates. A generated helper might handle the happy path and mishandle deletion or recovery. A workflow that makes sense to its author might be impossible for a colleague to understand. Personalization therefore needs boundaries, documentation and reversible changes, not just an enthusiastic generation loop.
There is also a distribution of expertise to consider. A technically confident user may inspect a modification; another person may be unable to distinguish a harmless UI change from a program that reads files or sends data elsewhere. If personal software spreads, understandable permission models will matter more, not less. Making creation easier must not silently transfer every maintenance and security burden to the person requesting the tool.
Claude Code Mods offers a small glimpse of that direction
Claude Code Mods is a concrete example of a tool becoming a customizable environment. Anthropic's documentation describes JavaScript or TypeScript handlers that can change interface elements and behavior within Claude Code. That is more than asking the model to answer in a different tone: it allows small pieces of code to reshape parts of the working experience. Official Mods overview, checked October 12, 2026
The same documentation warns that mods are not sandboxed and run with the user's permissions. That makes the example useful in two ways. It points toward increasingly personal software, and it shows why personal software still needs a trustworthy foundation. A convenient modification is not automatically safe simply because an AI helped write it.
For me, PhotoCraft is interesting less as a verdict on one incumbent than as a question about the next software economy. Open source can put powerful capabilities into more hands. At the same time, funding discovery, maintenance and reliable operation remains necessary. As AI makes interfaces easier to recreate and customize, I expect software to become more personal, while the shared infrastructure underneath it becomes more important. Claude Code Mods is a modest but revealing glimpse of that future: the tool can change around its user, but somebody still has to make the ground beneath it dependable.
Keep a reviewable record of your AI research
For readers collecting their own research notes, Telli.sh is one optional place to organize material and derived summaries. Create a note workspace.