Horizon EDA: a board tool where the library is the front door

One editor from symbol to board

Horizon EDA is an Electronic Design Automation package supporting an integrated end-to-end workflow for printed circuit board design, including parts management and schematic entry. The feature list for users is short enough to read in one pass, and the emphasis is on coherence rather than on the long feature list a mature EDA tool would have. The complete design flow runs from schematic entry to gerber export. There is a unified editor for everything from symbol to board, so the same application and the same conventions cover both halves of the design rather than two tools with a file exchange in the middle. The schematic editor is netlist-aware, which means it knows what the circuit is connected to and can react to that, and there is hierarchical schematics for designs too large to hold in one sheet. Around that sit the features a designer expects: sane library management, rule-based design rule checking, undo and redo, copy and paste for some objects, and what the project calls lag- and glitch-free rendering. It builds and runs on Linux and Windows. For a user, the pitch is that the parts you buy, the symbol you draw, the schematic you wire and the board you route all live in the same tool with the same idea of what a component is.

Parts management as the starting point

The order of the feature list is not accidental. Complete design flow from schematic entry to gerber export comes first, then sane library management, and only then the unified editor. That ordering reflects how the project positions itself against the established open source alternative. In most EDA tools the component library is an afterthought: you draw a symbol by hand, find a footprint somewhere online, and the two halves may not agree. A library that is a first-class part of the design flow is a different proposition, because a component becomes an object with a symbol, a footprint, a datasheet reference and a set of properties, and the schematic and the board are two views of that object rather than two files that have to be reconciled. The README does not document how the library is populated, whether it is downloaded, shared or built locally, so a reader has to check the documentation for that. The developer-side feature list gives a hint about the underlying model: everything is referenced by UUIDs, which is the mechanism that makes a component a single identity seen from several places.

KiCad's router, vendored at a pinned version

The third-party table in the README is unusually informative, and the most interesting row is the router. The project lists KiCad router, version 6.0.4, taken from the KiCad repository tree at that tag, under a GPLv3 licence, and separately the KiCad s-expression parser, also 6.0.4. Alongside it sits a long list of other borrowed components with their exact versions or commit hashes, nlohmann json at 3.10.3 for JSON for Modern C++, Clipper for polygon clipping, polypartition and poly2tri for the triangulation of shapes, dxflib at 3.26.4 under GPLv2, The Alphanum Algorithm, Delaunator for the triangulation, footag, Catch2 for the tests, and range-v3. The README also credits KiCad's awesome interactive router as a user-facing feature, and it also credits the router as vendored rather than written. That is a pragmatic and honest engineering decision. Interactive routing is the part of PCB layout that takes years to get right, and the licensing works out because the router is GPLv3 and the application is GPL-3.0, so the whole distribution is compatible. It does mean the routing behaviour is a known quantity rather than something new, and it means the version pin is a real constraint when you think about upgrading the project.

Modern C++, JSON on disk, GTK and OpenGL

The developer feature list is four lines and each line is a design decision. Written in modern C++, legacy-free codebase. Uses JSON as on-disk format. Uses Gtkmm3 for GUI. OpenGL 3 accelerated rendering. The JSON on-disk format is the one that changes how the tool is used and how it is versioned. A JSON file is readable, diffable and greppable, and a design directory can live in Git with meaningful history, which is a real advantage over a binary or proprietary format. It also means the format is your problem to keep stable across versions, and the project carries a make_version.py and a check_version.py along with a CHANGELOG.md, which is the machinery for that problem. The graphics stack is a performance decision. OpenGL 3 acceleration with a claim of lag- and glitch-free rendering is aimed at the case where an interactive router is redrawing a large board continuously, and Gtkmm3 is the toolkit binding. The application entry point is declared for the desktop in org.horizon_eda.HorizonEDA.desktop, with a metainfo.xml for the software centre listing, and the man/ directory holds manual pages, which are the marks of a project that intends to be installed as an application rather than run from a build tree.

Building from source is a meson project with packaging targets

The getting started instruction points at the documentation rather than giving a command, with the install page at docs.horizon-eda.org/en/latest/installation.html and a feature overview at docs.horizon-eda.org/en/latest/feature-overview.html, so the build steps live outside the repository and this README is the map rather than the manual. The tree still shows how the project is put together. There is a meson.build at the root, so the build system is Meson, and there is a make_bindist.sh script for producing a binary distribution. A wix/ directory indicates the Windows installer is built with the WiX toolset, and there are two Dockerfiles, one named Dockerfile-pr-review and one named Dockerfile-python, which suggests the continuous integration builds a container per pull request and a separate environment for the Python tooling. The Python tooling is real: make_rc.py and make_version.py generate resources and version strings, check_version.py verifies the version consistency, render_icons.rb renders the icon set, and imp.gresource.xml declares the compiled resource bundle that Gtkmm3 loads. Doxygen configuration is present for the source documentation, and dependencies.md is the file to read to see what the project expects from the system.

Where Horizon is the wrong tool

The honest limits are about maturity and reach. Horizon is at version 2.7.2, code named Mirage, released on 2025-12-05, with 2.7.1 in September 2025 and 2.7.0 in June 2025, and the last push to the repository was on 2026-10-04. A package at 2.7 with a three-release cadence over the second half of 2025 is moving, but a design that goes to a fabricator needs a toolchain whose output you trust, and a project with this little history is a harder thing to bet a board on than one with a decade of releases. The second limit is the parts library, which the project treats as a first-class feature but does not describe in the README, so the practical question of whether the components you need are available, with trustworthy footprints, has to be answered elsewhere. The third is the platform range, which the README states as Linux and Windows, so there is no macOS build mentioned. The fourth is scope of the vendored router: at 6.0.4 of KiCad's router, you inherit that version's behaviour, and while the project describes the router as interactive, the details of what it does well and what it does not are KiCad's, not Horizon's.

The alternative shape: separate tools and a file exchange

The realistic alternative to a unified EDA package is the traditional pipeline, where symbols and footprints live in a library tool, the schematic is drawn in one application, the netlist is exported, and the layout is done in another application that reads that netlist and the footprints. The difference in approach is where the identity of a component lives. In the split pipeline, a component is a row in a library file, a symbol instance in a schematic file and a footprint instance in a board file, and the three are reconciled by the netlist and by the careful human who made sure the pads match the pins. In Horizon the component is one object with a UUID, seen from the symbol editor, the schematic and the board, so the reconciliation is something the tool does rather than something you do. That is also where the cost of the unified approach shows up. The editor has to be good at all of it, and one of the hardest parts, the router, is not Horizon's code at all but KiCad's at a pinned version. For a hobby board or a small production run, the unified tool removes a class of silent errors and is worth it. For a team with an existing library, an existing board flow and a fabricator's expectations already met, changing tools mid-project is a large cost with no gain, and the pipeline you already have is the better tool.

Editorial conclusion

Adopt Horizon if you are designing a board today and want one editor from symbol through layout, with the parts library treated as a first-class citizen rather than a pile of downloaded footprints. Do not adopt it for a design that has to be manufacturable next month, because the project is at version 2.7.2 and the documentation on installation and features is the entry point for how far it goes. Before you commit, read the feature overview at docs.horizon-eda.org, check whether the parts you need are in the library you plan to use, and confirm the licensing position, since the application is GPL-3.0 while the bundled third-party components carry their own terms, including GPLv2 and GPLv3 code.

Frequently asked questions

Official sources

1. horizon-eda/horizon on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases