Is OpenWrt Still a Reliable Base for a Commercial Product?

Somebody in your organisation has almost certainly proposed OpenWrt as the base for a networking product. It is a reasonable proposal. The alternative is a vendor SDK built on a kernel three years behind mainline, shipped as a tarball, with a driver stack nobody outside the silicon vendor understands.

That comparison has been flattering to OpenWrt for a long time. It still is. But "better than the vendor SDK" is not the same as "suitable for a product you will sell for eight years and are legally obliged to patch", and that second question is the one that now decides the answer.

This article is about the difference between those two questions.

What OpenWrt is now, as distinct from what people remember

The mental model many engineers still carry is of a firmware replacement for consumer routers, flashed by enthusiasts, held together by shell scripts. That has not been an accurate description for a decade.

What you actually get today is a cross-compiling build system in the buildroot tradition, a package feed of several thousand entries, a kernel that tracks upstream far more closely than any vendor SDK, and a configuration layer — UCI — that gives every subsystem a consistent, scriptable interface. There is an SDK for building packages against a fixed toolchain, and an ImageBuilder for assembling firmware images without compiling from source. The project also now ships reference hardware of its own, which matters mainly because it gives the developers a target they control end to end.

None of that is hobbyist infrastructure. It is, in most respects, more disciplined than what a silicon vendor will hand you.

The engineering challenges, honestly stated

You inherit a patch stack, and it is yours now

OpenWrt tracks upstream kernels but does not run them unmodified. Every target carries patches: device tree definitions, drivers not yet upstream, fixes for silicon errata, backports. That patch stack is the reason your board boots.

It is also the reason a kernel bump is never routine. When OpenWrt moves to a newer kernel, the patches move with it, and any patch you added on top has to be rebased against a moving target. Teams that treat "we will take the next release" as a scheduling assumption find out otherwise the first time a rebase touches their driver.

The practical consequence: from the moment you add your first patch, you are not running OpenWrt. You are running a fork, and forks need an owner with time allocated.

Migrations that arrive mid-product-life

The project makes architectural changes that are correct and disruptive at the same time. Two examples that have cost real programmes real months:

Neither change is a criticism of the project. Both are what a healthy project does. The point is that a distribution improving itself and a product that shipped two years ago have different interests, and nobody is reconciling them on your behalf.

The flash and RAM floor keeps rising

Devices with 4MB of flash and 32MB of RAM were dropped from support some years ago, and the floor has continued to move. Modern kernels, current wireless stacks and TLS libraries are simply larger than they were.

For a product still in design this is a BOM conversation, and an easy one to get wrong: the flash size that fits today's image with no headroom is the flash size that cannot take a security update in year four. For a product already in the field with fixed hardware, it is a hard stop, and it arrives without warning as a build that no longer fits.

The feed is a feed, not a supported product surface

Several thousand packages are available. That is a genuine asset and it is routinely misread.

A package being present in the feed does not imply that anyone is tracking vulnerabilities in it, that it has been tested on your target, or that it will still be there next release. The core system receives real security attention. The long tail does not receive the per-package curation that a general-purpose distribution with a dedicated security team provides — and it does not claim to.

If a feed package ends up on the critical path of your product, you have adopted it. Someone in your organisation now owns its CVE tracking, whether or not that has been said out loud.

The commercial question, which is the one that actually decides it

Everything above is ordinary embedded engineering. Any platform has an equivalent list. The reason this decision has changed character is regulatory.

Under the UK's Product Security and Telecommunications Infrastructure regime, a consumer connectable product sold in the UK must meet baseline security requirements and — the part that bites — must publish the period for which security updates will be provided. Under the EU's Cyber Resilience Act, manufacturers face vulnerability handling and reporting obligations across a defined support period, with the substantive requirements phasing in through 2026 and 2027.

Read those two together and a specific question falls out:

For OpenWrt, it generally does not. Stable branches receive security attention for a period measured in months to a couple of years, and the project publishes no long-term support commitment of the kind an enterprise distribution offers. This is not a defect. OpenWrt is a volunteer-led project and has never promised otherwise.

But if you have declared five years of security updates and your base branch goes quiet after two, the remaining three years are yours to deliver. That is a staffing line, and it belongs in the business case at the point the platform is chosen, not discovered in year three.

There is a licensing dimension too, and it is the easier of the two. OpenWrt is GPL-licensed, so shipping a device means meeting source distribution obligations for the licensed components. This is well-trodden ground and entirely manageable, provided the build is reproducible enough that you can actually produce the corresponding source for a shipped image years later. Teams that build from a developer's machine rather than a pinned, versioned CI pipeline discover the problem at exactly the wrong moment.

So: is it still viable?

Yes — with the emphasis on what you are actually taking on.

It is a good base when your product is networking-centric and would otherwise depend on a vendor SDK; when you have, or will hire, someone who can rebase a patch stack and read kernel code; when your declared support window is short enough to sit inside a branch lifetime, or you have budgeted to maintain your own; and when the mainline-tracking kernel and current wireless stack are worth real money to you, which for anything Wi-Fi they usually are.

It is a poor base when nobody owns the fork; when the hardware is already fixed with marginal flash; when the product must be certified against a frozen software baseline that you cannot economically re-establish after each rebase; or when the organisation's actual expectation is a supported distribution with someone to call. OpenWrt is not that, and choosing it while believing otherwise is the failure mode we see most often.

The honest summary is that OpenWrt's reliability was never really the open question. The open question is whether your organisation is set up to run a fork of an embedded Linux distribution for the life of a product. Where the answer is yes, it remains one of the strongest bases available. Where the answer is no, the cost does not disappear — it just arrives later, in the form of an update you have promised and cannot build.

What we would suggest doing about it

If OpenWrt is already in your product, three checks are worth doing this quarter.

Write down the support window you have published, and the maintenance status of the branch you are on, on the same page. If the first number is larger than the second, you have found your risk, and it is better found now than in a regulatory response.

Establish whether you can rebuild a shipped image today. Pinned feed revisions, pinned toolchain, in CI, from a clean checkout. If the answer involves a particular laptop, that is the first thing to fix — it is both a GPL compliance exposure and the thing that makes a security patch a two-week job instead of a two-day one.

List the feed packages on your critical path and name an owner for each. Not a team, a person. Most organisations find between three and ten packages that everything depends on and nobody is watching.

If you are still choosing, evaluate against your support obligation rather than against the vendor SDK. The SDK comparison makes OpenWrt look obviously right. The support-window comparison is the one that tells you what it will cost.

Sources and further reading:
OpenWrt project, Developer guide
OpenWrt project, DSA switch configuration
UK Government, The Product Security and Telecommunications Infrastructure regime
European Commission, Cyber Resilience Act