I don't want to revel in the fork's demise for any reason besides relief that it didn't end up splitting GIMP's contributors and community in a way that would have harmed both projects.

> we could not find contributors willing to step up and help with non-code tasks like moderating communication channels

Gotta say though it feels ironic that they couldn't find enough people to be comment janitors considering the whole thing was based on wanting people to stop saying a particular word.

> As a result, we struggled to scale the project to match increasing demand.

‘Glimpse didn't fail; it was actually too popular’?

Before the weird sex stuff, "gimp" was an insulting term for a crippled person. The fact that it's so long out of common use for that purpose that a lot of folks don't realize that is perhaps an argument for not taking it too seriously. On the other hand, disabled folks are certainly among the most oppressed and abused and in ways that aren't well-understood by most folks, so a decent person should be pretty careful about using language that could be demeaning. I dunno. It feels like an archaic term that ought not have any power today, but what do I know?

the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)

That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.

[1] https://sqlite.org/cli.html#sqlite_archive_support

The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).