AM 10.7 adds 5,800 apps in two months and forks a core AppImage tool over a very public feud
The open-source package manager "AM" shipped version 10.7 today. In a single release it tripled its catalog to 9,233 unique applications. The numbers are impressive.
The real news is that AM's creator, Ivan Alessandro Sala (he spells his handle "iVAN"), has now publicly split with the AppImage project over how its build tool works. One release brought growth and a small pile of usability tweaks. It also handed the ecosystem a very public falling-out.
"AM" (sometimes "AppMan") is a Bash-based package manager for AppImages and other portable Linux formats. Sala, an independent developer based in Pompei, Italy, runs the project under GPL-3.0. The goal is to become the default way to manage AppImages, the way APT handles .deb packages or Homebrew handles macOS tools. It ships scripts, not binaries. Each entry is an AUR-style install script that downloads and assembles an app on demand.
What actually shipped in 10.7
The biggest change is an overhaul of the -t template option, which automates generation of install scripts for AppImages hosted on GitHub. That automation is precisely what let the catalog grow so fast, since contributors feed it USER/PROJECT repository lists and AM generates the scripts. The new version caches templates, translates descriptions live via translate-shell, and highlights URLs in color so you can spot them at a glance. Sala says he hits 15 scripts created per minute in his own workflow, assuming no manual corrections are needed.
If you need more than automation, 10.7 quietly piles on other stuff. A parallel-install guard stops you from installing the same app twice at once. The removal command now suggests apps you actually have when you mistype a name. GitHub token input is hidden so tokens don't leak into shell history. And a chunk of basic command-line utilities was sliced out of the core database into a separate am-extras source.
The catalog now holds 9,233 unique apps, comprising 8,819 AppImage packages plus 414 portable programs. Compare that to AM 10.5 in September 2026, which tracked just 3,439 applications. That is a doubling in under two months. On GitHub the project sits at roughly 1,500 stars and 148 forks, with dozens of first-time contributors credited in this single release.
Volume doesn't guarantee quality, and a catalog of 9,000-plus apps holds a fair number of half-baked builds. That tension is arguably the whole point of the feud.
The appimagetool fight
The most consequential thing about 10.7 happened outside the release itself. On October 30, just days before the build shipped, Sala opened issue #138 against the upstream appimagetool maintainers. The tool had begun enforcing stricter validation, converting what were once warnings into hard errors. A build now fails outright, exit code 1, if the source AppDir contains files that aren't world-readable, or if the .DirIcon is missing, broken, or an SVG.
The second check was the real problem for Sala, who builds AppImages at scale by batch-converting pre-existing binaries. His "ArchImage" technique wraps an entire Arch Linux container inside an AppImage so it runs even on a decade-old distro. That scatters files like /etc/gshadow- with 0600 permissions into the AppDir, and the new checks broke his pipeline. He wrote that one workflow ran in a fix loop for 30 minutes before timing out.
"I have about 100 AppImages in my repositories and few time to fix them all... Please convert this warning to just a warning! Do not break processes like this, from nowhere. Keep it simple." — Sala, in issue #138
Sala framed the change as hostile, calling it "a bug introduced intentionally to discourage anyone from adopting the AppImage format."
The maintainers pushed back hard. probonopd, who invented AppImage, said the checks were working exactly as intended. He is sitting on more than 4,000 defective AppImages and does not want more made.
"It is a format for application authors to distribute their applications directly to their end users without needing any intermediaries. AppImage is not intended to 'batch convert' pre-existing binaries from random places." — probonopd
TheAssassin, another core maintainer, took a middle path. The new behavior was less invasive than autofixing things, but some checks had been too strict. Within days, PR #139 relapsed most permission problems back to warnings, and TheAssassin later reverted a spec change that had wrongly implied SVG icons were banned.
The exchange heated up. One commenter called appimagetool a "supply chain hazard" and said he had no interest in using it anymore. Under the bickering lies a real cultural split. The maintainers prioritize quality and format reputation. Sala prioritizes adoption, simplicity, and the freedom to build however works.
Forks all the way down
Rather than wait for reconciliation, Sala went drastic. He switched AM's fallback builder to his own fork of appimagetool. He migrated his classic AppImage projects to Pkgforge's uruntime-based appimagetool, the very tool he is using to build the Firefox AppImage he references in these notes. He also forked type2-runtime as a precaution against future upstream changes.
In 10.7, AM offers a prompt so users can pick between the official tool and the new fallback. The default has clearly shifted, though.
"I would have gladly continued working with the main AppImage project... But this latest incident has made me deeply distrustful of their decision-making... after five years of conflict, I believe it's time to keep my distance." — Sala
He also revealed a personal wrinkle. A new job keeps him far from his PC, and a single pull request took two weeks to merge. That was too long for his standards, given that he feels he wasted time on things that previously worked, which the AppImage leader "suddenly decided to break."
The wider fight for Linux packaging
The AppImage tension here is a microcosm of bigger shifts. probonopd notes a phenomenon AM's numbers confirm: AppImage creation has exploded, driven largely by AI-assisted development of Linux desktop apps. He says he is now handling a few new apps every hour. More apps mean more broken ones, and more pressure on tooling to enforce quality at scale.
There is also the long-running libfuse2 question. Older Type 2 AppImages still need the legacy libfuse v2 library, which modern distros often no longer ship. AM offers a nolibfuse option to convert them with newer tooling, and Sala has spent years trying to convince upstream to adopt it. Same conflict in a new key.
At its core, AM embodies a decentralized, community-driven vision of Linux software. It is an AUR-style database run by volunteers, extensible through third-party "databases," and deliberately resistant to a single point of failure. That contrasts with the more centralized models of Snap and even Flatpak's Flathub governance. The appimagetool fight is, at root, a dispute about who gets to decide the rules.
Head here to download AM 10.7 from GitHub. You can browse the full catalog at portable-linux-apps.github.io.
