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..


2 thoughts on “iBOM Part 4 – Expanding the market

  1. 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).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s