Actually, code also requires unity. If many developers work on the same project, they have to adhere to the same overall goals and to the same coding standards; if this is not done, you can see it directly from the code.

Software projects have this amazing ability to be reborn, but the costs involved with rebirth are sometimes prohibitive. It’s even worse when that rebirth results from pieces cut out of past attempts. What you then get is Frankenstein’s monster.

The cost of design failures and the risks involved when that happens is much larger because it’s the first thing users see, and it’s something they’ll remember.

Design takes a similar approach. Ask any professional web designer and they will often tell you it’s critical that the initial conversations of the birth of a design be kept to as small and as focused a group as possible. In effect, these people that the designer collaborates with should represent the heart and unity of the company or community. As the design is born and evolves over time with each iteration, more and more people are introduced to it and can help with it’s evolution. Nearing it’s beta stages, it can be opened internally to the company or community or possibly even to select groups of the external public. Finally when the design reaches it’s maturity and is completed, it is finally “let go” into the world to interact with everyone on it’s own accord, yet at the same time its sustainability is dependent upon many people (i.e. people within the company or community it was formed).

Last but not least though, it is important to realize that a design is never “done”. It is always something constantly evolving and changing, just as we as individuals are constantly evolving and changing based upon the interaction and feedback we receive from the world around us.

PS. BTW you might be interested in reading Permaculture, Principles & Pathways Beyond Sustainability, by David Holmgren. The design principles within it relate remarkably well to designing for the Web and the communities within it because permaculture relates to designing within ecosystems and the Web itself is a digital ecosystem.

The issue gets harrier when you take a broader definition of “design”, to include the system architecture of software. Open-source software works, but it’s not always pretty—either in the UI or the underlying code base.

Collaboration is hard.

Although the code may all be open source, the vision and intention creating it is stuck in our heads. The more you can communicate (and agree upon) strong conventions from the start, the better off you’ll be. Perhaps all you can do is hope for the best.

I think its easy to say, that design in opensource can’t coexist with programming. And I think this is not helping anyone, but surely voicing a lot of uninformed opinions.

As long as there is a product which has an interface, it will need great design. Of course design is subjective, but in many discussions the arguments of colors, shape and position can be based upon design arguments. No programmer, can get around these – and I have yet to see a good design argument not succeed in such a discussion (it requires some stamina).

Having spend the greater deal of the past two years in the Drupal community as UX-Team member, I care to say that we are just getting started. And creating a great user experience is a slow, but insightful process. We could say secretive is better, but realistically for large applications you have to justify your every-move – for Apple and other companies it might happen within their own compounds, it still happends. And I think open source, truly exposes the need for design to get better at communicating their choices (thus making the community more informed as a whole).

I’d love if you take a read at http://www.bojhan.nl/reflections-on-a-d7ux-project/ especially Design Culture. I think that voices my thoughts on all of this.

As a sidenote, I’ve been hearing a lot of hubbub lately about “Gov. 2.0,” and admitting that I don’t really understand it, the effort does seem to suffer from overt, narrow (those two words almost seem like oxymorons, don’t they) focus on open standards (is it a blue, power-to-the-people sensibility?). Not ready to argue yay or nay to the political implications (not understanding it enough), it’s still my observation that this effort might suffer from a one-community-does-all approach, where leadership might be more effective in some cases.

Yes, sometimes the fervent fundamentalism of an individual has its place, Steve Jobs or whoever. But the problem there, as you’ve pointed out, is a certain short sightedness, or rather a lack of willingness to _loosen_ ones firmly held vision.

Personally, I see one of the defining characteristics for nurturing open source projects as an ability to loosen. Chris, I am again inspired by your infectious willingness to get your hands dirty steering the fine line between idealism and pragmatism.

In the spirit of recursion, perhaps open source’s religion is losing-religion?

If you have the right vision, it’ll pay off. This isn’t anything against openness or community involvement. This doesn’t mean that you shut yourself off to the community. There are just certain things that work better if you hand them to a person or a very small group of people with a cohesive creative vision. With regards to freedom, people are aways free to fork the software if their vision differs so much from yours, but the idea is, like you said, that they’ll value the improved experience so much that their design quibbles will seem trivial.

WordPress struggles with maintaining the right balance. Within the last year or so, we’ve been heading in two directions: soliciting more design feedback, but making more design decisions within the inner circle. Compare WordPress 2.7 to the more ad hoc assembled WordPress 2.3 — I’m not saying WP 2.7 is anything approaching Applesque design nirvana, but it’s undoubtedly an improvement.

I think these two things have to go hand-in-hand. There’s a temptation to sequester yourselves in an ivory Skype swarm tower and pelt the community with your edicts, from beyond earshot. You have to judge which things require a cohesive vision from the inner circle and which things should be left to the general community to decide.