Design and Commons Based Peer Production

On Tuesday, Chris Messina wrote a post about open source and design, where he laments that open source (whatever that means nowadays) and design seem to be opposed to each other. The crux of the problem seems to be that good design requires a unity about it and that since in open source all voices are heard, you inevitably end up with something that has been glommed together rather than designed. This is something that Mimi Yin and I discussed in our 2007 OSCON talk about the challenges of the Chandler design process. Chris is gloomy on the prospects of open source design processes, because he doesn’t feel that there are any examples that have succeeded. I think that this is a legitimate place to be. I don’t really see any successful open source desktop application which was designed in the kind of open design process that Chris or we at OSAF had in mind.

Is organization the problem?

On the other hand, I think that I’m slightly more optimistic about the situation than Chris is. Chris holds up the idea that there ought to be a design dictator, who drives the design and preserves the unity of the design. I’d point out that there are some open source communities where there are such people. Perhaps the best example that I can come up with are the programming languages. A good language is very hard to design. It needs to have the kind of unity that one expects to find in a good design. In some of the language communities, these designers have titles such as “Benevolent Dictator for Life”, and the community as a whole has recognized their giftedness and given them the ability to make final binding decisions about design issues. This isn’t end user facing desktop or web software, but it’s also not bunches of libraries, or implementations of JSR’s, IETF RFC’s, W3C recommendations or POSIX standards. These situations are very delicate mixes and their success is highly dependent on the particular individuals who are involved, so they tend to be rare. Nonetheless, I do think that its possible for communities to work even if there is a chief designer.

I also don’t think that there needs to be a single chief designer. Chris cited Luke Wroblewski’s description of the design process at Facebook. Very early in that post you read:

The Facebook design team works on product design, marketing, UI patterns, branding, and front-end code. The team consists of 15 product designers, 5 user interface engineers, 5 user experience researchers, 4 communication designers, and 1 content strategist. 25 designers in a company of 1,000.

Design can be done by teams. I think that we all know that, but in many of the discussions that I’ve had on this topic, the focus seems to be on the need for a dictator. The dictator model works, but so does a team model.

I think that the organizational challenges of design (dictator vs team) can be dealt with. If you bootstrap a community with a DNA that is committed to good design, and to the value of a good designer, and if the designer has won the respect of the community, then I can see a path forward on that front.   

The problems that I see

In my mind the problems are:

How do you find a designer or designers who want to work in this kind of environment? We know that not all developers are well suited to distributed development. I’d venture that the same is true for designers. It’s much easier for coders to self select into a project than it is for all other types of contributors, including designers.

How can a non-coding designer win the respect of a (likely) predominantly coding oriented community? If you believe that open source projects should be organized around some notion of merit, then what are the merit metrics for designers? Who evaluates the designers on these metrics? Are the evaluators even qualified to do so? In my examples of communities with designers, those designers are all coders as well.

Can we actually do design using the commonly accepted tools of e-mail, version control, wiki’s and bug trackers? The design process relies very heavily on visual communications. The code (including design and architecture of code) process is predominantly a text based process. It is very difficult to do design efficiently in a distributed setting using the existing stable of tools. This is going to be a challenge not just for designers but for many other problem domains that could benefit from commons-based peer production.

What’s with you and that long word?

I prefer to use Yochai Benker’s term “Commons Based Peer Production” instead of the term open source. The problem with the term open source is that everyone means something different when they use it. Some people just mean licensing. Some people think of a particular community’s set of practices. Others think that it means some kind of fuzzy democracy and mob rule.   
One of the reasons that I went to work at OSAF was to see if it was possible to design a good end-user application via some kind of community oriented design process. As far as I am concerned the jury is still out.

6 Responses to “Design and Commons Based Peer Production”


  • (1) I find it helpful to distinguish between outstanding design and competent design. Fred Brooks argued somewhere that we have no examples of outstanding design in any field done by groups larger than two. Conversely, we have lots of examples of competent design done by teams.

    (2) The “source” in “open source”, executable code, has a special property: it is self-describing. Most design work product is incomplete; we call it a “mockup.” Interestingly, both the FB process Chris links to and the Apple design process address this. From FB: “Mockups lie.” From Apple (see http://www.pragmaticmarketing.com/publications/magazine/6/4/you_cant_innovate_like_apple): “Pixel-perfect mockups are critical. This is hard work and requires an enormous amount of time, but is necessary to give the complete feeling for the entire product.”

    Successful open source code bases can start “incomplete” in the senses of “buggy” and “not covering all use cases”, but the code always self-describes perfectly. You know where you are and where you aren’t. Conversely, incomplete design work product “lies.” (Side point: how?)

    (3) Hypothesis: to make design work product more like executable code, you need a mechanism to replace the confrontation with reality that happens when code is executed. You would have to step out of the art-school tradition where a rough sketch is seen as an intermediate step between blank page and finished work. Perhaps the traditions of architecture or small craftsmanship might provide starting points.

    (4) Even if (3) is wrong, I am confident software design will never improve by relying on the visual culture that many self-identified designers come from. As much as we’ve all learned from Apple, I think the way their culture fails to distinguish between the proper use of fonts and the proper working of software as a mechanism holds us back.

    (5) If you haven’t yet read Magic Ink, you should. Victor closes with an attempt to square the circle of graphic designers developing executable mechanisms: http://worrydream.com/MagicInk/

  • Thanks for the thoughts, Ted.

    Part of my frustration with being an “open source” advocate (as you said — whatever that means these days) is the lack of obvious examples for how open source makes end users’ lives better. Surely having a commodity operating system and browser are good things for the marketplace, but I would take OS X and Safari’s user experience (whether their intuitiveness, consistency or speed) over their open source counterparts any day. Does that make me a hypocrite or just pragmatic?

    Given my training in design, I was never taught how to “open up” my design process — or to act, as Leisa Reichelt has done so masterfully in the Drupal community, as a facilitator of a *design process*. Instead, we were taught to do our own work, and to act as individual authors and artists — and not to work in teams. Or, if we did work in teams, there would always be someone responsible for the final design because any other approach would just end up inconsistent.

    I think your example of programming languages actually reinforces my point, since I’m largely thinking about intuitive, visual experiences, rather than coding or text-based experiences. I also think that the further the distance is between developer and user, the more work you have to do to integrate design methodology into development processes, if only to infuse empathy and pathos.

    I think WordPress is the one stand-out example where open source and design have meshed well together, but that again illustrates my point, since design is consolidated into the hands of a few who work at Automattic and have a mandate to steer the direction of the platform. Drupal 7 will be a curious product to watch — because after more than a year spent on its design — the question will be how it makes incremental improvements towards Drupal 8 with fewer resources (presuming, of course, that once 7 comes out, the design team will move on to other clients or responsibilities).

    Anyway, this is a very serious matter for the success of “peer produced work”. As I see the government, in particular, releasing more and more data openly, the challenge will not be so much what to build on top of those resources, but how to make the mashups and applications that use that data serve the widest possible audience — and to my knowledge — the best way to achieve that is through the application of a humanist design methodology.

  • Can anyone imagine open source software having achieved what it has without checkout, diff, patch, and merge?

    Are there design equivalents? If you asked 10 designers, how many answers would you get?

  • Sam,

    Thanks for all the interesting questions. I wasn’t aware of Magic Ink, so I’ll be giving it a read.

    Chris,

    Yes, I agree that this is a very serious matter for peer produced work in many domains, not just software. I also agree that the design process cannot be done by a large group of people.

    The example of languages was aimed at the question of whether or not open source communities could operate with some restrictions on who was doing the design. I do agree that the closeness of the developers to the users (in this case developers) makes that particular situation easy.

    Despite the history of free and open source software, I still think that we have much more to learn than we have already learned. We definitely have not arrived yet.

  • Chris: WRT “I’m largely thinking about intuitive, visual experiences, rather than coding or text-based experiences.” what do you think of Steve Job’s comment:

    ”Most people make the mistake of thinking design is what it looks like,” says Steve Jobs, Apple’s C.E.O. ”People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.’

    http://www.nytimes.com/2003/11/30/magazine/30IPOD.html

    I actually think the more substantial conflict lies around your use of “intuitive.”

    On the subject of tool support, a non-code example: attorneys developing contracts relying heavily on MS Word’s “Track Changes” feature:

    http://www.shaunakelly.com/word/trackchanges/HowTrackChangesWorks.html

    which is basically diff.

  • @Sam: Yeah, I’d agree with Jobs. I think visual experiences support intuitive operation — but then that boils down, as Jobs said, to “how it works”.

    What’s often lacking from open source design discussions is how something *doesn’t work* in aggregate — from an overall, comprehensive user experience perspective.

    That’s where the difference lies — in holistically approaching the development of a product rather than just ebbing away at bugs with patches.

Leave a Reply