fvwm3: a rewrite of a thirty-year-old window manager

What fvwm3 is, stated in two sentences

The README is short, and the opening paragraph is the whole description: Welcome to fvwm, version 3 is a multiple large virtual desktop window manager, and it is the successor to fvwm-2.6.x.

The design goal follows immediately: fvwm3 is intended to be extremely customizable and extendible while consuming a relatively small amount of resources. Those two goals are in tension, and a window manager that has to be both means the configuration is a program rather than a settings file, and the extension mechanism is a real API rather than a plugin format.

The primary language is C, and the X11 heritage is not hidden. The topics list fvwm, fvwm3, window-manager and x11-wm, and the AI Policy section explains the reason for the codebase's character: the people who wrote it had to think about how fvwm interacted with xlib and xserver implementations and work a lot of things out for themselves.

The project is alive and the release cadence is slow and steady. The recent releases are 1.1.5 from 2026-06-27, 1.1.4 from 2025-11-08 and 1.1.3 from 2025-06-01, and the last push was on 2026-09-11 with the project not archived. A version below 2.0 after more than thirty years of the fvwm line is itself a statement about how the project chooses to evolve.

The licence is recorded as a custom one that GitHub cannot classify, with the COPYING file at the repository root, and the homepage is not given on the repository itself.

The fvwm2 compatibility promise, and where it stops

The Fvwm2 Compatibility section is the part an existing fvwm user will read first, and it is careful about what it claims.

Although an existing fvwm2 configuration should mostly work with fvwm3, it isn't guaranteed to work without some modifications. The reason given is that fvwm3 has changed, often removing long-standing deprecated options. More details about those changes can be found in a linked discussion on the project's GitHub Discussions.

That is a well-judged way to handle a rewrite of a mature project. The temptation in a rewrite is to claim full compatibility, and claiming it is a way of not having to say which behaviours changed. This README instead says three things: most configurations work, some do not, and here is exactly which options were removed and where to read about it. A user with a decade-old fvwm2 configuration learns before upgrading rather than after.

The removals are the interesting part for anyone deciding whether to migrate, because a deprecated option that has been sitting in a config for years is exactly the kind of thing that breaks silently. The project's own news file, NEWS at the repository root, and the CHANGELOG.md are where the history lives, and the README points at the changelog for the release history.

The trade is the usual one: you get a codebase that is being actively shaped rather than one that accumulates compatibility shims for options nobody uses. For a project that has been alive for over thirty years, that is the more valuable direction.

The build is Meson, and the container assumes a prebuilt base

The top-level tree shows a build system that has moved past the old autoconf approach. There is meson.build at the root, meson.options for the configuration options, a meson-scripts/ directory, a build/ directory, and a Dockerfile. The presence of a shell.nix points at a Nix-based environment as well, and a Dockerfile.build-style base image is used for the container build.

The Dockerfile is a thin wrapper over a prepared build image:

FROM fvwmorg/fvwm3-build:latest

The environment then sets GOROOT and PATH for Go, with GO111MODULE set to on, copies the source into /build, and builds it with Meson:

RUN meson setup --reconfigure build -Dmandoc=true && meson compile -C build

Two things follow from that. The container build assumes the dependency environment is already baked into the fvwmorg/fvwm3-build image, so it is a way to produce a binary rather than a way to bootstrap a toolchain from scratch. And the -Dmandoc=true option is a build-time feature switch, which tells you the project supports optional pieces rather than requiring everything.

The Go environment is there for a reason. The tree has a perllib/ directory, and the topics of the project do not suggest a Go runtime dependency for the window manager itself, which points to the Go toolchain being present for a build or auxiliary tool rather than for the core binary.

The rest of the tree is what a large C project accumulates: an fvwm/ directory for the main source, libs/, modules/ for the loadable extension modules, contrib/ for contributed pieces, default-config/ with a shipped configuration, utils/ for helper programs, a bin/ directory, po/ for translations, doc/ for documentation, and dev-docs/ for the developer-facing notes.

Customisation through modules and a scripting layer

The repository layout is the clearest evidence for how the extensibility goal is realised, because a window manager that is extensible has to have a place where the extensions live.

The modules/ directory is the extension point. A window manager that supports loadable modules has an API that those modules compile against, and the API is versioned with the window manager, which means a module written for fvwm2 does not automatically work with fvwm3. That is a real cost of the rewrite, and it is why the modules directory is worth looking at before you decide whether the extensions you rely on are ready.

The perllib/ directory suggests a scripting layer for configuration. A window manager whose configuration is a program needs a language to be a program in, and a Perl library directory in the tree is consistent with the fvwm tradition, where the configuration file has long been executable rather than declarative. The dev-docs/ directory holds what people working on the code rather than using it need to read.

The default-config/ directory is the other half of the story, and it matters for evaluation. A project that ships a default configuration is making a claim that the out-of-the-box experience is usable, which means you can install it and see something before you learn the configuration language. The po/ directory with translations is a further signal of a project with a real user base rather than a hobby codebase, since translation work is only worth doing when people are reading the documentation in more than one language.

The documentation structure is unusually well organised for a C project of this age: doc/ for user documentation, dev-docs/ with a DEVELOPERS.md for contributors, a TODO.md that sometimes gets things worked on, and NEW-COMMANDS.md where new commands and configuration file syntax are documented before they land.

The AI policy is the most unusual thing in the repository

The README contains an AI Policy section that is worth reading in full, because it is a deliberate and reasoned position rather than a passing remark.

The argument starts with the project's age: FVWM is an old project, well over 30 years of development. It came at a time when the people working on it really knew their stuff, and they had to think about how fvwm interacted with xlib and xserver implementations and work a lot of things out for themselves. All of it was done without AI, obviously.

The claim that follows is that it is important that FVWM continues to be maintained with this history in mind, and that introducing AI would destroy that approach in a way which also destroys the people who have worked on it over the many years it has been alive. The word protect appears, and the policy says it is important to protect this at all costs.

The practical terms are specific. The use of AI in this project means it cannot be used for code generation, opening issues, writing or creating pull requests, and creating documentation updates. Such examples where this is submitted will be ignored and closed outright.

That last sentence is the part that matters for anyone reading the repository with an automated assistant. The prohibition is not a request, it is a stated mechanism, and this article is written in a way that respects it by describing the project rather than generating code for it.

Whether you agree with the position is a separate question. What it does concretely is remove a category of contributor from the process, and it does so in a project where the maintainers argue that the deep knowledge of the old code is the asset.

Where to go for help, and how the project is organised

The support structure is conventional and healthy for a project of this age. There is a strong community on IRC on libera.chat in the #fvwm channel, and the Fvwm Forums at fvwmforums.org where you can ask questions. Issues for bugs can be opened and any and all bug reports are appreciated.

The distinction between those channels is worth understanding. A forum question about how to configure a menu is a support question, and an issue is a bug report. For a window manager with a configuration language, most of what people need is configuration help, and the forums and IRC are where that gets answered. A IRC channel is also a good fit for a project whose users are the people who wrote the documentation.

The project structure in the tree supports the same division. The .github/ directory holds the issue and contribution templates, .editorconfig and .clang-format handle formatting, and the .disabled-travis.yml file is a visible fossil of a CI migration, with the actual CI on GitHub Actions as the build status badge shows. There is a .mailmap for contributor attribution, a .current-version file and a .release-status file, and a COPYING file rather than a LICENSE, which is a hint about the age of the project's conventions.

The development documentation is the part to read if you want to contribute. dev-docs/DEVELOPERS.md is the starting point, dev-docs/TODO.md lists what is outstanding, and dev-docs/NEW-COMMANDS.md is where new commands and configuration file syntax are written down as they are designed. The README asks people to open a GitHub issue or contact the maintainer directly to discuss a particular feature or an issue they need help with.

What thirty years of a window manager buys you

The honest case for fvwm3 is not that it has more features than a modern alternative. It is that it is a project where the configuration is the point.

A window manager that is extremely customizable and extendible is one where the user ends up with a desktop that matches how they work, and that requires a configuration language expressive enough to express it, modules rich enough to extend the behaviour, and a low enough resource cost that the whole thing stays out of the way. FVWM3's thirty years of development went into exactly those three things, and the people who did that work are, by the project's own account, the reason it is worth maintaining.

The cost of that approach is what the fvwm2 compatibility note describes. A rewrite that removes deprecated options breaks configurations, and the documentation will be your friend here because the changes are written down rather than left to be discovered.

The upgrade path for an existing fvwm2 user is therefore: read the compatibility discussion, read the changelog for the release you are taking, copy your configuration, and expect to remove the options that were dropped. For someone starting fresh, the default-config directory plus the documentation is the entry point, and the modules directory tells you how far the platform can be pushed.

What it will not give you is the ecosystem of the larger desktops, or the modern conveniences, or an active community of the size a mainstream window manager attracts. FVWM3 is a small, old, deliberately unfashionable project with a clear point of view about how a window manager should be shaped, and for the person who agrees with that point of view, that is the entire proposition.

Editorial conclusion

Adopt fvwm3 if you want a highly configurable virtual-desktop X11 window manager that is configurable to the point of being a personal environment rather than a set of preferences, and if you are prepared to learn its configuration language and its extension mechanism. Do not adopt it expecting drop-in fvwm2 behaviour, because the project states that an existing fvwm2 configuration should mostly work but is not guaranteed to, since long-standing deprecated options have been removed. Before you commit, read the changes discussion linked from the README, check the CHANGELOG for the release you are taking, and read INSTALL.md, because the build is Meson based and the container image assumes a prebuilt fvwm3-build base.

Frequently asked questions

Official sources

1. fvwmorg/fvwm3 on GitHub
2. Issues
3. README
4. Releases