Open Hardware: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
'''Hardware that is the result of open designs, similar to open source code, and the result of collaborative work.''' | |||
Hardware that is the result of open designs, similar to open source code, and the result of collaborative work. | |||
An important comment about the difficulty of developping it, as compared to open source: | An important comment about the difficulty of developping it, as compared to open source: | ||
Revision as of 08:37, 9 March 2006
Hardware that is the result of open designs, similar to open source code, and the result of collaborative work.
An important comment about the difficulty of developping it, as compared to open source:
"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." (http://www.worldchanging.com/archives/004155.html)