A panel on open source in customer premises equipment. Two things I argued.

Container lifecycle management is worth having for the operational change, not the applications. Most of the discussion about containers on gateways is about what you can run on them. The part that matters to an operator is what it removes, which is the scheduled outage window for a monolithic firmware upgrade. Being able to add or remove a service on a device that stays up is a different operating model, and it is the reason to do this work at all. I made the longer version of that argument in the talk at the same event.

Most tier-one operators will be on USP within two to three years. That is my expectation rather than a forecast I can cite. The interim is the awkward part, because mixed estates still need legacy protocols backported alongside USP and that carries a real cost while it lasts. I do not think the direction is in doubt.

Two other threads from the discussion are worth recording.

The first was runtime maturity. LXC is what most container deployment on these devices runs on today, and it is heavy for the memory envelope they have. containerd, crun and OverlayFS v2 came up as where the efficiency is going to come from, which matters because the memory headroom on this class of device is not going to grow much.

The second was standards fragmentation, and it was the more interesting argument. Operators adopt the segment of a data model they need and leave the rest, so no two deployments are alike. The comparison drawn was to POSIX, which worked because it settled a common area everyone had to meet. The suggestion was that standards bodies would get further by defining the practical use cases first, the way an open-source project does, and writing the specification after that.

The reason so many devices in the field run old software is not that operators are careless. It is that the unit of change is wrong. A broadband portfolio runs to hundreds of variants across gateways, access points and fixed wireless, and the traditional way to fix anything is to build, qualify and ship a whole firmware image per variant. Small fixes cost the same as large ones, so small fixes wait.

Modular package management is the way out of that. Alpine and APK let a component or a container be updated on its own without rebuilding the image around it. The benefit I did not expect to matter as much as it does is the bill of materials: APK tells you what is actually inside a given image, so dependency tracking, open-source license compliance and vulnerability response become a lookup rather than an investigation. With the Cyber Resilience Act reporting obligations arriving, that stops being a convenience.

The management plane has to be standards-based for the same reason the packaging does. USP, the Broadband Forum’s TR-369, is what makes remote configuration, monitoring and troubleshooting work across devices you did not build, and every operator estate of any size is multi-vendor. prplLCM covers the lifecycle half. The discipline worth keeping there is to run the open implementation as it is rather than fork it, because a fork has to be carried against every upstream change afterwards.

The part I would push hardest on is security. Running privileged containers on a device in someone’s home is not an acceptable end state. What it has to become is unprivileged execution by default, access control lists bounding what an application can reach on the host, and signed images so the device can verify what it has been asked to run. None of that is exotic. It is ordinary practice everywhere else in the industry, and the edge has been slow about it.

Residential broadband devices have had spare compute for years and almost nothing runs on them. This talk was about why that gap has stayed open and what has to be true before it closes.

The constraint people underestimate is memory. A gateway will give a container something on the order of 128MB, which rules out most of what the container ecosystem assumes about its environment. That pushes you to OCI images built on Alpine and musl rather than glibc, and to stripping virtual binaries until the image lands somewhere between 15 and 20MB. Smaller also means a smaller attack surface on a device sitting in someone’s home.

The second constraint is the build. These are 32-bit and 64-bit ARM targets, and a developer writing C, C++ or Go should not have to think about that. Cross-compilation belongs in a container-based toolchain behind a CLI, wired into dev containers and CI, so that shipping to a gateway looks like shipping anywhere else.

The third is lifecycle, and it is the one the industry has spent longest avoiding. Installing, updating and removing third-party software across a fleet of millions of devices is a management problem rather than a packaging one, and the legacy remote-management model was never designed for it. prplLCM is the open answer to the runtime and lifecycle half.

The half I did not have a good answer for then, and still think is unresolved, is the layer above it: catalog, curation, signing, distribution. The runtime has been open source for years. Nothing at the catalog layer is.