I like designing in the open. This is not really the same thing as “open source” design, although I love that too. An open source design means that you’re sharing your source files, ideally with lots of comments to explain what you’re doing and why. I think of “designing in the open” as talking about1 all the experiments, design ideals, design choices, mistakes, dead ends, and breakthroughs that come along with working on an open source design.
These are really parallel and complimentary tracks. If you’re designing in the open, anybody can come along, read through your notes, ideas that you’ve considered but not really explored, and build their own project based off your thoughts. Open source projects allow anyone to come along, build your exact project, and make changes as they see fit. The two together however, allow the next person to use your source and stand on your shoulders, to learn from all your mistakes, and truly grok the design.
Two of my projects “designed in the open” that I’ve done the most work on was a large wall hanging drawing robot2 and a tiny drawing robot. At the time of this writing, I’ve got about 83 posts on the large drawing robot (including literally thousands of words about just about every aspect of the design of each plastic part) and 23 posts on the small drawing robot, exploring all the design ideas that didn’t pan out, different approaches other people used, and what did and didn’t work for me, and why.
When it came to building my own big drawing robot, Sandy Noble’s website and forums were absolutely invaluable. Using these resources and with patient guidance and help from Sandy himself, I was able to build my own robot, making variations informed by the experiences of others.
Designing in the open is more than about just documentation. Documentation tends to be more about explaining why something is the way it is and now not to go wrong. It doesn’t tell people about all the mistakes and tragedies that went into the creation of the thing in first place.
So, why am I droning on about blogging about mistakes and dead ends? I’m embarking on a new project where there has been some truly incredible work so far. As I look at the designs, it is difficult for me to see what aspects of the designs are absolutely critical, which parts are vestigial remnants of earlier designs, and what parts are merely cosmetic. When it came to working on my own big drawing robot, I tackled a similar problem3 by creating exhaustive lists of pretty much every variation I could find, examining the differences and similarities, and pondering/brainstorming about why different decisions were made.
Part of the problem with this new project is that so much of the content is in Google Plus or on Thingiverse, both of which are incredibly difficult to sift through for information. Thingiverse is great for sharing design files, works in progress, and sharing instructions. However, the comment system handled by Disqus is very finicky and doesn’t allow linking to specific comments. Google Plus is a fair system for facilitating group discussions and comments, but it requires an invite, doesn’t allow “reshares,” and is pretty much impossible to link to for reference.
All that being said, while a blog is an excellent way for a very small number of people to share their work, it’s kind of terrible for larger collaborative discussions. Although I haven’t tried collaborative work through a wiki, that might be a reasonable way forward. While I don’t know the answer to the community conundrum, I know it is not Facebook or Google Plus. Overall, the best system I’ve seen so far may be Sandy’s blog + forums.
In any case, to the extent you have an open source project you’re working on, please consider how your choice in community platform can facilitate designing in the open so that viewing and searching don’t require invitations/registrations, comments don’t require registrations or log ins, and easy linking to prior discussions and comments.
- Probably blogging about – but forums work well too [↩]
- Based on Sandy Noble’s excellent Polargraph [↩]
- Namely, lots of excellent designs, lots of documentation – but little information about why certain decisions were made [↩]