Losing my religion

Last January, writing on the problem of open source design, I said:

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Lately, I’m feeling the acute reality of this sentiment.

In 2005, I wrote about how I wanted to take an “open source” approach to the design of Flock by posting my mockups to Flickr and soliciting feedback. But that’s more about transparency than “open source”. And I think there’s a big difference between the two that’s often missed, forgotten or ignored altogether: one refers to process, the other refers to governance.

Design can be executed using secretive or transparent processes; it really can’t be “open” because it can’t be evaluated in same way “open source” projects evaluate contributions, where solutions compete on the basis of meritocratic and objective measures. Design is sublime, primal, and intuitive and needs consistency to succeed. Open source code, in contrast, can have many authors and be improved incrementally. Design — visual, interactive or conceptual — requires unity; piecemeal solutions feel disjointed, uncomfortable and obvious when end up in shipping product.

Luke Wroblewski is an interaction designer. He recently made an observation about “openness” that really resonated with me:

I read this quote last week and realized it is symptomatic of a common assertion that in technology (and especially the Web) “completely open” is better than “controlled”.

“But we’ll all know exactly where Apple stands – jealously guarding control of their users […] And that’s not what Apple should be about.” –TechCrunch

Sorry but Apple makes their entire living by tightly controlling the experience of their customers. It’s why everyone praises their designs. From top to bottom, hardware to software -you get an integrated experience. Without this control, Apple could not be what it is today.

He followed up with a post on Facebook’s design process today that I also found exceedingly compelling.

I worry about Mozilla in this respect — and all open source projects that cater to the visible and vocal, ignoring the silent or unengaged majority.

I worry about OpenID similarly — an initiative that will be essential for the future of the social web and yet is hampered by user experience issues because of an attachment to fleeting principles like “freedom” and “individual choice”. Sigh.

I’m not alone in these concerns.

When it comes to open source and design, design — and human factors, more generally — cannot play second fiddle to engineering. But far too often it seems that that’s the case.

And it shouldn’t be.

More often there should be a design dictator that enters into a situation, takes stock of the set of problems that people (read: end users) are facing, and then addresses them through observation, skill, intuition, and drive. You can evaluate their output with surveys, heuristics, and user studies, but without their vision, execution, and insane devotion to see through making it happen, you’ll never see shit get done right.

As Luke says, Most people out there prefer a great experience over complete openness.

I concur. And I think it’s critical that “open source” advocates (myself included) keep that at top of mind.

. . .

I will say this: I’m an advocate for open source and open standards because I believe that open ecosystems — i.e. those with low barriers to entry (low startup costs; low friction to launch; public infrastructure for sustaining productivity) — are essential for competition at the level of user experience.

It may seem paradoxical, but open systems in which secretive design processes are used can result in better solutions, overall.

Thus when I talk about openness, I really mean openness from an economic/competitive perspective.

. . .

Early today I needed access to a client’s internal wiki. Having gone without access for a week, I decided to toss up a project on Basecamp to get things started.

When I presented my solution to the team, I was told that we needed to use something open source that could be hosted on their servers. Somewhat taken aback, I suggested Basecamp was the best tool for the job given our approaching deadline..

“No, no, that won’t do,” was the message I got. “Has to be open source. Self-hosted.”

I asked them for alternatives. “PHProjekt“. Double Choco Latte. I proposed Open Atrium.

Once again, as seems all too common lately, more time was devoted to picking a tool rather than producing solutions. More meta than meat. Worst of all, religion was in the driver’s seat, rather than reality. Where was that open source pragmatism I’d heard so much about?

Anyway, not how I want to begin a design process.

Ultimately, I got the access I needed — to MediaWiki. So, warts and all, we’ll be using that to collaborate. On a closed intranet.

In the back of my head, I can’t help but fear that the tools used for design collaboration bleed into the output. To my eyes, MediaWiki isn’t a flavor that I want stirred into the pot. And it begs the question once and for all: what good can “open source” bring to design if the only result is the product of committee dictate?

12 thoughts on “Losing my religion”

  1. I don’t quite see how that’s much different than any other aspect of software development. Open source, I mean The source code, encourages creativity but quite usually in a secretive fashion in a first step. Once a project becomes heavier, more looked at, it automatically slows down some of this creativity.

    As you say yourself in your previous poste:

    > So the problem with open source design is not the feedback (designers et al should be grateful when it comes) but with the ego issues that are wrapped up in how feedback is delivered and how it’s received. And these are ultimately social issues.

    Well that can be said to other parts of software development. I’m not actually buying the idea than design would be some kind of distinct, grand, area where only by working on your own makes your work any better on the long run. To me doing so is essential only in the first step, where mocking up an idea is very personal, but so is prototyping your code.

    > Thus when I talk about openness, I really mean openness from an economic/competitive perspective.

    That’s fine but open source and economic openness are orthogonals. They may meet but usually in a one way fashion “we use open source software to create open economy but we don’t actually produce better, more creative open source software”.

  2. Chris,

    While I agree with your general message here, I think you could go a bit deeper into both how dictatorship is practiced in open source, and how principles of design (e.g. software design) are decided on by those dictators.

    For example, isn’t Linus the dictator of the kernel? And does the Apache project, say, allow committees to decide on the core architecture (i.e. design) of the httpd server?

    I’m not convinced that the open source model is incompatible with user experience design. The problem is that the dictators of successful open source projects tend to be engineers, and they don’t appreciate the value of this type of design.


  3. It’s takes guts for an Open Source developer to say “no, the community is wrong, we’re doing it this way”… but that’s often what you should do, if you really care about the project.

    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.

  4. There’s a fine balance between “Losing my religion” and “Loosening my religion”, they’re the same thing from the two glass half full/empty perspectives.

    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?

  5. Thanks for the more honest assessment, especially from one at the ramparts. I sometimes think the cry for “Open, open!” misses other opportunities, though I like teamwork, leadership has it’s place.

    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.

  6. Wait, lets backup – how long has this design in opensource really been out there? Maybe 3 or 4 years? So we havn’t reached the body of knowledge, neither a full understanding how different opensource cultures effect design – that should be required of such a field.

    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.

  7. Well put. As someone who walks the line between coder and designer, this debate is all-too-familiar.

    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.

  8. Design is a reductionist activity. Open source is essentially emergent. Oil, meet vinegar.

  9. This is going to sound somewhat weird but try to think of design as a natural process similar to conceiving a child and raising it to adulthood. The initial conception is between two people who through unity create this new child. In its initial stages of life, the child is cared for directly by it’s mother (i.e. tending & feeding the child) and indirectly by it’s father (i.e. working to provide food for his wife which in turn allows her to sustain the child). Later as the child grows, other family members start helping out with the child in it’s growth (i.e. grandmother babysitting). Later on, other societal systems help out as the child starts going to school (i.e. kindergarden, etc). After years of schooling and interaction with many people, the child becomes an adult and final is “let go” into the world to interact with everyone it meets on it’s own accord, yet at the same time is still supported by many people as well (i.e. employer, banks, grocers, etc).

    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.

  10. That’s more or less what Fred Brooks Jr. says in the Mythical Man Month. I think the chapter in question is the surgical team. You have the head surgeon who decides everything. He’s the only person who makes decisions during the surgery. Everyone else has a specific role, but they’re not supposed to decide (innovate) on anything because if it isn’t in line with what the head surgeon thinks, the patient could die.

    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.

  11. “Open source code, in contrast, can have many authors and be improved incrementally. Design — visual, interactive or conceptual — requires unity; piecemeal solutions feel disjointed, uncomfortable and obvious when end up in shipping product.”

    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.

Comments are closed.