Hardware-specific Considerations

Stay organized with collections Save and categorize content based on your preferences.

When planning your open source hardware project, it's important to take both component selection and toolchain choice into consideration.

Component Selection

This is an area that’s unique to hardware projects, but is conceptually similar to upstream dependencies in open source software development. Hardware product development can often be thought of as a series of system integrations of commercial off-the-shelf (COTS) parts, with an assembled circuit board usually consisting of “commodity” parts like resistors and capacitors plus some application-specific components like processors and sensors.

As COTS components, the factors to consider for use in a hardware project include unit cost, lead time, vendor availability, and the risk of a component being discontinued. Less obvious factors to consider are component package size and other integration complexities like calibration or unit testing. While the importance of these are immediately apparent to engineering projects and manufacturing schedules, these also impact the long-term viability of an open source project.

A consumer device with a cutting-edge sensor package could certainly be open sourced by releasing its relevant artifacts, but if the bill of materials (BOM) is filled with esoteric components that are expensive in small quantities, only available from a single vendor source, and only on a 12-week lead time, the project then is only accessible to other large organizations with the means to source the components and manufacture it.

Further, the open source hardware community shares many similar roots with the maker community of hobbyists and enthusiasts with a strong DIY ethic. Specifying passive components smaller than 0805 imperial will prevent most hand-soldering and will instead require expensive automated pick-and-place machinery that further restricts the pool of potential contributors to people with large factories at their disposal. (Although the increasing availability of low-volume contract manufacturing is helping to lower the barrier to entry here, it hasn’t yet lowered far enough to ignore these concerns.)

Development Toolchain

Since the artifacts of an open source software project are primarily human-readable text, there are a wide variety of authoring tools available that cover a spectrum of use cases and costs (vim, emacs, VS Code, Eclipse, etc). Hardware projects do not have this luxury, as interoperability between popular development environments can be poor or nonexistent. This can drive up the cost/complexity of switching or converting artifacts between development environments down the road, so the initial toolchain selection has a long term impact on the project and the ability for a community to form around it.

Development toolchains can be split into two categories, listed below with examples (see Wikipedia for more examples:

Proprietary/Closed source

  • Solidworks (Physical CAD)
  • Creo (Physical CAD)
  • Altium (Electronic CAD)
  • Maya (3D rendering)

Free/Open source

  • FreeCAD (Physical CAD)
  • OpenSCAD (Physical CAD)
  • KiCad (Electronic CAD)
  • Blender (3D rendering)

The tradeoffs between these can be considered in terms of development cost (or time to market) and community accessibility. Proprietary tools are stable, mature, and provide high usability, and as such have become industry standards that are well-known by professional engineers and designers. Due to their commonality in industry, a product team can often deliver a product to market faster using these tools and at a lower cost (license fees notwithstanding), but the resulting artifacts are only accessible to other companies or professionals who purchase the same software licenses.

Free/open source tools for hardware design can potentially be less mature and have a steeper learning curve for developers transitioning from proprietary workflows. This places additional costs on the product team in terms of staff training and slower development velocity, however the resulting artifacts are more widely accessible to anyone with a computer.

Put another way, hardware development tools are similar to the build tooling for software projects: if a project’s code only builds with Visual Studio, that limits the pool of contributors to only those with a Visual Studio license.

For more guidance in making decisions around components and toolchains, reach out to the Open Source Hardware team at emailremoved@.