Skip to content

Instantly share code, notes, and snippets.

@adavidramos
Last active June 26, 2019 17:30
Show Gist options
  • Save adavidramos/21c78cbaf4b65a484c43db784bfa40f6 to your computer and use it in GitHub Desktop.
Save adavidramos/21c78cbaf4b65a484c43db784bfa40f6 to your computer and use it in GitHub Desktop.

Quick response in case it’s useful to you re your conference proposal deadline.

This is fascinating and important. The idea of using free/libre/open source approaches (or materials created and licensed in that manner) is novel, on one hand, and yet we do it far more than we usually realize.

Free/open source is an enormous topic. It seems small only because it’s outside most of what we talk about in graphic design. There’s enough here for three or four papers/presentations, really. I think, pick one topic—any of them are worth examining, and (guessing at your audiences here) are likely to need considerable explanation. You could also focus on the MICA special topics class, which would let a designer/educator audience hear about a familiar and tangible outcome (the class) yet explore all of these threads. One issue in depth, or talk about one class that looks at all these issues, making the class and the student response into the topic.

I’m seeing, in your writing, a few ways of thinking about free/libre/open source:

  • Straight-up using F/L/OS software. Sounds as if it’s important to your class, and fairly prominent, yet unexamined, in digital/interaction practice. This is fairly easy for a reader to get their get your head around.
  • Putting design process out in the open (what we could be doing with Dribble but, as you note, aren’t).
  • A collaborative way of designing (which pushes up against the issue of, well, is most design work worth collaborating on in the first place).
  • Vernacular, which points toward the idea that maybe everyone can design.
  • Control over design tools and the ideas that they embody.
  • Also, freely licensed or public domain images, texts, and data, which isn’t quite so much a part of what you’re writing about.

There’s a gap, here, between the well-understood practice of making open source software and the ways we do design. Look at the Creative Commons license, which came about as a cultural-works alternative to software-centered open source licenses. What should open source be for design? I’ll hazard that many kinds of graphic design (or UX, so on, whatever) work don’t fit well into the software model of licensing, nor does the fork/merge model quite align with the notion of a designer as a singular player. (Designer as author, vs. designer as instigator.)

Still, design deals mostly with projects that don’t really lend themselves to shared responsibility–either we make them once and they’re done, or they’re too closely attached to one person’s vision, or they are ephemeral, or, honestly, they’re not that complex. That’s a limitation of design’s own making. With expanding ideas of what design has become, maybe there’s a place to ask how we can iterate and design in public.

There are also ideas about public process, and about learning about the people who will be served by the products of design, and how we design for them.

Rapid iteration and unstable design has indeed made its way onto the web, where we have learned to ship and to modify on the fly.

Dunne and Raby are super-important here.

On the vernacular—Henry Glassie has a book, Folk Housing in Middle Virginia, which arrives at the height of linguistic structuralism.

Implicit in much open-source software, and indeed in any kind of collaboratively developed software, regardless of license: modularity and community. You need the community to have people who are willing to work together, and designing the community is more important than the nature of the software itself. (Example: WordPress. I respect so, so much about WordPress, and admire its community, but the technological decisions and templating system are a horror show.) Then there's modularity–it shows up in things like object-oriented software languages, and in the way that software engineers work to separate parts of the programs, and in all of the protocols to let different pieces of a stack talk to each other. Without that, how could people pull out one part without the whole codebase collapsing? We don't have modular design. Maybe we don't need it. Or maybe design should become more modular. To that, there are some examples in industrial design history, in (weirdly) lots of those big 1960s/1970s brand identity systems (heck, Unigrid empowers anyone to make their own brochure), and also in web HTML/CSS frameworks (on which, ugh, we can blame much of the sameness of the web). But how do you contribute to the design of a tangible printed piece?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment