When open source projects close the process, something’s wrong

Twice in recent weeks open source projects have surprised me with their lack of openness. In both cases, developers acted or spoke out in such a way as to intentionally push other developers away from their work.

Case one: Evil icon thieves

The first incident originated with KDE’s Oxygen project, an icon redesign on track for inclusion in KDE 4. Oxygen designer David Vignoni expressed his disapproval that someone outside the project team put together a theme package incorporating the project’s publicly accessible icons. He asked the theme packager to remove the Oxygen icons. Commenters on his blog cheered.

A few days later, Wade Olson of KDE’s Marketing Working Group attacked the theme packager in his own blog post, calling the second-hand theme morally suspect and a violation of the Social Contract. Commenters on his blog cheered as well, and soon began to attack the theme packager in comments on the theme’s page at the art portal gnome-look.org.

The Oxygen icon set was available under two licenses: Creative Commons Attribution-ShareAlike 3.0, or GNU LGPL. Both permit reuse by others. The icons themselves were available via public Subversion repository. There was no license violation or misappropriation, a fact that both Vignoni and Olson affirmed.

Criticism of the second-hand icon theme centered on the notion that the Oxygen project proper should get to release the icons first — since the official Oxygen theme wasn’t dubbed a public release yet, no one else should be allowed to publicly release them either. As one commenter put it, “What about the people who spend two years of work on this? Should not they have the right to publish it in their project before you copy it?”

But the answer is a clear and resounding “no.” When you choose to place your work on a publicly accessible server, and when you decide to place it under a free software license, you give up the right to control what other people do with it.

The secondary complaint — that it is wrong to release the icons before the project declares them “ready” — is entirely incompatible with the “release early, release often” philosophy. Artwork is no different from executable code in either regard.

The fact that free software licenses and the open source development model force everyone to relinquish that level of control is intentional, and is key to making community-driven development work.

Case two: We have enough ideas without you

The second incident cropped up in the GIMP’s User Interface Redesign effort. When I researched the GIMP UI brainstorm in October, I was struck by the stark “us” versus “them” language used in the project.

The project’s wiki repeatedly makes the distinction between the team and everyone else. Creation of new accounts is disabled, so that only the team can make changes.

Under the heading “got ideas?,” where you would normally expect an open source project to invite participation, interested parties are instead directed to submit their comments to the GIMP UI brainstorm. “It is moderated by our team, we listen to what you show us and broaden our horizons.”

But that absence of an open invitation to contribute is topped by direct rejection. In August, an excited would-be participant learned about the project and wrote to the gimp-developer mailing list volunteering to help. GIMP UI Redesign team leader Peter Sikking replied, saying, “I am afraid that I do not have positions open at the moment.”

Elsewhere in that same message, and in other posts to gimp-developer, Sikking’s comments back up the notion that he regards the GIMP UI redesign as his team’s project and his team’s alone, and that that team has no room for anyone else.

Clearly the team members are qualified, but refusing to entertain even the possibility that there are other individuals with worthwhile contributions flies in the face of free software and open source ideals. It is Cathedral thinking, not Bazaar.

Free software acknowledges Bill Joy’s Law — that no matter who you are, most of the smartest people work somewhere else — and opens up the development process for the express purpose of subverting it.

If you are afraid of openness, you have come to the wrong place

The root of both problems is an unwillingness to commit to a truly open development process.

That is explicitly clear in the GIMP UI case, but perhaps less so in the Oxygen case. What directly sparked the ire of the Vignoni and Olson was that an unapproved person did something with the icons. And the distinction between approved and unapproved people stems from Oxygen’s “restricted to us” team of artists.

Through the Internet Archive‘s Wayback Machine, you can examine the Oxygen project’s site all the way back to 2005. Ever since the beginning, two things have remained unchanged: the only images available are “previews” licensed under Creative Commons Attribution-NonCommercial-NoDerivs, and the team does not invite outside participation.

Contrast that with the Tango project, which invites participation openly — in multiple places on its Web site, and through multiple avenues. Contrast the GIMP UI redesign with the GIMP project as a whole, which invites and receives patches, bug reports, and ideas from scores of outsiders.

Which is the way it is supposed to work: software freedom doesn’t begin and end in the COPYING file; it applies to the whole process.

No matter what the Oxygen and GIMP UI teams may think, opening up to outside participation makes a team stronger, not weaker. And it is a key part of the philosophy that created the open source software movement. Listening to other people’s ideas — love ’em or hate ’em — is not optional.

By all objective standards, Vignoni and the other Oxygen artists are doing beautiful artwork, and Sikking and his team have done excellent work pushing the GIMP’s interface in a better direction. But by restricting their respective processes, they are hurting themselves and others. They hurt themselves by shutting out good ideas and by losing available manpower, and hurt others by preventing cross-pollination and by discouraging newcomers from helping out.

I have no doubt that Sikking meant no harm when he told that volunteer on gimp-developer that his help wasn’t needed. I have talked to Sikking and he is a sincere and hard worker. But that volunteer stopped writing to gimp-developer. Tell me: was driving him away worth it? I don’t think so.