The distinction is becoming tangible in FPV. Belgium-based OpenDrone has released hardware repositories for flight controllers, ESCs and ExpressLRS receivers under CERN-OHL-S-2.0. Its roadmap separates four beta boards from alpha devices and says none of its designs has yet reached the final "launched" stage. That status information matters as much as the fact that the schematics are public.
Reproduction starts with the editable design
The Open Source Hardware Association definition requires the preferred editable source format, not only manufacturing outputs such as copper artwork. A Gerber package can tell a fabricator how to make a PCB. It does not necessarily tell a contributor how to move an IMU, reroute a motor-current return path or modify an RF matching network without reconstructing the circuit.
OpenDrone's OpenFC-Lite, OpenESC-30x30 and OpenRX-Gemini repositories include hardware directories and board-specific technical documentation. Their native-design approach gives a reviewer a practical starting point for checking footprints, connectivity and component selection.
The next question is reproducibility at a named revision. An editable file from a project's main branch may have changed since a particular board was manufactured. A useful reproduction package ties a git revision or release tag to the actual PCB markings, schematic, layout, bill of materials, assembly files, bootloader and known errata. Otherwise two builders can correctly claim to be using the same project while testing different hardware.
OSHWA's certification guidance specifically recommends marking the physical hardware with a version or release date so it can be matched to design files. That is operationally relevant in FPV, where a changed voltage regulator, sensor, gate driver or antenna network can alter the safe build procedure without changing the board's product-family name.
Flight controller, ESC and receiver have different failure modes
These three OpenDrone examples make the distinction clear.
The OpenFC-Lite repository describes a six-layer RP2354B Betaflight controller with a BMI270 IMU, four UARTs, microSD blackbox storage and a 3-8S input range. It also documents an analog-OSD conflict: an operator may need to disable the LED-strip feature until a firmware update resolves coexistence. That small, concrete limitation is more informative than a generic compatibility label. A PCB can be sound while the combination of target definition and enabled firmware features remains troublesome.
The OpenESC-30x30 describes four independent motor-control channels, each with an MCU, gate driver and six MOSFETs. The repository lists AM32 firmware, a 2-8S input, bidirectional DShot and a claimed 60 A continuous rating per channel. That rating is a project specification, not an independent thermal endurance measurement. A reproducer must still evaluate copper thickness, connector and wire loss, MOSFET switching heat, airflow, manufacturing quality and protection behavior. The repository explicitly lists no BEC, so a stack assembled from these parts needs a separately verified power arrangement.
The OpenRX-Gemini receiver uses an ESP32-C3 and two LR1121 radio chains for Gemini/Xrossband operation, according to its repository. It is labeled alpha. Here the critical validation path includes antenna configuration, RF layout, receive sensitivity, power integrity, regulatory obligations and receiver failsafe behavior. A functional bench link does not measure link quality in a noisy aircraft or prove performance across supported frequency configurations.
The distinctions matter because a single label, "open-source board," hides three different engineering disciplines: estimation and timing on the controller, high-current thermal design on the ESC, and RF performance on the receiver.
Firmware is a separate versioned dependency
OpenDrone's organization overview identifies Betaflight, AM32 and ExpressLRS as upstream firmware projects. It explicitly says those firmware projects retain their own licenses; the hardware repositories use CERN-OHL-S-2.0. Public hardware files do not remove the need to pin a compatible firmware target, bootloader version and configurator settings.
A flight controller design may expose a UART in copper, yet require the correct serial resource mapping before a receiver or VTX works. Bidirectional DShot depends on both controller timing and ESC firmware support. An ExpressLRS receiver can have the right radio components and still require target-specific flashing or regional configuration. These are integration boundaries, not contradictions in the idea of open hardware.
A useful project release should therefore pair each tested PCB revision with known-working firmware commits or binaries, configuration exports and a short list of incompatible combinations. Firmware can move faster than manufacturing; without that pairing, users may mistake a software regression for defective hardware, or vice versa.
The license enables modification; it does not certify flight readiness
The CERN-OHL-S-2.0 text permits the copying, modification and conveyance of covered designs subject to notice and reciprocal-source conditions. In particular, distribution of modified covered source and certain products brings obligations to make corresponding modified source available. Builders planning to sell modified boards should read the actual license obligations rather than relying on a short slogan about openness.
Certification addresses another question. OSHWA's requirements concern open-design compliance, with the producer self-certifying individual products and identifying proprietary third-party components. The certification does not constitute an electrical, RF, environmental or aviation-safety qualification. The OpenDrone organization page claims OSHWA certification for several listed designs, but the appropriate interpretation remains a design-openness claim, not an independent endurance test.
Openness improves the possibility of investigation and repair. It does not make counterfeit components, solder voids, power spikes, electromagnetic interference or thermal runaway disappear.
A practical audit trail for a board revision
Before treating an independently built flight stack as interchangeable with the designer's tested article, a builder or maintainer needs evidence at several levels:
- Identity: The PCB silkscreen, revision, released CAD commit, bill of materials and assembly variant agree. Component substitutions are recorded.
- Power and signal integrity: Input range, BEC behavior, grounding, motor transients and interface voltage levels are checked against the complete stack rather than isolated product descriptions.
- Firmware configuration: The target, bootloader, firmware version, resource mapping, receiver binding and failsafe settings are preserved with the test record.
- Bench evidence: Sensor orientation, UART traffic, current measurement, RPM telemetry, link recovery and safe disarm are exercised without propellers as appropriate. ESC heat should be evaluated under a guarded, representative electrical load.
- Controlled flight evidence: A test plan records operating mass, pack, motor/propeller combination, vibration, current, link statistics, temperature and any resets, with clear limits on the conditions actually tested.
This is a proposed engineering audit checklist, not a claim that OpenDrone has failed these tests or that its boards have passed them. Its value is in making the gap between design access and repeatability measurable.
What to watch in the next revisions
OpenDrone's public roadmap currently places its flight controllers and ESCs in beta and its receiver variants in alpha. A useful future milestone would be published, revision-specific build packages and reproducible test reports that others can run against their own assemblies. Without those records, an open schematic is still useful for learning and repair, but evidence about flight reliability remains attached to particular samples and configurations.
The strongest promise of open FPV hardware is that a third party can challenge a design with measurements and submit a fix, then show exactly which revision changed. That is a better standard of progress than equating an available KiCad folder with a finished flight system.