FOSS stack in libdrone, and the DJI dependency problem

Summary¶

Every software and firmware component in libdrone was selected on FOSS criteria first: auditability, vendor independence, community maintainability. The stack across both current builds — Cinematic (ArduPilot) and Agile (Betaflight) — is open source or open standard end to end, with a small, acknowledged set of exceptions that aren't in the critical path. Where DJI achieves its video, camera, and flight-stack quality is precisely where it's closed: none of it is available to buy as components, and building an equivalent from what is available costs roughly three times as much for a worse result. Galileo and EGNOS are used alongside GPS as a deliberate, EU-origin choice, part of a longer-term goal — an actually EU-sourced drone — that's honestly years and several rebuilds away, not a claim made about the current build. The documentation you're reading follows the same principle: plain Markdown, git-tracked, validator-enforced, no proprietary wiki platform holding it hostage.

Concept¶

Why the entire stack matters¶

A chain is only as open as its weakest proprietary link. A build that uses open-source firmware on the FC but a proprietary RC protocol on the radio link has a single proprietary dependency that can strand the entire investment. Selecting FOSS throughout the stack ensures no single vendor decision can disable the platform's core function.

The DJI dependency problem¶

DJI makes genuinely excellent drones. That's not in dispute, and it's not the problem. The problem is threefold, and none of it is fixable by buying a different drone:

The good components aren't sold separately. DJI's video transmission system (OcuSync-class), its camera and gimbal stack, and its flight software are vertically integrated and closed. You cannot buy DJI's VTX as a component and put it in your own build. You cannot buy DJI's camera sensor and image pipeline. The quality that makes DJI's product excellent is exactly the part that's unavailable to anyone building their own platform.

Building an equivalent from open or available parts costs more, not less. This sounds backwards — open source is supposed to be cheaper — but at the component level it isn't, because DJI's cost advantage comes from vertical integration and manufacturing scale that no hobbyist-facing open ecosystem can match. Sourcing a video system, camera, and flight stack from publicly available components (HDZero, standalone cameras, ArduPilot/Betaflight on commodity FCs) to approach DJI's actual output quality runs to roughly three times the cost, for a result that's still a step behind DJI's own image quality and link robustness. The honest reason to build libdrone anyway isn't "it's cheaper" — for matched output quality, it usually isn't. It's ownership: understanding it, fixing it, modifying it, and not being dependent on one company's continued goodwill.

Every flight still routes data through infrastructure you don't control, on the DJI side of things — telemetry and imagery metadata to DJI's own servers, outside EU jurisdiction, outside GDPR enforcement reach. For a hobbyist this is usually just an inconvenience. For anyone who cares about actually owning their data as well as their hardware, it's the same ownership problem as the components question, one layer up.

The EU strategic autonomy dimension, honestly stated¶

The European Union's strategic autonomy policy — the European Chips Act, Cyber Resilience Act, research funding frameworks — addresses dependency on non-EU technology for critical infrastructure. libdrone takes a step in that direction already: Galileo and EGNOS alongside GPS removes dependency on US military policy decisions for navigation (GPS Selective Availability demonstrated this risk is real, not theoretical).

But "the goal is an EU drone" and "this is an EU drone" are different claims, and only the first one is true right now. HDZero's encoding firmware isn't open. Several key components (FC silicon, camera sensors) aren't EU-manufactured even where the design around them is open. Getting from here to an actually EU-sourced, EU-manufactured platform is a multi-year, multi-rebuild trajectory, not a switch to flip. Stating it as already achieved would be exactly the kind of overclaim worth avoiding — better to be honest about the direction and the distance.

Documentation is part of the open stack too¶

The same no-lock-in principle that applies to firmware and hardware applies to how this documentation itself is built. It's plain Markdown, version-controlled in git, checked by an automated validator before anything publishes, with nothing ever silently deleted — superseded content is marked and kept, not erased. There's no proprietary wiki platform holding the corpus hostage, and no vendor whose pricing or shutdown decision could take the documentation down with it. This isn't a claim made to anyone in particular — it's the same ownership argument as the rest of the stack, applied to the thing you're reading right now.

Reference¶

Complete FOSS stack map¶

Known exceptions: - HDZero VTX/goggle encoding firmware: not open source. Video-critical, no full open alternative currently matches its performance. - Synology NAS DSM: partially proprietary. Not a flight-critical component. - RadioMaster TX16S PCB layout: not published (firmware is open).

Contributing to the FOSS stack¶

libdrone's community benefits from contributions at every level:

• Bug reports with reproducible steps: more valuable than they appear — they save developer hours and benefit every user
• Documentation: perpetually underserved in all FOSS projects; clear explanation of how something works is as valuable as implementing it
• Testing new firmware: catching problems before they reach thousands of users is critical community infrastructure
• Publishing build modifications: every improvement, every new calibration procedure published publicly adds to the commons that benefits everyone
• Code contributions: fixing bugs, adding features, reviewing pull requests

The career argument is direct: a student with commits in Betaflight, in the ELRS repository, or in the libdrone repository has a public portfolio of real engineering work visible to any future employer. Work done on proprietary tools is invisible and inaccessible.

Procedure¶

Evaluating a new component against FOSS criteria¶

Before adding any new component to libdrone (new sensor, new FC, new protocol), evaluate:

1. Is the firmware/protocol specification publicly available?
2. Can the community fix bugs or add features without vendor permission?
3. If the manufacturer discontinues the component, is the design reproducible from publicly available information?
4. If proprietary: is the dependency on a critical path? Is there a viable open alternative? What is the exit path?

Document the evaluation. Record any proprietary dependencies explicitly. The goal is informed decision-making, not purity for its own sake — and where the pragmatic choice is a proprietary or non-EU component (HDZero being the clearest example), say so plainly rather than quietly working around it.

Rationale¶

Why FOSS selection compounds in value over time¶

A single open-source component selection is a marginal improvement. A complete FOSS stack is compounding advantage. Each open component reduces the risk from every other component — the community that maintains one component's firmware is likely to maintain the others. The contributor network that caught a bug in AM32 will catch bugs in the payload firmware.

Open-source ecosystems have network effects just like proprietary platforms — but the network effects accrue to the community rather than to a single vendor. libdrone participates in and contributes to a FOSS ecosystem that will outlast any individual component manufacturer's business lifetime.

Why this article absorbed the DJI-dependency and documentation-trust¶

material

Two earlier articles covered adjacent ground separately: one made the case against DJI dependency for an institutional-evaluator audience, and one made the case that libdrone's documentation structure could satisfy NATO-adjacent institutional governance requirements, aimed at the same kind of audience. Neither audience is who this project is actually for anymore — it's for the person building their own platform, not an organisation evaluating a vendor. The parts of both articles that were genuinely true regardless of audience (the DJI component-availability problem, the documentation system's own lack of vendor lock-in) are folded in here, in the individual-ownership framing that's consistent with the rest of this domain. The original articles are kept, deprecated, not deleted, in case any of the discarded institutional-pitch material is ever useful again.

Connections¶

requires: - foss-principles - vendor-lock-in related: - elrs-protocol - open-source-philosophy - legal-and-regulatory leads_to: - contributing-guide