Documenting the GIMP’s file format resolves technical and political issues

The GIMP finally has a documented file specification. The free image editor has long been criticized over the fact that its native image format XCF was not publicly documented. Recently the issue came to a head, sparked unintentionally by discussions over the proposed OpenRaster graphics interchange format. Once the argument cooled off, however, an independent developer decided to tackle the problem head on — to the benefit of all.

The gist of the debate was this: some outside of the GIMP project felt that XCF was being intentionally kept closed, and that perhaps the project’s members were attempting to lock out outside developers. GIMP project developers insisted that this was not true; XCF was documented in the source code, and there were several other projects that supported it.

Naturally, that assertion begs the question of whether “documented in the source code” amounts to proper documentation at all. Certainly it is inconvenient when compared with an RFC — but on the other hand, when the target audience is software developers, shouldn’t that be good enough?

GIMP developers also contended that the accusation that they were locking out outsiders was a misunderstanding. Rather, when asked about XCF, the most common response was to discourage its adoption in new projects — not out of fear of competition, but because the format is difficult to work with (not designed for interchange, its structures are tightly bound to the GIMP’s internals), and it is targeted for replacement in the GIMP’s next major development cycle.

Both of those points may be true, but they don’t speak to the needs of a software developer who needs help with XCF today. The difficulty factor is an obstacle, but no one chooses to implement file format compatibility because it’s easy — you implement it because you have to, easy or not. And for someone working on a software project today, the future plans of the GIMP are of little consequence; there is no set timeline for deprecating XCF, and legacy files will persist long after the current GIMP codebase is retired.

File under document

Henning Makholm took matters into his own hands after the most recent flare-up over this issue, writing a specification based on his own knowledge of the XCF-handling code in the GIMP.

Makholm is the creator of xcftools, a suite of command-line utilities for reading .XCF files and converting them to other formats, so he has had to tackle the format directly in the past. He posted his initial draft spec to the GIMP developers mailing list and has made updates and corrections to it based on their feedback. Though still a work in progress, the GIMP project happily added it to the official documentation.

At a practical level, documenting the format will certainly defuse future debates over the GIMP team’s interest in cooperating with outsiders, and will no doubt benefit projects like Seashore and Krita, which read and write .XCF files. But there are lessons to be learned from the entire adventure.

First, publicly documenting data structures and file formats is of paramount importance even when you disagree with it, and even when you have a logical rationale to back your position. All of the reasons asserted at varying times by GIMP developers for not drafting a formal XCF spec were true: XCF was not intended as an interchange format, it can change with ongoing revisions of the GIMP’s internals, and it will be replaced. But none of those reasons vacate the requirements of outside developers. Reading and writing .XCF files is a necessity for some apps, even when it means additional headaches. You cannot predict the requirements and prerequisites of other software projects (present and future), therefore no rationale for skipping the documentation is complete. There may seem to be no consequences to leaving it undone, but the consequences will arise.

A second lesson is that — at least when it comes to free software — technical decisions have political repercussions. This may be different in the proprietary software world, but the landscape of free software is one where every player regards himself as on equal footing with all others, and feels entitled to equal treatment. Thus, the GIMP team’s standpoint that XCF compatibility was not worth encouraging was immediately taken as offensive and argumentative — even though it was purely technical. The row that cropped up during the OpenRaster discussion was only the most recent flare-up of a recurring misunderstanding.

In this case the general harmony of the free graphics community was restored shortly, but not all such disputes are so short-lived. If you are a free software developer, consider your own experience — we can all name a few projects or topics the mere mention of which ignites political reaction or argument. It is regrettable, but one of the costs of functioning as a community.

As for the case at hand, though, the argument seems to be over. Kudos are due to Henning Makholm, not just for the technical benefits others will enjoy thanks to his work on an XCF spec, but for helping to re-establish the amicability that occasionally breaks down among people who feel strongly about their free software.