Recently, Humblefacture (and our lab The Humblefactory) have been exploring the potential of open source product design as a part of a more equitable, appropriate manufacturing. Chris Anderson at Wired Magazine has also been interested in this sort of thing for a little while; A recent article of his profiled a number of small-scale producers using open design and flexible manufacturing to make niche products that can compete with the big boys. It's great to see a big voice like Chris behind the open hardware movement (even better, his money is where his mouth is, with the success of his DIY Drones company). Even so, we can't help but think that the future that Chris describes doesn't go far enough. Where "the next industrial revolution" he describes has an open, but still top-down manufacturing structure (finished objects are still made by single manufacturers, just smaller ones, more flexibly) we imagine something entirely new. With a few tweaks, we might have manufacturing with unprecedented accessibility and specificity. You might call it cloud manufacturing, and it could be the most important step toward true locally appropriate manufacturing.
Cloud computing is already reinventing the way that teams of people coordinate around the world to edit documents, create movies, and coordinate projects. The open source software community long ago recognized the value of eliminating physical proximity as a requisite for collaboration. After all, the more minds working on a piece of software, the faster it gets made. Sourceforge is a great example of what a distributed community can accomplish by working on small pieces together.

It was the need to allow local developers to work on small parts that lead to another important innovation: the creation of intercompatible, modular libraries of functions. Unlike interchangeable parts in products, these parts can be recombined into entirely new functional arrangements; imagine plugging parts from 10 different products from Target to form an entirely new product. While modular libraries may have been developed to help coders in giant corporations like Xerox and IBM, their true power has been harnessed by the OSS community. Amature coders might only have expertise in a single area, so being able to borrow functional pieces to shore up the rest of a program makes a massive difference.

The SSG Framework tries to bring some of this same modularity to matter, but with an awareness of the key difference between bits and atoms: Atoms take lots of energy to copy. This makes fabrication hard, or expensive, or both, so analogies of downloading atoms tend to fall apart. Instead, it's better to think of bits as being able to describe the relationships of atoms to one another. The cloud of information describing possible modules and collections of modules is only powerful as long as these modules are easy for lots of people to play around with. Its the difference between giving 1000 kids 1000 LEGO bricks each, or an equal quantity of raw plastic pellets. The first group would be overflowing with ideas. The second group would probably have a couple different kinds of piles. Ease of interaction is key.

An even better analogy can be seen in looking at music, and the rise of the remix as a form of musical expression. Early in history, the musical world might have been dominated by writer/performers. But, early on, musicians realized that they could perform songs that others had composed -- effectively compiling their own program from code. Folk music was traditionally performed in this way, and other genera, like jazz and blues are likewise re-interpretive. Even more recently, it became commonplace for "cover" bands to give a song a very different sound, even changing its genera. This is a modest form of re-coding, but preserves the essential structure of the song. Next, we saw the rise of sample-based musical composition -- now, an artist with a sampler could "play" any musical instrument, even one they had never learned to use. This modularity of sound and sample is key to the function of most modern music, but it has always been present; Even Chopin borrowed themes and chord progressions from his contemporaries. Early sample-based music from the 1970s and 80s often mixed recorded and live sounds for a richer composition.

continuum of musical development

Most recently, we saw the arrival of the mash-up {} , a musical form where none of the modules that make it up are created by the musician. Instead, by re-combining samples from two or more songs according to a different structure, entirely new meaning and emotional power can be derived. In other words, only the structure of the music is created by the musician. Everything else is curation. This curatorial trend is exemplified most fully in the mix of a DJ, who's performance has more to do with the songs selected, the order in which they are played, and the transitions between the songs. In this way, a DJ re-uses hugely coarse modules (entire pieces of music) to weave a larger device: A performance.

The hope of Open Hardware needn't stop at filling niche markets. We should aim for a DJ culture for objects. One in which modules need not be re-manufactured every time that someone decides on a new specification. If we pursue this future, consumerism, and the waste associated with it will only accelerate.

Instead, imagine a future where the global cloud of possible modules and modular configurations evolves separately from the material modules themselves. Then, when a manufacturer/user decides which configuration they need most, they can use that digital description to inform the collection of modules and software on those modules which will come together to form a product. The manufacturer need not understand all the parts of their design, just as the DJ doesn't need to know how to play every instrument in her box of 45s.

In a future with cloud manufacturing, waste, if not irrelevant, at least becomes much more open to interpretation. Imagine a student getting ready to start high school. They want a desk -- a digital device which will allow them to work on digital files, watch movies, edit emails, and do homework. Rather than saving money at a job to buy this device and add it to their growing collection of things, the child gathers the toys they no longer want, and sets off to the local electronics shop. At the store, the clerk scans each toy, which builds a virtual inventory of modules available from within them. The clerk then brings up a listing of possible desk configurations which may be built using these modules, or with some few additional pieces. Once the child selects a device specification, the clerk dissociates the devices into modules, updates their firmware appropriately, and re-assembles them into the new device. The child pays them for the service, and might get a discount for selling back any unused modules -- some other customer will find the used parts a bargain.

With cloud manufacturing, manufacturers all have access to the same specifications (owing to their open design) so competitive advantage must be gained through better customer service (transparency, shared values, etc), more appealing build materials (possibly locally sourced, or materially rare), and aptitude at finding good matches between products and users. These are all things which current manufacturing has trouble with.

The most exciting part about a world with cloud manufacturing is that the scene above didn't have to happen in any one place. It could be in Brooklyn, just as easily as Detroit, and Dubai as easily as a slum outside of Delhi. The particulars of the interaction -- cost, possible materials, possible specifications, and desirable devices -- will change drastically from place to place. And they should. But they will change based on what is locally appropriate, not what is globally economical.

This is the difference between an industrial revolution, and a cloud: A revolution always has a general, an army, and someone who is conquered. Even if they are each very small, and very many. A cloud, on the other hand, cannot be contained. It cannot be formed to fit some larger intention. And everyone can have access to it, depending on the ability of their local systems to use it. Matter will never make up the cloud. Matter deserves local decision. But information wants to evaporate from open source projects.

Luckily, Chris's drone control systems are already highly modular, perfect for becoming a valuable part of the cloud. Other designers should follow his lead. Together, we can surround the earth in a fog of knowledge that will illuminate the path to invention for makers everywhere.


tell leo once said... @ September 23, 2010 at 11:11 PM

How will these novel configurations be tested for safety? A distributed ULbot?

Then there's the possibility of weapons manufacturing, I wonder if the BATF has considered the implications of high precision 3d plastic printers...

Erik de Bruijn said... @ September 24, 2010 at 2:17 AM

A short route towards this is pick-and-place machines that desolders, identifies and tests components and put them into an assortment for later reuse or apply them to a new circuit.
Since we're making good progress having 2D and 3D fabbers for the skeleton/body, we need the PnP machines for the guts/brain too.
While it's not an easy task to develop such a machine, it definitely can be done and is a typical project where users can collaborate to develop and refine the technology and techniques.

Anonymous said... @ October 27, 2010 at 3:26 PM

I'd love to see the rich collaboration you get on Open Source software transferred into the design process for physical products.

I'm currently running a open design experiment for a sustainable consumer product at http://tacticalendar.co.uk.

It's a laser-cut plywood perpetual-horizon erasable calendar.

Hand-finished Tacticalendars are available for mail order, whilst the laser-cutter files are published under the creative commons for people to experiment making their own derived works. There's an instructable available if you're not sure how to fabricate.

Consistent with the open source model, there's even a github issue tracker! This means feature suggestions and bugs can be recorded, triaged and incorporated into the design as it is iterated.

The product is developed first through beta versions and release candidates. Finally stable versions appear after much user testing.

Betas and release candidates are for sale at cost price for people who want to save money and work with us to perfect the ideas.

The v0.1 design was canned early - the first physical prototype immediately suggested a better approach. We're now at v0.2 release candidate 3, and there's only one non-functional modification before v0.2 is declared stable and serious shipping will begin. Version 0.3 beta will follow, incorporating fiduciary markers to synchronize the calendar with Google from a camera phone.

Tacticalendar is the first project to be taken to market from the pool of ideas published as part of the public domain invention-a-week project at http://enigmaker.org . I'm hoping someone else will beat me to market with the second :)

Post a Comment