open.mp: a multiplayer server for San Andreas that keeps SA-MP compatibility

The whole point is that existing scripts keep working

The repository description is one sentence and it defines the project's entire value proposition: Open Multiplayer, a multiplayer mod fully backwards compatible with SA-MP.

That compatibility claim is the technical constraint that shapes everything else in the repository. A San Andreas multiplayer server has two sides of the wire: the game client that players run, and the server plugins, often called scripts, that implement game modes. Those scripts talk to the server through an SDK, and if a server implementation changes that SDK, every script written for SA-MP breaks at once.

open.mp takes the position that the wire protocol and the plugin-facing API should not change. The README's structure table is built around that promise. The `SDK/include` directory holds the core SDK headers and they are marked stable between versions. The component and plug-in SDK headers under `SDK/include/Server/Components/*/` are also stable between versions.

Everything else in the tree is explicitly not stable, and the README repeats the warning in three separate places. `Shared/NetCode/` holds the netcode headers, the RPC and packet read and write structures, and they are marked NOT stable between versions. `Shared/Network/` holds network utility headers with the same warning. The server implementation under `Server/Source/` is not stable and the instruction is to not use headers outside the Source folder. The component implementations under `Server/Components/*/` carry the same note about not using headers outside the component's own folder.

For a plugin author, that table is the whole API contract. You include from `SDK/include` and you are safe across versions. You reach into netcode or server internals and your plugin compiles today and breaks on the next release.

Five concepts define the vocabulary of the codebase

The README defines a small glossary, and it is worth reading because the terms are used throughout the code and the naming is not what you would guess.

An Entity is something that can appear in the 3D world of the game. A Pool is a container of something with a limited amount of IDs, which is the game's version of a handle table. A Component is something conceptually different enough to be separated into its own module. Something Extensible is something to which extensions can be added while preserving ABI compatibility, and an Extension is something that adds functionality to an extensible and preserves ABI compatibility.

Those last two entries are where the compatibility promise lives as a design idea rather than as a policy. The server is built out of components so that new functionality can be added as an extension without recompiling or breaking what already exists. The word ABI is doing real work there, since it refers to the binary interface, and preserving it is a stronger requirement than keeping source code compiling.

The entity and pool concepts are how the server represents the game world. Entities are the things you can see, and a pool is how the server hands out identifiers for them, with a fixed number of IDs available. This is a deliberate design choice for a game server, where the set of active objects is bounded and the server needs to refer to them cheaply in packets.

The glossary is short enough to be memorable, which is a sign that the concepts are load-bearing rather than decorative. Nothing in the visible documentation explains them further, so a contributor reading the source is expected to already have this table in mind.

Building is delegated to BUILD.md, and the build tooling spans three systems

The README does not contain build instructions. It points to BUILD.md for source checkout, prerequisites, and build instructions for Windows, Linux and macOS, and that is the whole of it.

The top level of the repository shows what a build involves. There is a `CMakeLists.txt`, so CMake is part of the build, and there is `build.ps1`, a PowerShell script, which suggests the Windows path is driven from PowerShell. There is a `docker/` directory, so a containerized build or runtime is supported. `format.bat` and a `.clang-format` file together suggest a formatting workflow with a Windows entry point, and `.clang-tidy`-style linting is implied by the presence of `CODING.md`.

The dependency model is git submodules. There is a `.gitmodules` file and a `lib/` directory described as containing various submodules and third-party libraries. That is a meaningful choice for a project that wants a pinned, reproducible dependency set, and it also means a source checkout that skips submodules will not build, which is exactly the kind of detail BUILD.md exists to cover.

The repository also carries `CAPI`, a directory whose purpose the README does not describe, and `Tools/`, plus a file called `vs-chromium-project.txt`. The latter is a familiar artifact in projects that borrow configuration from Chromium, but the README does not explain what it does here, so it is best treated as an implementation detail rather than a documented feature.

A build status badge points at a GitHub Actions workflow, and the default branch is master. The repository is not archived, the last push was on 2026-10-15, and the release history shows v1.6.7.3218 on 2026-10-14, v1.5.8.3079 on 2025-12-17 and v1.4.0.2779 on 2025-01-12. The four-part version numbers are worth noting, since a patch-level release can carry a build identifier, which is a common pattern for software that is rebuilt against a moving dependency set.

A plugin author needs the SDK, not the server source

The repository layout draws a line that determines what a third-party plugin can safely use, and it is worth restating as a practical rule.

Inside the `SDK/include` tree are the core headers, stable between versions, and under `SDK/include/Server/Components/*/` the component and plug-in SDK headers, also stable between versions. Those are the headers a plugin includes.

Outside that tree, the netcode headers with their RPC and packet read and write structures, the network utility headers, the server implementation and the component implementations are all marked unstable, each with an instruction not to use their headers outside their own folder.

The distinction is subtler than it looks, because a plugin that wants to hook a component's behavior might reasonably reach for the component's implementation header. The README forbids that, and the reason is the compatibility promise itself. A plugin compiled against a netcode struct layout, or against a server-internal API, will be rebuilt against a different layout on the next release and will fail in ways that are hard to diagnose, since the failure appears at load time on a server the plugin author does not control.

The concepts table reinforces this. Components exist so that functionality can be added as extensions while preserving ABI compatibility, and a component's internal header is not part of the surface other code may rely on. The Extensible and Extension entries are the mechanism, and the stable-header marking is the contract.

The practical consequence is that a plugin written against the SDK should continue to work across server upgrades, and a plugin written against anything else should not be expected to.

Compared with staying on SA-MP and with writing a server from scratch

There are two other paths, and the trade-offs are clearer once the compatibility promise is understood.

The first is to stay on SA-MP itself. The argument for that is exactly the one open.mp is answering. If the existing server works, if the scripts work, and if the player base is stable, then the only reason to move is the state of the upstream code. The argument against is that a server implementation whose ecosystem depends on a single organization's maintenance decisions is a long-term risk, and open.mp's existence is a statement that this risk is worth addressing. The cost of moving is that it is a migration: plugins, configuration and player expectations all have to be carried over, and the SA-MP compatibility promise is what makes that migration tractable rather than a rewrite.

The second is writing a server from scratch, which nobody serious would do for a game with this much existing tooling, and the repository structure shows exactly how much work that would be. There is a components system with an extension mechanism designed for ABI preservation, a netcode layer with defined RPC and packet structures, a shared network utility layer, and a core server implementation. Each of those is a design decision that took iteration, and the component and extension model in particular is the kind of thing that is much cheaper to adopt than to reinvent.

The middle position, and the one open.mp actually occupies, is a reimplementation that copies the wire behavior exactly. The compatibility claim means that the expensive part of a server, the accumulated plugin ecosystem, survives the move. What does not survive is the code of the old server itself, and that is the whole bet.

Editorial conclusion

Adopt open.mp if you are running a San Andreas multiplayer server and want a codebase that is being maintained rather than frozen, while keeping your existing SA-MP scripts and clients working unchanged. Do not adopt it if you are starting a new game server on another engine, since the compatibility target is specifically SA-MP and the San Andreas client. Verify first which of the SDK headers your plugin code actually includes, because the README states that the netcode, network utility and server source headers are not stable between versions and must not be used outside their own folders.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. openmultiplayer/open.mp on GitHub
3. Project website
4. README
5. Releases