Slashdot Mirror
The Makerspace Is the Next Open Source Frontier
An anonymous reader writes: Jono Bacon explains that in the same way open source spawned millions of careers and thousands of companies, the same openness has massive potential when applied to products. It could potentially jumpstart a revolution in how we conceptualize, build, and share things and how we experiment and innovate to push the boundaries of science and technology. He outlines some steps for adapting open source principles to physical creations: "...we will need to create a premise of a blueprint bundle. In much the same way I can download a branch from Git or a tarball with some code, complete with build system, we will want to be able to download a single branch or tarball with the full software, hardware designs, and more for how to create an open product. ... we will need to figure out how we collaborate and improve different pieces of these projects. For example, if someone refines a 3D printed piece of a drone, how do they fork the blueprints, submit their changes, have them reviewed, and get them merged into the project? Another question could relate to automated testing: when building physical products we can't always afford to build and test new physical hardware for it to then crash and burn, so how can we have unit tests for hardware or test in a virtual setting?"
In the aerospace industry, we had metadata around the actual design documents, and a process for incorporating changes. Some examples are:
* A drawing tree. A complete airplane or other complicated product had a top level drawing, that called out major assemblies (wings, landing gear, engine installation, etc). The major assembly drawings then called out sub-assemblies, in a tree structure, until you get to the parts level. Documents tied to a particular drawing (like engine installation procedure) got the same number as the drawing with a -002, -003, etc added, so you could track what they go with.
* Interface drawings and documents. Between assemblies you defined the interfaces between them - mechanical, dimensional, electrical, etc. You can't change your side of the interface before first consulting the people on the other side, and updating the interface data. That's how you ensure the pieces go together later.
* Requirements tracking. For example, the 747 landing gear has to support a takeoff weight of 880,000 pounds. Therefore there has to be a weights tracking process that assigns weight budgets to the various parts, and reports status back up the tree. Otherwise you can end up with a plane that's too heavy for the landing gear. Anywhere else there is a critical design value with contributions from various parts, you use this method.
All this metadata has to be passed around along with the actual parts drawings and software code. If you don't, then anything too complicated for one person to design is likely to need rework when the pieces of the design are merged.