OpenRA is an engine plus three mods, and the wiki overview is labelled outdated

The three games are mods, not separate programs

The directory layout explains the architecture before any documentation does. There is OpenRA.Game for the engine, OpenRA.Launcher and OpenRA.WindowsLauncher for the front ends, OpenRA.Server for dedicated servers, OpenRA.Utility, OpenRA.Platforms.Default for the SDL and OpenGL platform layer, and OpenRA.Test for the test project. The games themselves sit beside those as OpenRA.Mods.Cnc, OpenRA.Mods.D2k and OpenRA.Mods.Common, with the mod content under mods/. So the engine is generic and the games are content loaded into it, which is the reason a separate Mod SDK exists at all and the reason a total conversion is a realistic project. What ships is an engine with the three games as distributed mods; the Makefile's install target compiles and installs Red Alert, Tiberian Dawn and Dune 2000 together.

Gameplay is yaml, so a broken ruleset is a data error

Behaviour is not all in C#. The project offers a Mapping tutorial and states plainly that custom rules can change gameplay drastically, and there is an auto-generated Trait documentation for the yaml files that hold those rules. A trait is how a piece of unit, weapon or tile behaviour is declared, and the documentation is generated rather than written, which is why it can track a branch. The check that catches mistakes is in the Makefile, and it is narrow:

# to check the official mods for erroneous yaml files, run:
#   make test
#
# to check the engine and official mod dlls for code style violations, run:
#   make check

make test covers the official mods only. Your own ruleset is data, so a typo in a trait name, a missing dependency between traits or a unit that references an image that is not there will not fail a compile; it fails when the game loads it. Scripted missions go further out into data still, through a Lua API whose documentation lives on its own site. Outside the official mods, you are left debugging yaml by playing the game.

Native dependencies are bundled unless you ask for the system's

The build defaults to bundling, and that default is a decision with consequences. The Makefile sets DEPENDENCIES to bundled unless you override it, and the comment block at the top of the file gives the alternative in one line: make DEPENDENCIES=system compiles using the system libraries for native dependencies. A configure-system-libraries.sh script sits at the root beside it, and there is a fetch-geoip.sh script as well, which tells you some data is fetched at setup time rather than compiled into the binaries, though nothing at the top level says which component consumes it. The bundled route is the reproducible one, since you get the library versions the project chose, and it is what a first build should use. The system route is what a distribution package wants, because it stops shipping a second copy of SDL inside every build, and it is where version mismatches with your distribution show up as build errors instead.

The default branch is bleed, and the newest tag is a playtest

Version handling is deliberately loose. The default branch is bleed, and the recent tags are all playtests: playtest-20261026 (2026-10-25), playtest-20261011 and playtest-20260222. The Makefile resolves the version at build time with git name-rev, and if that fails it falls back to a string built from the short commit hash, so a build from an untagged commit reports itself as git-<sha> rather than as a release. The comment above that line notes it is only for use in the target version. For anyone pinning a build, it means a checkout of bleed is not a version, a playtest tag is not a release, and the only stable handle on what you ran is the commit you built from.

The Hacking wiki page is labelled outdated, and the docs come in two flavours

The documentation is where this project is most uneven, and it says so itself. A contributor is pointed at INSTALL.md in the repository and at the Compiling wiki page for setting up a development environment, and then at the Hacking page for an overview of the engine, which is described in the same sentence as a now very outdated overview. That is an unusual thing for a project to state about its own documentation, and the practical effect is that the engine's architecture has to be read out of the source tree, which is what the directory layout in the first section is for. The generated docs add a second wrinkle: the Lua API is published under a release path while the trait documentation is published under a latest path, so both exist and they are pinned to different things. Following the wrong one gives you an API for a build that is not the one in front of you.

Platform support is a claim in the description, not a build matrix

The repository description states that OpenRA runs on Windows, Linux, *BSD and Mac OS X, and the tree is arranged to match: launch-game.sh and launch-dedicated.sh for Unix, launch-game.cmd and launch-dedicated.cmd for Windows, plus make.cmd and make.ps1 for building without a Unix shell. The Makefile picks the target itself when you do not pass one, reading uname -s and uname -m and mapping the result, including the case where uname reports Darwin but the dotnet runtime identifier contains no x64, which maps to an osx-arm target. Installing is the standard autotools-shaped arrangement, with prefix defaulting to /usr/local and bindir, libdir, mandir and a gameinstalldir under libdir:

# to compile and install Red Alert, Tiberian Dawn, and Dune 2000, run:
#   make [prefix=/foo] [bindir=/bar/bin] install

There are also make targets for the FreeDesktop startup scripts, desktop files, icons and MIME metadata, for AppStream metadata, and for the Unix man page.

GPL covers the engine, and the Windows signature covers only official builds

Two separate things are worth reading carefully. The licence is GNU General Public License version 3 or later, with COPYING in the repository and the copyright held by the OpenRA developers and contributors, so the engine is free software and the terms are the standard copyleft ones. The games are a different object: the distributed mods are described as a reimagining of Red Alert, Tiberian Dawn and Dune 2000, and the project states that EA has not endorsed and does not support this product. Third-party total conversions are uploaded to a Mod DB profile in their own right. Signing sits on the same dividing line. Free code signing on Windows is provided by SignPath.io with a certificate from the SignPath Foundation, which tells you who produced that one binary. It says nothing about a mod or a map you downloaded from someone else, so the signature is worth checking on the official build and worth nothing on the rest.

Editorial conclusion

OpenRA fits a player who wants the early Westwood games rebuilt as free software, and a modder who is willing to work in yaml traits. It does not fit a team that needs a current engine overview in its documentation, since the Hacking wiki page is labelled very outdated and the two documentation trees are pinned differently. Before you build on it, check the branch you are on: the default is bleed, the newest tag is playtest-20261026, and a build from a commit with no tag reports a version string of git-<sha>. Then run make test, because a ruleset mistake is a data mistake and nothing in the compiler will catch it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. OpenRA/OpenRA on GitHub
3. Project website
4. README
5. Releases