For an 20+ year old desktop application written in C, GIMP has a a very good code-base. This is thanks to it always being a priority of the developers. The migr

For an 20+ year old desktop application written in C, GIMP has a a very good code-base. This is thanks to it always being a priority of the developers. The migration to GEGL for image processing and preparation for GTK+3 forced a lot of updates across the application (and was a lot of work). Probably unknown to many here is that GIMP also has an API. Actually two, the C API and the PDB API (Python/Scheme/etc). This is used by third-party plugins that extend/customize GIMP for various purposes. Many of the existing plugins that people use are quite old, and often poorly/unmaintained. Keeping these plugins working is the main consideration for why the GTK+3 migration was not done in mainline until 2.10 was released, since GTK2->GTK3 is a breaking change in the C API. Of course C, GObject and GTK+ are probably not what anyone today would choose today as the base of a graphical image manipulation application. Other UI frameworks would have a larger mindshare, and other programming languages might require less skill/care to code in. Allowing UI elements to be written in another language than C89 would probably make things more accessible to contributors, in my opinion. But a two-language split in an application has disadvantages also. Preserving compatibility with existing projects that users have is also something that takes a good bit of resources and can restrict movement a bit. It was the last big piece to solve for getting GIMP 2.10 with high-bitdepth support ready. But breaking peoples project files tends to make users unhappy... To keep old files alive and rendering correctly there is a fair amount of legacy image processing code being kept around, but it is factored to not be that much of an issue.