Wednesday, 27th November 2013

The case for open source design

Posted on 01. Sep, 2010 by in Open culture

Open source design is taking off. Fired by the success of the open source collaboration model in software design, creative communities are applying open source approaches to other realms of design, including computer hardware, electronics, humanitarian design, and prosthetics. There are, however, significant challenges presented to these projects. Opening design processes to sharing and multiple input quickly leads to chaos without an interface that facilitates versioning and targeted collaboration. As Mushon Zer-Aviv argues in ‘The Case for Open Source Design: Can Design By Committee Work?’, the challenge for open source design is to create user interfaces that facilitate open-source design work without falling into the trap of ‘design by committee’.

Open source design projects, Zer-Aviv argues, are faced with a problem of granularity. Software is made of granular building blocks, namely typographical characters. This enables software designers to accurately identify the locus and strata of co-construction. It allows them to easily compare changes, enabling transparency, accountability, moderation and versioning.

This is not the case with other open design projects. Zer-Aviv describes it as a coding-decoding problem. In the case of any act of information exchange, ideas are transformed, or ‘coded’, into a message using a specific language. The recipient of the information must ‘decode’ the language in order to digest the ideas. Software designers have a clear language and set of protocols for coding and decoding messages. But this is not the case for other design communities. How, for instance, is a Belgian architect to code her design ideas such that they can be easily construed by a Kenyan builder, and vice versa? The challenge is not simply to identify a common language in which to exchange ideas. The challenge is to design an interface that enables all involved parties to identify and distinguish the components, or ‘grains’, of the project, thus enabling the transparency, accountability, and versioning required for successful open design.

Zer-Aviv offers the following suggestions:

1. We need to implement versioning of both code and image files. Since code lends itself to precise and accurate exchanges, it is the preferable medium for open source projects. But image files play a vital role in design projects. We need new collaborative paradigms for versioning and collaborating on such files. This is a task for open interface design.

2. We need to find better ways of encoding and decoding communicated messages. Zer-Aviv breaks this down to two things. First, we need to formalize processes of collaborative encoding. Second, we need to identify design patterns that are rational or standardized. These patterns establish a basis for consensus and shared expectations of how a message will be interpreted.

3. The ultimate challenge for open source design has no technological fix. It concerns the way that we interact with others on collaborative projects, and how we perceive our role as stewards of these projects. As Zer-Aviv claims,  ‘the substantial parts of design that still cannot be easily quantified or assessed on shared rational ground should be managed through trust and leadership’. Ultimately, we need to approach open design projects with a view to helping evolve the culture of open design.  This is a culture that all of us have an investment in developing.

Tags: , , , ,

6 Responses to “The case for open source design”

  1. Chris Watkins 3 September 2010 at 4:35 am #

    I wonder if SVG images make image versioning easier?

    Agreed, of course on the importance of open design. We’ve had some similar conversations in the broader Appropedia community, esp re “Open Source Appropriate Technology” (a web search will find some of the conversations). Samuel Rose is working on a versioning tool for designs (too technical for me, but I’m hoping the finished product will be usable for many people).

    For now the closest thing to versioning for design, AFAIK, is a wiki. It’s strengths are that the page, its history and diffs are all easy to access and understand, and the whole site can be organized by the community, and can be made easy to navigate.

  2. Tim Rayner 4 September 2010 at 11:38 pm #

    Good question about SVG images, Chris. http://en.wikipedia.org/wiki/Scalable_Vector_Graphics I’d be interested to hear from anyone with experience using them.

  3. Jonathan Eyler-Werve 7 September 2010 at 11:35 pm #

    A lot of this has to do with the quality of documentation by creators and editors. Yes, code is granular, but in practice it is the documentation that makes it understandable in a reasonable timeframe. There’s no structural reason that images can’t have documentation attached. A hidden comment layer will work just fine in most graphic design software, or for bigger efforts file attachements embedded in a forum thread work fine to archive both comments and file versioning. This applies just as well to text, video, anything.

    Programmers are trained to embrace documentation – it’s not innate. As noted above, it’s human behavior, not technology that is at issue.

  4. Gerry 13 September 2010 at 11:18 am #

    Thinking about design representations, texts vs. images, is not the core of collaborative design. Design is a process, not a product. The result is a conversation, not the design artifacts of code and blueprints.

    On the other hand, much of the work of producing a design is the work of encoding the design using design tools. The artifacts can become a primary focus of the communication, and this is particularly true in the work of writing code. This shift of focus from the space of design to the space of implementation is not only inevitable but desired. When we engage in so called agile design, we are shifting rapidly between these spaces.

    Debug only code, don’t get sucked in by the comments.

    This programmer’s saying illustrates a deep issue. Even when the documentation is tightly bound to the code, they can diverge. Because the code itself is the only truly shared language across the open source development space, it is inevitably the final authority and “documentation” in general is deprecated.

    This is unfortunate because it makes it hard to actually do design and architecture work very well in the Open Source space. One of the reasons that I am so attracted to the “Open Stewardship” initiative is because of the way it opens the possibility for the care for the social processes that nurture collaborative design as well as the shared digital artifacts and communications networks that support the work.

    We need to be able to initiate dialogs, ask and answer questions and share design (not implementation) artifacts in a coherent network. The state of the art in tools is such that “creating and extending global collaborative social networks” is just possible, but still very difficult. We need a lot of stewardship work just to fight the tools in the current generation, and we need the time to build the next generation of tools as well.

  5. paul t. horan 9 November 2010 at 3:53 am #

    Chris, Tim, Jonathan, Gerry et al.,

    Thanks for this yummy education … I/we’ve so much good stuff to learn about designing, implementing and celebrating our human activity systems as evolutionary guidance systems.

  6. Daniel Connell 19 November 2011 at 11:51 am #

    It’s more to do with the outcomes of design than the process, but I would strongly advise anyone attempting to generate valuable designs to learn some basic 3d animation skills.

    For the last two years I’ve been developing an open source solar energy device, the construction tutorials for which will be freely available on a website.
    These tutorials center largely around animations of the full device coming together piece by piece.
    For example:
    https://www.youtube.com/watch?v=W19ibIsc6DE

    This is important, vital really, because it leaves nothing to the imagination. Tutorials which are photos and text, even some videos, will always have gaps that the reader must fill in from their own experience, and if they’re not already intimately familiar with the process, that creates a kind of immediate panicked disconnect.

    But 3d skills are rare, even though simple to use free software is easily accessible (sketchup and blender make a good combination, I generally use Rhino3D and Maya, but they’re not free).

    So if you want to present the construction of your design in a way that can be followed by anyone, please do us all a favour and either involve an animator or learn the basics yourself.


Leave a Reply

Comment moderation is enabled. Your comment may take some time to appear.

Please fill the required box or you can’t comment at all. Please use kind words. Your e-mail address will not be published.

Gravatar is supported.

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>