I understand why people want Adobe to lose. Expensive subscriptions, frustrating bugs and the feeling that the features you actually need keep arriving too late can make a free alternative feel like a small act of revenge.
But I worry about what comes after that celebration. Recreating the visible parts of a creative tool is one achievement. Building something people can trust with their work for years is a much larger responsibility.
Cloning is understandable, but the promise matters
People want affordable tools, control over their files and a way out of subscriptions they dislike. Those are reasonable demands. Rebuilding an existing workflow can also make it more accessible or give users a better way to do the same job.
ArtCraft is one example behind this discussion. Its PhotoCraft repository describes a clean-room reimplementation of Photoshop in Rust. As of October 12, 2026, that same documentation calls PhotoCraft early alpha and says it is not yet a replacement for daily professional Photoshop work.
That admission matters. An early project deserves room to develop. What feels rushed to me is the jump from recreating a recognizable interface and feature list to treating the established professional tool as already replaced.
The practical test is harder: open a complicated client file, make changes, save it, send it to another editor and reopen it months later. A creator needs confidence in that whole process. Excitement about how quickly software was built cannot supply that confidence by itself.
Maintaining creative software takes real resources
Software needs maintenance even when nobody is asking for a new feature. Operating systems change. Drivers change. File formats have awkward cases. Someone opens an old project with unusual fonts, nested sequences or an effect that behaves differently on another machine.
Fixing those problems takes time, expertise and testing. So does researching a feature that might take months to become useful.
That work needs funding or a dependable commitment of people’s time. A company might pay salaries through subscriptions or licenses. An open-source project might rely on sponsors, paid support, institutions or contributors. There are several possible models, but each has to sustain the work after the launch gets attention.
Adobe’s scale does not excuse every pricing decision or every bug. It does help explain why replacing professional software requires more than reproducing the buttons people recognize.
Fast development can hide unfinished work
AI assistance can make it much faster to get a tool running. That speed also makes it tempting to move on as soon as the main workflow looks convincing.
An editor may get a good result on a short test and then find that a longer project breaks. A save may succeed while quietly dropping something important. A feature may work with ordinary footage and fail with a nested timeline or an unusual frame rate.
Those are the details a polished demo can miss. Creatives usually discover them under a deadline, after they have already committed to the tool.
Early users can choose to help test experimental software. They should know that is what they are choosing. They should not become the unpaid support team for a product presented as ready for professional work.
The standard I care about is whether the builder keeps testing, communicates limitations and fixes failures. That obligation applies to AI-assisted software, traditionally written software and Adobe’s own products.
Shared tools make professional work easier
There is a practical benefit to many people learning the same software. Tutorials, troubleshooting advice, training and shared working habits accumulate around it. An editor joining a team can understand its projects without first learning an entirely unfamiliar environment.
That familiarity helps with hiring and collaboration. A handoff is more useful when the next person can open the project and continue the work, rather than start again from a flattened export.
Creative skills still transfer between tools. Knowing how to edit a conversation matters more than memorizing a menu. But switching software adds practical costs, especially when effects, timelines, fonts or plugins do not travel cleanly with the project.
Dominance also has a cost. A high barrier to entry can protect established companies from competition and make customers dependent on them. I do not think that is a benefit we should preserve for its own sake.
Shared formats, reliable import and export, documentation and interoperable workflows can give us more choice while keeping collaboration practical. Alternatives should take those responsibilities seriously.
The economic concern is real, but the outcome is not inevitable
Imagine someone spends years building a useful paid feature. Another developer recreates much of it for free and charges for a different feature. A third developer recreates both. It becomes harder to earn enough from the original functionality to pay for its continued development.
That is the cycle I worry about. AI can lower the cost of creating a competing implementation, while maintenance, support and compatibility still demand sustained work.
But saying there will be no money left for serious software goes too far. Free software can have a sustainable future. Paid software can fail its users. A competitor can improve a workflow enough that people are willing to fund it.
The concern is whether the funding and commitment survive after the first version. Who will fix the obscure bug six months later? Who will handle the operating-system update? Who will keep old projects usable?
I also worry that, if controllable editing tools become difficult to sustain, more investment could move toward services that generate a finished result for you. Those services may be useful, but I still want tools that let people inspect, revise and make precise creative decisions. That is a risk I see, not a prediction that every free alternative leads there.
We need a middle path
I still think we need companies like Adobe: organizations that can support complex tools, maintain compatibility and invest in capabilities that take time to develop. We also need credible competitors, open-source projects and smaller builders who make those companies respond to users.
I want Adobe to earn its place through better tools, fairer pricing and respect for creatives. I want alternatives to earn trust through working software and continued support. Neither deserves a pass because of its size, its business model or how its code was written.
My concern is what the next generation of creatives inherits. Will they have affordable tools they can control, projects they can hand off and software they can depend on? Or will they keep moving between impressive launches that nobody can afford to maintain?
We need affordable choices that remain dependable after the launch. The responsibility starts when someone trusts a tool with their project.