At first blush, the open source model doesn't necessarily seem like a good fit for physical objects. The reason comes down to replication: with open source software, I can give you a copy of (for example) Firefox without losing my own. With open source hardware, at present the best I can give you a copy of the instructions as to how to make your own (for example) microprocessor with your own equipment; it's the functional equivalent of saying "you want Firefox? Here's the source code -- go find a compiler and learn how to read and modify the code to work with your hardware." While this is hardly a barrier for people who already do have the necessary tools and skills, it's a major hurdle if open source hardware is ever to move beyond a few niche fields.

But replicability is something of a secondary effect of open source -- if you give someone a copy of a program's source code, it's hard to prevent them from giving away complete versions. The key elements of open source, accessibility and modifiability of the underlying instructions, apply just as readily to hardware designs as they do to software code. Moreover, the lack of replicability is something of an artifact of technology; that I can't send you a copy of a computer chip (or mobile phone, or fabber, or bacteria), only a design, is important only in that you can't just double click something and see that microchip (etc.) pop up in front of you.

As fabrication technologies take on an increasingly digital form, this distinction will become less clear. When I send you a copy of Firefox, what I'm actually sending is a set of instructions telling your computer how to organize bits of magnetic material on a hard drive to create another instantiation of Firefox. Similarly, at some point in the next decade or two, I will be able to send you a "copy" of my phone simply by sending a set of instructions telling your computer how to organize bits of carbon in a desktop nanofactory to create another instantiation of a phone. Very soon, a more software-like open source physical world paradigm will become possible.

But what will really make a big difference will be the emergence of tools allowing you to take that set of instructions for the phone and modify it to meet your particular needs prior to it being printed out.

I don't mean a requirement that you design your own phone from basic parts on up, or can only get a bare-bones phone that you then must seek out and add on (potentially conflicting) modules to give it any kind of real utility. I'm talking instead about an interface to the code that makes it easy for amateur designers to tweak the instructions without running the risk of easily breaking the final result. In effect, I imagine that we'll soon be in a world of "skins," "plug-ins," and "overlays" for the material world.

Download any application aimed at an audience of teenagers or young adults, and you'll be confronted by a plethora of options for making it work and look the way you want. "Skins" for programs change the external appearance in sometimes dramatic ways, with (usually) little significant modification of the interface; "plug-ins" are (generally) the reverse, altering the operation of the software, but doing little to change its look and feel; "overlays" are add-ons intended to provide a specific change to the visual use of a program, but (typically) not to change how the whole application works or looks. In nearly every case, programmers code the programs explicitly to allow (or even encourage) these kinds of add-ons. And in most cases, the add-ons are open source.

It's possible to make Firefox look and behave in ways that would make it seem utterly alien to a user of the unmodified version. What's more, many of the modules that enable these changes can be built by people with little or no programming experience. The open source code for Firefox enabled the creation of tools allowing the easy creation of add-ons, while shielding the core application code from seriously disruptive modifications. The open source code of most of the modules enables new users to learn-by-copying, and to modify near-miss designs to meet specific needs.

So imagine a world where these hand-holding tools allow changes to the design of physical goods, not just software. You want that CO2-analysis module on your phone? Drag-and-drop a plug-in to the phone code and press "print," and the underlying code handles how to fit the pieces together. Or, from an architectural perspective, you want an extra space in that clinic to serve as a classroom? Drag the room plug-in around the 3D design until you get the right location, then let the code deal with issues of load-bearing walls and routing power outlets. If the plug-in modules are simple enough, you can even go in and tweak the parameters to get the results you need.

I suspect that professional product or architectural designers are already sharpening their knives -- clearly, this is a scenario in which everyday citizens don't necessarily need the full range of services from designers to accomplish some otherwise moderately sophisticated tasks. But just as it's possible but not desirable to use the tools to modify Firefox in order to use it as a word processor, these "plug-ins" for physical objects wouldn't be a substitute for dedicated design. Furthermore, someone has to come up with the code for how the plug-ins work in the first place -- this scenario doesn't eliminate designers, just moves them up the food chain a bit.

And while the nanofactory aspect of this scenario is off in the future, the core idea is something that could work right now. When Cameron's open source architecture database is built, it should be possible to give it an interface which would allow non-architects to modify the designs safely to meet particular demands.

As we've observed numerous times before, one of the key advantages to an open source approach is that it allows people to examine the code as a tool for education. As the proliferation of skins, plug-ins and overlays for a huge variety of programs demonstrates, the addition of an easy-to-use interface for coders can open up software design to a larger variety of people than those willing to engage with C++. There's no reason why these two principles can't be part of an open source design and open source hardware world, too.