River project swims against the Wayland tide with modular window management

Breaking a big hard problem up into smaller ones? That'll never catch on

FOSDEM 2026 Isaac Freund's River compositor brings a little old-fashioned modularity and customizability to the brave new Wayland world.

One of the great joys of the FOSDEM conference is catching program items that introduce radical ideas you'd never considered might be possible. Almost by accident, The Reg FOSS desk found itself in one of these – a talk titled "Separating the Wayland Compositor and Window Manager."

In it, Freund introduced his River project, which he describes as "a non-monolithic Wayland compositor." River brings to Wayland the idea of a window manager as a separate program, and it already supports a list of ten different WMs that can work with it.

Freund is a member of the core team of the Zig programming language, also the basis of the Phoenix X11 server we mentioned last month, and he also works on wlroots, a set of modules for building Wayland compositors. He explained that with River, he "plans to change the Wayland architecture to make it more easy to experiment."

Currently, a Wayland compositor combines three primary functions into one. It must act as a display server, it must manage windows, and it must composite those windows together to be displayed on screen. The River project, which is about three years old now, splits this up. It's a display server and it's a compositor, but it doesn't do window management. Instead, it offers a documented window management protocol so that another, separate program can do the window management.

He says that in the month and a half after he published the protocol, "at least nine independent WMs were written."

As the accompanying slides [PDF] explain, the core of the program is a fairly simple state machine, and the window manager's job is letting you arrange them and decorate them as you wish. It's not involved in displaying them, so it's very fast. As he noted with a grin, this offers you the freedom of choice in X11-style "decorations" (title bars, buttons, and so on), compared to GNOME and its "client side decorations."

It's important to note that River needs its own window managers. It won't let old X11 window managers run on Wayland – that's not what it's aimed at. For that, take a look at the Wayback project we covered last year – it's moved to hosting on GitLab and is up to version 0.3 by now.

Forestalling some obvious questions, he included a section headed simply "Why?" The points he called out were that writing window managers is much easier than before. They can be developed in high-level languages with no increase in latency, and the user can restart or even switch to a different window manager without losing their session. He expressed the hope that this will help to promote diversity in the Wayland ecosystem, noting that even today there are still lots more X11 window managers than there are Wayland compositors.

There was also a "Why not?" section, which noted that this was not for non-traditional environments like virtual-reality headsets and so on. River doesn't change how the contents of windows are displayed, so it can't offer things like wobbly windows and other special effects. The protocol, he said, is stable: "We do not break window managers," an intentional nod to one of the rules set by kernel supremo Linus Torvalds concerning Linux's kernel/userland split.

In the Q&A section at the end, he called out one advantage of his approach. One of the River window managers is his own, and he says that it's written in a "very high-level language" and "it's slow and totally unoptimized – but it's fast and stable." This is because there are no round trips between the window manager and the River server-cum-compositor. Indeed, there are "no calls at all, unless windows are moved or something. Otherwise, it stays out of the way." ®