Developer rewrites seven Adobe apps in Rust and open-sources the code

One developer has rewritten seven Adobe apps in Rust and released the result publicly. It is free, with source code. This comes from a Fireship video dated 12 October 2026, in which the channel's author runs the clones and checks what works. The video's title is blunter than the news itself: "Every app on Earth is now open source, whether it wants to be or not."

What is actually known

The announcement contains few facts, so they are worth stating plainly. There are seven apps. The implementation language is Rust. The license is open and the price is zero. The video is a hands-on test, not an official release with benchmarks. The description does not disclose the names of the programs, the author's name, the size of the codebase, the supported file formats or the degree of compatibility with the originals. Any talk of a "Photoshop killer" is therefore premature: what needs checking is what opens, what is preserved and where things break.

The choice of Rust itself makes sense. The language offers predictable memory handling, good performance and convenient cross-platform builds, including via WebAssembly. For graphics and media tools, where C++ code has piled up for decades, it is a logical target for a rewrite.

Why the headline says "every app"

Fireship's ironic tone hints at a broader trend. Rewriting a mature product from scratch used to mean years of work by a team. Now that coding agents can read specifications, analyze a program's behavior and generate large volumes of code, the barrier is dropping sharply. The announcement does not confirm this directly, and it cannot be claimed that AI was used here. But the phrase "whether it wants to be or not" points to exactly this scenario: the functionality of a commercial product is reproduced without the owner's permission.

That is also the project's main risk. Adobe protects its code, formats, brand and interface decisions. A clone written "by behavior" is legally different from a clone that used decompiled fragments or proprietary assets. It is not yet known which path the author took, and that determines whether the repository survives even a few months.

What to check

Several specific parameters matter when evaluating the project:

• License: MIT, Apache, GPL or something more exotic, and whether it is compatible with commercial use.
• Format compatibility: whether PSD, AI and other working files open without losing layers, effects and fonts.
• Performance: a comparison with the original on large projects, not on a demo file.
• Code provenance: whether the code was written from scratch and whether AI agents were used.
• Maintenance: whether the project has more than one maintainer and a roadmap.

Practical takeaway

It is too early for designers and studios to move their workflows to such clones: without compatibility guarantees, one failed export costs more than a subscription. It is worth cloning the repository, running your typical files through it and noting exactly what does not work. Developers will find something else more interesting: if one person really did build seven apps, that is a benchmark for estimating the effort of rewriting legacy code in Rust. Lawyers and vendors' product teams need to rethink their protection model: when functionality can be reproduced quickly, value shifts to the ecosystem, the cloud, data and integrations rather than the executable itself.

The Fireship video is a good reason to look at the project with your own eyes, but it is better to draw conclusions after checking the repository, not the headline.