Ideas to simplify the project going forward

[probonopd]

The AppImage format has spawned a large open source community ecosystem by now. At the same time, the AppImage project has become complex and unlike the original vision (probonopd/AppImageKit) where everything was meant to be small, simple, and in one repository has created a significant burden for the people maintaining it, including @TheAssassin and me.

So, going forward, I would like to:

• Strengthen the community around the AppImage format, and delegate more of the actual code to that community, instead of trying to do everything inside the AppImage project
• Reduce amount of code maintained inside the AppImage project to a bare minimum
• Reduce complexity of code and repositories inside the AppImage project, and specifically inside the AppImageKit repository, to a bare minimum
• Move everything else to community project(s) outside of https://github.com/AppImage/

My personal itches:

• Remove "complicated" (for me!) dependencies (like C++, CMake, and libappimage) for what remains inside the AppImage project, and specifically inside the AppImageKit repository, and have those things maintained by the community
• Switch to a static AppImage runtime that is more robust against future changes in Linux distributions (like this one)
• For the essential AppImage tools, deliver them as AppImages that bundle everything or as static binaries, to make them more robust against future changes in Linux distributions
• Reduce the amout of stuff that I have to feel somehow respronsible for to essentially the AppImage spec and a very small set of tools
• Have to care roughly only about https://github.com/AppImage/AppImageSpec/, https://github.com/probonopd/static-tools/, possibly parts of https://github.com/probonopd/go-appimage/ in the AppImage project
• Ideally standardize on Golang where possible, statically link where not possible
• Prevent developers from producing AppImages/AppImages that don't "just work" on all still-supported Linux distributions and ideally even FreeBSD which I am pretty much exclusively using these days (e.g., by promoting AppImages that bundle everything)

Result of brainstorming with @TheAssassin earlier this year:

1. Version AppImageSpec; in a new version reduce/remove room for ambiguity
2. Write an AppDir spec. So far we just pointed at http://rox.sourceforge.net/desktop/AppDirs.html but factually started to use non-mandatory conventions like a top-level desktop file used by some of our AppRun implementations. It needs to be clarified whether things like that are MUST/SHOULD/CAN
3. In a new AppImage type, use a "resource system" that allows us to put e.g., update information and similar metadata into AppImages (and possibly other ELF compliant files) in a standardized way that is easy to parse e.g., by file managers (similar to what Haiku does but using a simpler format like .ar?)
4. Document how to create AppDirs/AppImages that bundle everything and that decide at runtime which version of things like GPU related libraries to use; document the tradeoffs between AppDirs/AppImages that bundle everything and "traditional" AppDirs/AppImages
5. Move non-essential repositories out of the AppImage project
6. Move everything except the runtime out of the AppImageKit repository
7. Replace runtime by static runtime
8. Print a message if the AppImage was built on a newer system than the target system on which the AppImage is running (can be approximated e.g., by looking at glibc versions or something like that)
9. Document and support --appimage-target
10. Document system requirements and assumptions, e.g., regarding fusermount

[LTreeshu]

Respect!!!It's a great job!

[kuiperzone]

Good stuff