GIMP 3.3 from the GNOME GitLab mirror: what the development branch actually contains

What GIMP is, and who the 3.3 branch is for

GIMP is the GNU Image Manipulation Program, a raster editor written in C. The repository under discussion is a read-only mirror of https://gitlab.gnome.org/GNOME/gimp, so patches and issues belong on GitLab, not on the mirror. The README opens by naming the branch directly: "This is an unstable development release in the GIMP 3.3 series." That sentence is the whole audience definition. The 3.3 branch is for people who want to test the next series, report bugs against it, or hack on the code. It is not the branch you hand to a designer who needs to finish a file today. The stable releases live at https://www.gimp.org/downloads/, and the README points there rather than shipping a binary from the mirror. Documentation sits at https://docs.gimp.org/. Contributors are routed to https://developer.gimp.org/, with three named starting points: setting up a developer environment, the coding style, and submitting a first patch. Note the README does not describe the feature set of 3.3 at all. Anyone arriving from a search for what is new in this branch will not find it in the README; the release notes are the place that would carry it, and none were retrieved for this branch.

The architecture visible in the tree: app, libgimp, pdb, plug-ins

The top-level entries tell you how the program is split. app/ holds the core application. libgimp/ and its siblings (libgimpbase, libgimpcolor, libgimpconfig, libgimpmath, libgimpmodule, libgimpthumb, libgimpwidgets) are the libraries that plug-ins link against, separated by concern rather than bundled into one blob. pdb/ is the procedural database, the interface layer through which plug-ins call into the core. plug-ins/ holds the bundled plug-ins, and extensions/ sits alongside it. menus/ and data/ carry UI and resource definitions, desktop/ carries desktop integration files, and modules/ holds loadable modules. The build is Meson: meson.build and meson_options.txt at the top level, with build/ for build support files. That layout matters if you intend to write a plug-in, because the split between libgimp* and the core is the boundary you code against, and the pdb is the surface you call. It also matters for packaging: the libraries are separate build products, so a distribution can split them. The repository also carries a long tail of ChangeLog.pre-* and NEWS.pre-* files, which are historical records kept in the tree rather than deleted. They are not part of the build; they are how the project preserves pre-git and pre-3.x history.

Building GIMP 3.3 from the mirror: where the instructions actually live

The README does not contain build steps. It says: "For detailed installation instructions, see the file INSTALL." The tree lists INSTALL.in, which is the template that becomes INSTALL during configuration, so a fresh clone may not have INSTALL yet. That is the first thing to check before you assume the instructions are missing. The same pattern applies to contributing: the README says "If you want to hack on GIMP, please read the file devel-docs/README.md." So the two files to open first are INSTALL and devel-docs/README.md. What the README does give is configuration paths, and those are concrete. Interface customization for a GTK app lives under `${XDG_CONFIG_HOME}/gtk-3.0/`, specifically settings.ini and gtk.css, and GIMP additionally reads its own stylesheet.

Configuring the interface and keybindings after install

Once a build is running, the README documents two override points that are specific to this version. The first is a GIMP-only stylesheet, so you can restyle the application without touching the shared GTK configuration. The second is the shortcuts file, which is how you rebind keys without going through a preferences dialog. Both paths are versioned by the 3.3 directory name, which means a future branch will read a different directory and your customizations will not silently carry over. That is worth knowing before you invest in a heavily customized setup on a development branch.

Where GIMP 3.3 is the wrong tool, and what to use instead

The README states plainly that this is an unstable development release. That is the limitation, and it is not a small one: unstable means the branch is where changes land before they are considered ready, so behaviour and file formats can move under you between builds. If you need a raster editor for production work, the README's own answer is the downloads page, which serves stable versions. If you are deciding between GIMP and Photoshop, the honest framing is that GIMP is a free software raster editor with a plug-in architecture exposed through the pdb, while Photoshop is a commercial product; the README makes no claim of parity and the repository contains no comparison. A more useful alternative for engineers is to skip the GUI build entirely and call GIMP's libraries from a script through the pdb, since that is the documented extension surface. The trade-off is real: the pdb route gives you automation without the editor, but it also means you inherit the same unstable-branch caveat if you build against 3.3 rather than a stable release.

Maintenance, upgrade cost and the licence question

The mirror is not archived, and the last push was on 2026-09-21, so the branch is receiving commits. That tells you the code is moving; it does not tell you the branch is stable, and the README explicitly says it is not. Upgrade cost on a development branch is the directory rename: customizations written to `${XDG_CONFIG_HOME}/GIMP/3.3/` are scoped to 3.3, so a move to the next series means re-checking gimp.css and shortcutsrc rather than assuming they apply. On licensing, the repository carries both COPYING and LICENSE at the top level, and the GitHub-style metadata reports the licence as NOASSERTION, meaning it was not automatically identified. GIMP is a GNU project, so COPYING is where the actual terms are; read that file rather than the metadata field. Nothing here is legal advice, and the NOASSERTION value is a reason to open the file, not a reason to assume anything about the terms.

Editorial conclusion

Adopt GIMP 3.3 only if you are testing against the development branch or building from source on a GTK 3 system; the README calls it an unstable development release, so it is the wrong base for anything you have to support. For everyday editing, take a stable release from the downloads page instead. Before either, open INSTALL and devel-docs/README.md in the checkout, because the README delegates the build and the contribution rules to those two files rather than spelling them out here.

Frequently asked questions

Official sources

1. GNOME/gimp on GitHub
2. Issues
3. Project website
4. README