Replicatorblog's response made very good points. Though I think the FLOSS community should start by appreciating the huge differences between developing code and developing design.
I am a designer and a FLOSS guy and I have actually researched this subject a lot, both in practice, in writing and in teaching. The essay I written for Smashing Magazine a few months ago might be relevant in this context, it is called "The Case For Open-Source Design: Can Design By Committee Work?"
http://www.smashingmagazine.com/2010/09/01/the-case-for-open...
I identified three major challenges:
1. Scratching an Itch
2. Granularity
3. Encoding/Decoding
I go through a few interesting positive examples for collaborative design processes and then try to propose some tips to making it work. Finally it's about a mix between leadership and openness, but this leadership has to be respected even if it does not translate to algorithmic metrics (like Google's A/B Testing of 41 shades of blue, more: http://stopdesign.com/archive/2009/03/20/goodbye-google.html)
If you prefer to go through this essay as a 20mins video presentation, you can check it here:
http://vimeo.com/18761002
I start at 00:27:50
I realize this is a pretty long and complex answer for what sounds like a simple question, but in my experience this is really revealing the boundaries of the Open Source collaborative process as we know it and it will not change unless we help this model mature.
Thanks :)
I'm actually working with illustrator Galia Offri on another project along the same line as this thread. It is called Wikipedia Illustrated (http://WikipediaIllustrated.org) and is trying to address a similar question: "Illustrators, how do we get you guys to contribute to Wikipedia?"
I am a designer and a FLOSS guy and I have actually researched this subject a lot, both in practice, in writing and in teaching. The essay I written for Smashing Magazine a few months ago might be relevant in this context, it is called "The Case For Open-Source Design: Can Design By Committee Work?" http://www.smashingmagazine.com/2010/09/01/the-case-for-open...
I identified three major challenges: 1. Scratching an Itch 2. Granularity 3. Encoding/Decoding
I go through a few interesting positive examples for collaborative design processes and then try to propose some tips to making it work. Finally it's about a mix between leadership and openness, but this leadership has to be respected even if it does not translate to algorithmic metrics (like Google's A/B Testing of 41 shades of blue, more: http://stopdesign.com/archive/2009/03/20/goodbye-google.html)
If you prefer to go through this essay as a 20mins video presentation, you can check it here: http://vimeo.com/18761002
I start at 00:27:50
I realize this is a pretty long and complex answer for what sounds like a simple question, but in my experience this is really revealing the boundaries of the Open Source collaborative process as we know it and it will not change unless we help this model mature.