Debating icon names and ad-hoc specifications

Freedesktop.org's Icon Naming specification became a center of contention for several days in May courtesy of a heated discussion on the XDG mailing list. At issue was whether the specification should enumerate a minimum contingent of icons for system-wide use, a comprehensive list, or something in between. The debate also raised questions about how the specification is crafted and, perhaps, what it means in light of Freedesktop.org's founding principle not to legislate standards.

The Icon Naming specification is a hierarchical set of named icons meant to be provided by a desktop environment like GNOME, KDE, or Xfce. The standard named icons include common functions such as opening and closing documents, and reusable components like the desktop's help browser. The specification defines a set of eleven contexts into which icons are grouped: actions, animations, applications, categories, devices, emblems, emotes, international, MIME types, places, and status. An application can take advantage of the system by referencing the named icons rather than having to embed its own copy of each icon it needs.

A related specification, the Icon Theme specification, shows how artists can create complete implementations of the set to install alongside the system's default. The Desktop base directory specification describes where in the filesystem applications should look for the icons provided.

Seeking icon specification specifics

Like many Freedesktop.org specifications and projects, the Icon Naming specification is discussed on the XDG mailing list (the name of which reflects Freedesktop.org's original name: X Desktop Group). May's debate was prompted by a request from PulseAudio's Lennart Poettering to add four new icon names to the devices context, representing common audio hardware devices (audio-headset, audio-headphones, audio-speakers, and audio-handsfree). Rodney Dawes, maintainer of the specification, countered with a different proposal he said would better fit the specification's existing hierarchy and not introduce unnecessary icons: a new icon for headset, replacing audio-card with speaker, making headphones a secondary icon named speaker-headphones, and dropping the audio- prefix from all of the names. Poettering defended his initial request, arguing that the audio- prefix should stay, and that speakers, headsets, and headphones were distinct enough form factors that they deserved separate icon names. When several weeks passed without a reply from Dawes, Poettering announced that he was going to use his proposed icon names anyway, bypassing the specification to talk directly to the distros, and suggested that Dawes hand over maintainership to someone else — reigniting the debate.

The back-and-forth then shifted from the original topic into a discussion of how the specification is maintained and updated. Critics of Dawes accused him of rejecting all requests for new icon names, and not listening to the needs of application developers. Dawes contended that the developer community seemed unwilling to provide input into the process; because the specification is intended to represent a community consensus, accepting a single developer's request for new icons without discussion would rapidly cause it to break down under a mountain of single-purpose icons. He had asked for input from other audio developers, he said, but received none.

Jakob Petsovits suggested that the specification did not need a formal process or maintainer at all, and that "if an icon is used by projects across different desktops and has a semantically clean purpose then that pretty much makes it 'approved' on its own." Marius Vollmer argued for creating another specification describing an "extra icon set" that would be separately maintained. Dawes then replied that such an extension mechanism already exists in the form of addenda to the Icon Naming specification, and expressed frustration that the community did not know of or take part in it.

Finally, talk turned to the purpose of the specification itself, with Dawes arguing that it "is a base specification, designed to be the minimal list of icons that everything else can fall back to. It is not going to have every little icon that ever random developer thinks needs to be in the spec for their app to have that icon. It doesn't make sense." Brian Tarricone responded that "the 'goals of the specification' (whatever the hell that means; inanimate documents don't have goals) are irrelevant. The needs of the community and of the people who will use the specification are paramount" and that "the goals of the spec don't fit what the developers need."

Tarricone's position seemed to be that the specification should try and be as inclusive as possible, trusting that the developer community would not suggest conflicting, confusing, or an excessive number of icon names. Dawes repeatedly pointed out that he was not opposed to adding new icon names, but felt that the developer community needed to weigh in on the merits of suggested additions, or else the specification would not reflect the community's consensus.

Thus, in different ways, both viewpoints do want the specification to be shaped by the community itself. They disagree on how best to implement that goal. Several pointed out that part of the problem is that icon themes by their nature involve both programmers and artists, two groups with very little overlap. Even among developers, who actively participate in the XDG list, individual change requests rarely elicit much response. As Tarricone asked in a subsequent message, "how do you get proper consensus for something where only one person seems to be working on a particular problem and needs icons for it?"

Participants in the discussion agreed that the informal mailing-list-only process was inefficient and led to proposals ending up in long-term limbo. Some suggested using wiki and bug-tracking software to manage proposed changes, but there is not yet a concrete plan for how to smooth out the process.

Standards, specifications, and open source developers

The diverging opinions about the purpose of the Icon Naming specification are limited to that specification alone, but they reveal another stumbling block — that despite producing specifications, Freedesktop.org is not a "standards body" in the traditional sense. Participation in any Freedesktop.org project is voluntary, and there is no attempt to enforce adherence to any specification it produces.

The group was founded in 2000 by Havoc Pennington (then at Red Hat) as a neutral place where projects and companies working on X-based desktop environments could meet to collaborate on common tasks. It currently provides hosting for several important Linux projects, including D-Bus, HAL, the X.Org server, and Compiz. Its other main activity, however, is producing cross-project specifications for system and application behavior. There are currently 50 specifications listed on the site's wiki, covering topics from desktop launchers to X extensions.

The Freedesktop.org mission statement emphasizes that it is not interested in "blessing" or legislating formal standards — a claim important enough to bear repeating on its specifications page. The fact that it produces specifications but makes no attempt to dictate their adoption places the group in an ambiguous position. As Pennington commented, "Freedesktop is basically a place people can document any consensus they may reach on interoperability. No rough consensus and it pretty much just gets stuck."

That may be frustrating for the participants, but for a completely voluntary-membership organization, it is unavoidable. In contrast, the Linux Foundation's Linux Standard Base has a formal workgroup, specification process, and certification.

Ted Gould, who weighed in on the confusion over the Icon Naming specification, summed up the Freedesktop.org distinction. "The reality is that most 'Freedesktop Specs' aren't really anything like IEEE Specifications or anything that typically is described using the word 'specification.' Really they all are more agreements on the way things do work in the code on the various desktops. But, in a truly open source way, code rules, so the only thing that really matters is who's implemented it as a vote yeah or nay on the spec." As the Icon Naming specification discussion recently showed, that process may not always be smooth.