The OpenWrt repository you are reading is a mirror, and that is the first thing to know

This repository is a mirror, and pull requests still come through it

The repository description is the most useful line on the page and it is not the tagline.

It states that the repository is a mirror of the canonical tree at git.openwrt.org, that it is for reference only, and that it is not active for check-ins. It then says the opposite of what you would expect: pull requests will continue to be accepted here.

They are not merged directly. Pull requests are merged via staging trees and then into the canonical repository, which means a change accepted on GitHub travels through at least one other tree before it lands.

That is an unusual arrangement for a project of this size, and it explains two things a newcomer would otherwise trip over. Commits in the GitHub history are not the authority on what shipped. And a pull request being merged here is not the same as it being in a release.

A writable filesystem instead of a static firmware

The design decision is stated in the opening paragraph and everything else follows from it.

Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. That frees you from the application selection and configuration provided by the vendor, and lets you customize the device through packages to suit any application.

The README then gives the same idea twice, once for each audience. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it. For users, it means the ability for full customization, to use the device in ways never envisioned.

Those are different promises and they carry different costs. The user-side promise is what people are usually after, and it is bounded by whether the device is in the supported list. The developer-side promise is the one that makes the package split, described later, worth the trouble.

Two maintenance lines are shipping at once

The three most recent releases are not on one branch line, and the ordering is informative.

v25.12.5 was published on 2026-07-01 and v25.12.6 on 2026-10-18, both on the 25.12 series. Between them, v24.10.8 was published on 2026-07-26.

So the newer series shipped a point release about three and a half weeks before the older series did, and has shipped another since. That is the shape of a project with two maintained lines.

It is also the practical reason to read the version number carefully before installing. A v24.10 image and a v25.12 image on the same router are not the same software, and the project does not describe a support window for either line in the README.

The repository is not archived, and its last push was on 2026-11-02.

The build path may not contain spaces, and Cygwin is out

The Development section names the host systems you can build on: GNU/Linux, BSD or macOS.

There is one condition attached, and it is the kind that costs an afternoon if you hit it cold. A case sensitive filesystem is required, and Cygwin is unsupported precisely because it lacks one.

The Makefile enforces the related constraint directly. It defines TOPDIR from the current directory and then raises an error if that path contains a space, with a message saying the path to the OpenWrt directory must not include any spaces.

Two more details in the same file are worth knowing before a first build. It forces LC_ALL, LANG and TZ to fixed values so the build does not inherit your locale, and it prepends the staging directory's host bin directory to PATH, so tools built earlier in the same tree win over system ones.

Four commands and a two-line package list

The quickstart is four steps, and the order matters.

Run ./scripts/feeds update -a to obtain the latest package definitions defined in feeds.conf or feeds.conf.default. Run ./scripts/feeds install -a to install symlinks for all obtained packages into package/feeds/. Run make menuconfig to choose the toolchain, target system and firmware packages. Then run make, which downloads the sources, builds the cross-compile toolchain, and cross-compiles the GNU/Linux kernel and all chosen applications for the target system.

The build dependencies are listed as a short block:

binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.8+ rsync subversion unzip which

Note the version floors written into the names: gcc-6+, make4.1+ and python3.8+. Those are minimums, not pins, and the README points to a build system setup page for the complete list with distribution-specific packages.

The top level is four build stages and a Kconfig

The root directory is the build system, and the names describe the order.

tools/, toolchain/, target/ and package/ are the four stages, and the Makefile chains them with stamp files: toolchain/stamp-compile depends on tools/stamp-compile, target/stamp-compile depends on the toolchain stamp, and package/stamp-compile depends on the target one. Nothing starts until the stage before it is stamped.

Alongside them sit include/ for the shared make fragments, with debug.mk, depends.mk, toplevel.mk and subdir.mk named explicitly, config/, and Config.in at the root, which is where the menu that make menuconfig presents comes from. rules.mk and feeds.conf.default handle the two cross-cutting concerns: build rules and the package feeds.

Then there is BSDmakefile, which is there for the BSD hosts the README said you can build on, a scripts/ directory that both the feeds commands and the quickstart depend on, and the licence files, COPYING plus a LICENSES/ directory.

Packages come from four sibling repositories and one installer

The main repository does not contain most packages, and the README explains the arrangement.

The main tree uses multiple sub-repositories to manage packages of different categories, and all packages are installed through the OpenWrt package manager called opkg. Four siblings are named. LuCI is the web interface, described as a modern and modular way to control the device via a web browser, at github.com/openwrt/luci. OpenWrt Packages is the community repository of ported packages. OpenWrt Routing holds packages focused on mesh routing. OpenWrt Video holds display servers and clients, naming Xorg and Wayland.

Support is split the same way. Users get the forum for usage, projects, discussions and hardware advice, plus a support chat channel named openwrt on oftc.net. Developers get a bug tracker at bugs.openwrt.org, a development mailing list for sending patches, and a separate channel named openwrt-devel.

The licence is GPL-2.0, stated in the README and mirrored by a COPYING file and an SPDX header in the Makefile.

Editorial conclusion

OpenWrt fits anyone who wants to replace a vendor's fixed image on hardware it supports, and developers who want to build one application without assembling a whole firmware around it. Do not clone the GitHub mirror expecting to push to it, because the description says it is not active for check-ins. Before you start, confirm your device is in the Hardware Database and use the Firmware Selector to find a factory image, then read the Info link for that image rather than general instructions. If you are building, check the path first: the Makefile refuses a build directory containing a space.

Frequently asked questions

Official sources

1. Issues
2. openwrt/openwrt on GitHub
3. Project website
4. README
5. Releases