Free (as in Freedom, not as in Beer) Beauty Squadron

Nicholas Reville has an interesting post yesterday at miro (”The Free Beauty Squadron“) about the challenge of good interface design which has classically plagued open-source projects, especially on the desktop:

Open-source software projects tend to be initiated and built exclusively by programmers and their focus usually lies, as it should, with core features and technology. But a project that is exclusively driven by programmers usually won’t have an elegant user interface.

This post started as a comment on his blog, but got too long so I moved it here instead.

Reville proposed fixing this problem, in part, by establishing a “Free Beauty Squadron” which would connect designers and open source projects looking to improve their interfaces:

Here’s how a Free Beauty Squadron might work. A volunteer committee of experts asks projects to apply, explaining why they are a good candidate for an overhaul and what they hope to accomplish. When a project is selected, a paid designer flies out to meet one or more team members in person and begins developing a plan. Over a 6 week period, the designer creates mockups and interfaces flows for a new user experience, all in consultation with the coders. When the designer is done, the project has graphic files, documentation of a new UI, and an implementation plan to quickly or gradually put the new interface in place. The designer reserves 2 weeks for future consultation with the project as issues inevitably arise during implementation. The committee then sends the designer to their next project.

While I’m with Nicholas on the problem, I think this is the wrong direction in which to aim for a solution.

It’s not just that it is difficult to add design to the surface of a fully formed application (while beauty may be skin deep, true usability goes right through to the core), or that the interactions between new designers and existing Open Source projects might be difficult, or that the projects would need to take time to implement the new designs (these are logistical problems which Nicholas admits and offers what he sees as reasosonable workarounds to).

The problem is that it sets up the idea that “design work ” (specifically he seems to be targetting visual design, which is only a subset of a broader set of design skills from which many open source projects could benefit) is so fundamentally different than other kinds of production that it requires a different funding mechanism to get produced.

Put another way, why pay the designers and not the coders? Or, perhaps more accurately, why attract and encourage designers differently than coders?

Is it just that designers don’t need the tools open source produces?

Are the varied and sundry motivations which drive coders to contribute to open source somehow not relevant in the design community?

Many contributors to open source are actually paid employees of large companies using the software in question - don’t any of those patrons have designers?

I would assume many designers might appreciate the opportunity to build their portfolios with design solutions to real world challenges - for which their compensation might be reputation and experience, rather than cash.

Part of the problem must be in the code-centric nature of many open source communities, in which your ability to hack is the (only) measure of your worth - but that has been evolving in many projects to include broader skillsets.

So how does the open source community broadly engage with the designers in our midst, without having to create a separate charity brigade?