Who Makes GIMP? The Open Source Community Behind the Project

GIMP is not made by a company. It is built by a distributed community of volunteers from around the world. Understanding how this works - Who contributes, how decisions are made, and how the project is sustained - Reveals a lot about what GIMP is and why it exists.

The Founders: Kimball and Mattis

GIMP was created in 1995 by Spencer Kimball and Peter Mattis, two undergraduate students at the University of California, Berkeley. They wrote the initial version as a semester project for an Advanced Programming Practicum course. What they built in that single semester - A working image editor with layers, a scripting engine, and a plug-in architecture - Was remarkable for students with no commercial backing or professional infrastructure. For more on what GIMP is and its full history, see the What is GIMP page.

Kimball and Mattis released GIMP to the public in January 1996 and continued developing it through their time at Berkeley. After graduating, they handed the project to the community rather than commercializing it. Both went on to careers in technology - Notably, they later co-founded Cockroach Labs, the company behind CockroachDB, a distributed SQL database. Their GIMP work influenced their subsequent thinking about distributed systems and open infrastructure.

Their original decision to release GIMP under a free software license and involve the community from day one set the entire trajectory of the project. Neither of them is involved in active GIMP development today, but their architectural decisions - The XCF format, the plug-in system, Script-Fu, the GTK toolkit - Remain central to GIMP three decades later.

No Single Company - A Distributed Volunteer Project

Today, GIMP has no parent company, no lead organization, and no dedicated full-time paid development staff. The project is maintained by a loosely organized group of volunteer contributors who span multiple countries and time zones. GIMP is free and open source - Licensed under the GNU GPL, meaning anyone can study, modify, and redistribute it.

The core team consists of a small group of experienced developers who have commit access to the main repository and make architectural decisions about the direction of the project. Around this core is a larger group of occasional contributors who submit patches, fix specific bugs, or add targeted features. Beyond that is an even larger community of translators, documentation writers, bug reporters, and users who participate in less technical ways.

This structure is common in successful open-source projects and has both strengths and weaknesses. The strength is resilience - No single company going bankrupt or changing business strategy can kill GIMP. The weakness is that work happens according to contributors' interest and availability, not according to a product roadmap driven by user research and business goals. Features that are technically interesting to contributors get built faster than features that users want but developers find uninteresting.

GNOME Foundation Infrastructure

Although GIMP is not a GNOME application in the traditional sense (it predates the GNOME project and has its own identity), it is hosted on GNOME infrastructure and the GNOME Foundation provides significant in-kind support:

Source Code Hosting

GIMP's source code is hosted at gitlab.gnome.org/GNOME/gimp. GNOME maintains the GitLab instance that powers this, along with the CI/CD pipelines that automatically build and test every commit. This infrastructure would cost significant money to operate independently.

Bug Tracking

GIMP's bug tracker is also on GNOME's GitLab. All bug reports, feature requests, and merge requests go through this system. The issue tracker has thousands of open items representing years of accumulated feedback from users worldwide.

Translation Platform

GIMP is translated into dozens of languages through GNOME's translation platform, Damned Lies. Volunteer translators submit translations of GIMP's interface strings, and these translations are integrated into each release. GIMP supports over 70 languages.

GNOME Foundation vs GIMP Project

The GNOME Foundation does not control GIMP's development direction - It simply provides the infrastructure. GIMP developers make their own decisions about features, releases, and architecture. The relationship is that of a hosted project, not a subsidiary. Think of it as GIMP renting office space from GNOME rather than being part of the GNOME organization.

How Contributions Work

Contributing to GIMP is open to anyone. The contribution pathways vary by skill and available time:

Code Contributions

GIMP is written primarily in C, with parts of the plug-in and scripting infrastructure written in Python and Scheme. To contribute code, you fork the GIMP repository on GNOME GitLab, make your changes, and submit a merge request. Core developers review the change, request modifications if needed, and merge it when it meets the project's standards.

New contributors often start by fixing well-defined bugs (labeled as "good first issue" in the tracker) before attempting larger features. The review process can take time - Core developers are volunteers with limited availability - But well-prepared patches with tests and clear commit messages move through review faster.

Bug Reports

Reporting bugs is a valuable contribution that requires no programming skills. A good bug report includes the GIMP version, operating system, steps to reproduce the problem, and what you expected to happen versus what actually happened. Bug reports with attached example images or screen recordings are especially helpful.

Translations

If you are fluent in a language other than English, you can contribute translations through the Damned Lies platform at l10n.gnome.org/module/gimp. Translation contributions are particularly welcome for less common languages where coverage is incomplete.

Documentation

GIMP's user manual is a separate project from the main application. It is hosted at gitlab.gnome.org/GNOME/gimp-help and accepts contributions in the form of text improvements, corrections, and new content. The manual is written in DocBook XML.

Artwork and Testing

GIMP needs icons, splash screen artwork, and test images for its test suite. Designers can contribute icon sets or UI mockups. Non-technical users can help by testing development builds and reporting regressions - Cases where something that worked in a previous version broke in a newer one.

GIMP.org vs GIMP.cc

It is worth being clear about the relationship between two websites you may encounter:

This site (GIMP.cc) is an independent resource created to supplement the official documentation with practical tutorials, comparison guides, and tools. It is not affiliated with, endorsed by, or in any way connected to the GIMP development team or the GNOME Foundation. For official downloads, always use gimp.org/downloads.

Key Subsystems and Their Origins

GIMP is not monolithic - It is composed of several distinct components, some of which are independent projects with their own development communities:

GEGL (Generic Graphics Library)

GEGL is GIMP's image processing engine, responsible for all color operations, filters, and the high-precision rendering pipeline. GEGL is a separate open-source project with its own repository at gitlab.gnome.org/GNOME/gegl and is used by other applications beyond GIMP. It is written in C and C++ and is the component that enables GIMP's 16-bit and 32-bit per channel processing.

babl (pixel encoding library)

babl handles pixel format conversion - Translating between different color representations (RGB, CMYK, LAB, YCbCr) and bit depths. Like GEGL, babl is a standalone project used by multiple applications. It is a dependency of GEGL.

Script-Fu

Script-Fu is GIMP's built-in Scheme-based scripting engine, originally written by Spencer Kimball and Peter Mattis in the initial GIMP release. It provides access to the full GIMP procedure database from a Lisp-like scripting language. Script-Fu is maintained as part of the main GIMP codebase.

libgimp

libgimp is the C library that plug-ins use to communicate with GIMP. It provides the binding layer between external plug-in processes and GIMP's internal procedure database. GIMP 3.0 introduced a significantly revised libgimp 3.0 with improved Python bindings and a cleaner API design.

How to Get Involved

If you want to contribute to GIMP, here are the specific starting points for each type of contribution:

The GIMP development community communicates primarily through the GitLab issue tracker and merge request discussions. There is also a community discussion page on gimp.org that lists mailing lists, IRC/Matrix channels, and forums where contributors coordinate.

Funding and Financial Support

GIMP does not have a centralized fundraising operation. Financial support flows through several indirect channels:

GNOME Foundation Donations

The GNOME Foundation accepts donations that fund the infrastructure GIMP relies on - Servers, bandwidth, CI/CD systems, and the Damned Lies translation platform. Donating to the GNOME Foundation at gnome.org/donate indirectly supports GIMP.

Individual Developer Sponsorship

Some active GIMP core developers accept individual sponsorship through GitHub Sponsors or similar platforms. This allows users and organizations who benefit from GIMP to directly support the specific people doing the development work. These arrangements are voluntary and do not grant sponsors any influence over development decisions.

Employer Support

Some GIMP contributors do development work as part of their employment at companies that depend on GIMP or open-source graphics infrastructure more broadly. This represents a form of indirect corporate support for the project.