Contemporary open source understanding (Braithwaite’ included) comes from Eric Raymond’s The Cathedral and the Bazaar. In the essay, Raymond analyzes Linus Torvalds’ (and his distributed hacker crew’s) development of the Linux Kernel. Raymond found magic in Torvald’s “release early, release often” mantra and distributed method of working. Raymond points to the maxim “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone,” or “Given enough eyeballs, all bugs are shallow,” as key to Linus’s (and Linux’s) success. Get as many self-selected, expert users as possible to tinker with a design; then ask those same users to share everything wrong they find. As fixes are made, redistribute updates as fast as possible back to the group. Problem finding and solving is accelerated (duplicate searches end quickly since redistribution of fixes is rapid). This was crucial to Linux’s stability and rapid improvement.

Braithwaite is encouraging designers to adopt the same shared, distributed model in hopes that many skilled eyes will also make light work. , Graphic designers aim to find the best visual solution to a problem, but do we show “buggy” ideas to clients, colleagues, or stake holders as part of our process in such an unselfconcious way? This is done easily within the classroom or in the studio between colleagues: hang work on the walls; pass designs between desks/desktops as they develop; look over each other’s shoulders. It can take place out in the world by using services like Dribbble, Behance, and Github. But, open designing is not about accruing comments like “cool!” or “nice work!” or “wow! what’s that great esoteric typeface!” The goal is real solutions to unsolved problems. Designers and audience members other than ourselves might see things differently, catch things we have missed, or have a solution waiting that we have not found on our own (or have not found yet, thus shortening our solution’s path).

Our Special Topics: Open Source class had moved our project files to Github, and we also decided to utilize Github’s issue queue to aid in communal problem solving — making sure we lent each other our eyes. Issues let a user reveal found problems to the “community” (in this case our class, but in general the maintainer and anyone else interested in a project) and then request help with solution finding. Peers peruse each other’s queues attempting aid by providing thoughts; sharing a tutorial; or downloading, tweaking, and re-publishing a fix. For our class, utilizing issue queues kept us a community beyond the classroom when at our homes or working from separate studios across campus. It was also incredibly complicated! For visual design projects the Github “distributed critique” made it hard to get deeper into each others’ experiments that just superficials; it was easy to provide basic visual feedback — asking a question isn’t hard; theorizing isn’t too much work; throwing up a screen shot or two is easy; a “this is working, that isn’t” is no problem. But, forking someone’s project, opening the files, and trying to make sense of design decisions AND understand the context and content of that direction? That required time that not many ended up undertaking. Our class found what most open source communities have found — a small percentage of the community are actually responsible for the majority of the work; most “members” merely download and attempt to use the software, code, utility, whatever, not actually help problem solve and improve.