Publishing open hardware is mostly about one test: can a stranger reproduce your project from what you posted, without writing to you? Everything below serves that test. The tooling matters less than people think. A tidy folder on any public Git host passes; a beautiful project page with a ZIP of exported Gerbers and nothing else does not.
Pick a home for the files
Most projects live in a Git repository on a public forge. Git handles text formats well, and many EDA and CAD tools now save in text, which makes diffs readable. Binary CAD files still work in Git; they just can't be compared line by line, so write good commit messages.
Some communities prefer dedicated platforms with build logs and photos. Those are fine for visibility. Keep the repository as the source of truth anyway and link to it from the platform page, so the files outlive any one website. A mirror on a second host, or an archive deposit with a DOI if you work in research, costs little and protects against a service shutting down.
Lay out the repository
A layout that people recognize saves them time. A common pattern:
my-board/
README.md
LICENSE (hardware license text)
LICENSE-docs (documentation license, if different)
hardware/ (EDA project: schematic + PCB)
mechanical/ (enclosure, brackets: STEP + native CAD)
firmware/ (source code + its own LICENSE)
production/ (Gerbers, drill, pick-and-place, BOM exports)
docs/ (assembly guide, user guide, images)
CHANGELOG.md
Keep generated files in production/, separate from the sources they came from. Someone who changes the layout should know which folder to regenerate.
Publish the design files in the form you edit
The community definition asks for design files in the "preferred format for making changes." In practice:
- For electronics, the native project from your EDA tool (KiCad, for example) along with exported Gerbers, drill files and a PDF schematic. The PDF is what most people will open first.
- For mechanical parts, the native CAD file plus STEP, a neutral format most CAD programs read. An STL alone is a mesh and is hard to edit.
- For FPGA or chip designs, the HDL source, constraints files and build scripts, plus the toolchain version you used.
If your design depends on a proprietary tool, say so in the README and still publish the native files. Many people will have the tool; others can at least open the exports. A design made in free tools is easier for everyone to modify, and that's a real point in their favor when you're starting a new project.
Libraries matter too. If your schematic uses custom symbols and footprints, include them in the repository. A KiCad project that opens with missing footprints is a common and frustrating failure.
Write a bill of materials people can buy from
The bill of materials (BOM) is the most-used file in many projects and often the worst maintained. A good BOM has one row per unique part with:
- Reference designators (R1, R2, C5...)
- Quantity per board
- Value and key ratings (10 kΩ 1% 0603; 100 nF 50 V X7R)
- Footprint or package
- Manufacturer and manufacturer part number
- At least one distributor part number, and an alternate for parts that go out of stock
Export the BOM as CSV so it opens anywhere and diffs cleanly in Git. Generate it from the EDA tool instead of typing it by hand, so the BOM and schematic never disagree. Mark parts that are "do not populate" clearly, and note any part that has to be sourced from a single vendor. If a component is proprietary but needed, list it and point to its public datasheet.
Mechanical BOMs need the same care: screw size and length, material, and any off-the-shelf parts like bearings or extrusions.
Document like the reader has never seen it
Documentation is where most projects fall short. Most projects need a README, an assembly guide and a user guide.
README
The README says what the thing is, shows a photo, states the license, explains the folder layout and links to the latest release. Five minutes of reading should be enough to decide whether the project is useful to someone.
Assembly guide
Give step-by-step instructions, a tool list, a photo at each step and the tests to run before first power-on. Note the mistakes you made building your own first unit. Those notes save other people hours.
User guide
Cover how to use, update and repair the device, with safety notes where voltage, heat or moving parts are involved.
Photos and diagrams belong in docs/ under a documentation license. Creative Commons Attribution-ShareAlike (CC BY-SA 4.0) is the usual pick, and the license chooser will tell you when CC BY is a better fit.
License every part
A hardware project usually needs more than one license: one for the design files, one for documentation, and one for firmware. Put each license file at the root of the folder it covers, and add a short line to the README that maps folders to licenses.
Put a license notice inside the design files too. In KiCad you can add text to the schematic title block and to the board's silkscreen or fabrication layer. Source files can carry an SPDX identifier line such as SPDX-License-Identifier: CERN-OHL-S-2.0, which tools can read automatically. Some licenses, including the CERN Open Hardware Licence v2, ask you to state a "source location," a URL where the design lives, and suggest putting it on the product itself, for example on the PCB silkscreen.
Choosing among the licenses is its own topic; see choosing an open hardware license.
Release in versions
Tag a release every time you send boards to a fab or start a production run. A release should contain the exact production files used, the BOM for that revision, and a changelog entry describing what changed and why. Put the revision on the board itself (REV B, v1.2), so anyone holding a unit can find the matching files.
Don't overwrite old releases. People who bought or built version 1 need version 1's documentation. If you plan to certify the project with OSHWA, this matters further, because their program registers each version separately. Our certification guide covers the details.
Make contributing possible
Open hardware gets better when other people can send improvements. Add a short CONTRIBUTING file that explains how to report a problem, how to propose a change to the design files, and how you review changes. Issue templates that ask for the board revision and photos make bug reports far more useful. If you can't accept contributions, say so plainly; people will fork instead, and that's fine too.
A pre-release checklist
Before announcing, clone your own repository onto a clean machine and try to reproduce the project from it. Check that:
- The project opens without missing libraries or footprints.
- The production files match the latest design files.
- The BOM has a buyable part number for every line.
- The README states the license and the revision.
- The release tag contains everything needed to order boards.
If a friend can order a board from your files without asking you a single question, you've published open hardware.