iBOM Part 4 – Expanding the market
Production on the backend isn’t the only thing holding back opensource hardware, getting from innovation and good ideas into any sort of distributed production requires initial investment. In some cases it can be very small, but unlike opensource software there are physical requirements of pcbs, parts and tools that have very real costs! the iBom part of the equation could be connected in here also by the likes of an Octopart, either by aquiring someone like KickStarter or by rolling their own distributed investor community. This would have the effect of ‘quickening’ the front end in order to supply the backend and would facilitatte the emergence of a ‘Market’ which is the next key part of the move to distributed production. It doesn’t take an Einstein to take this further and envision market places bolted onto the innnovation front ends for successful projects, thus closing the circle and providing positive feedback whilst encourage fresh new agile growth.
*Update I added an iBom repo to get started on the idea/format etc..
I agree that the status quo for sharing and managing footprints, BOMs, EDA symbols, and component information is an impediment to electronics creators and the open hardware movement.
The idea of recursive “BOMs within BOMs” all the way down to component parts is interesting, though i’m not sure i’m sold on it as a file format independent from the rest of a project’s design files. I think that future open EDA tools should accommodate versioned sub-components (with their own schematic/layout/BOM), and that such tools could handle generating a master BOM on their own. For example, a larger design might include a VGA video module maintained by a different team; if the VGA module is updated to use newer analog components, the larger design and BOM would be updated in a mostly automated fashion.
Including component information in a BOM is a tricky problem (there is a whole software industry around merging and normalizing part information in different formats), but certainly isn’t impossible. I don’t think Octopart can just dictate down such a standard file format from the mountain top, but we’d probably support it if such a format got traction. If there was an XML microformat, JSON structure, or even standard .CSV headers to accommodate specifications and metadata about all kinds of electronic components, then BOMs could include a URI pointing to such files hosted on manufacturer websites (or, eg, on octopart).
bryan - September 7, 2011 at 4:23 pm |
Thanks Bryan your right it is a tricky problem, but it can be solved, we have made a start, we now have a project http://goo.gl/mBvsN and a group http://goo.gl/m1keL for iBom, join in the conversation to make it happen, you have already made a start here
regards
Al
folknology - September 7, 2011 at 4:57 pm |