Openfoot Manager is a Rust simulation engine wrapped in a Tauri shell, and the depth is a setting

No licensed database, and the depth is a dial

Openfoot Manager is a free and open source football or soccer management game, licensed under the GPLv3, inspired by the management genre that Football Manager, Championship Manager and Bygfoot built.

The README then draws a line that matters for anyone evaluating it. It is not a clone of any of them. There is no licensed database, no online requirement, and no monetization, and instead the world is data you author and share, and the depth is a dial you set.

That sentence does a lot of work. The licensed database is the reason the commercial games in this genre feel the way they do, because the player names, attributes and histories are the content, and they are not reproducible. Removing it means the data is yours, which means a community can share a world, and it means the simulation has to earn its depth from the model rather than from the richness of the reference data.

The depth as a dial is the interesting consequence. A management game normally commits to a level of fidelity, and a mod that adds a hundred fictional clubs is expected to work with the same engine. Here the README says the depth is something you set, and points to VISION.md for what that means and where the project is going.

The project also links a roadmap as an issue, and a vision document, which is a reasonable way to run a project where the design is still being argued rather than settled.

The primary language is Rust, the homepage is openfootmanager.com, the default branch is `develop`, and the last push to the repository was on 2026-10-19 with the repository not archived. The copyright line reads Openfoot Manager, copyright 2020-2026, Pedrenrique G. Guimarães.

The match engine is Rust and the interface is React

The architecture section names the four moving parts, and the split tells you where the work is.

Rust is the backend for the Match Simulation Engine and the Game State, described as a blazing-fast backend. Tauri is the lightweight desktop application shell. React with TypeScript and TailwindCSS is the frontend interface. And SQLite is the local persistence for game saves.

The match simulation is the part that decides whether the game is any good, and putting it in Rust rather than in the frontend is the correct call for a game that has to simulate many matches quickly, particularly if a player fast forwards through a season. The state lives in the same side, which means the interface is a view over the engine rather than a client of a server.

The Tauri shell means the interface runs in a web view provided by the operating system rather than in a bundled browser, so the installed footprint stays small and the startup is fast. The cost, which the project is honest about, is on Linux.

The features list tells you what the game does with that engine. There is text-based match simulation with event-driven commentary and score progression, full squad management for roles, depth planning and player development decisions, transfer and contract workflows to buy, sell and negotiate, training and staff systems, dynamic inbox and news generation, and scouting support for discovering talent and evaluating future signings.

That last one, the dynamic inbox, is the feature that separates a management game from a spreadsheet. A simulation that produces events and then a UI that surfaces them as news is a design that most management games converge on, and building it is more work than the match engine.

The dependency list shows a modern React desktop app

The package manifest is worth reading because the choices are recent and the split between the Rust and the JavaScript sides is visible.

On the React side there is `react` and `react-dom` at 19.2.4, `react-router-dom` at 7.18.2 for the routes, `zustand` at 5.0.12 for the state, `recharts` at 3.8.1 for the charts, and `lucide-react` at 1.7.0 for the icons. Tailwind 4.2.2 comes through the `@tailwindcss/vite` plugin rather than as a PostCSS setup, which is the current way to run it with Vite.

Internationalisation is a first class concern rather than an afterthought. There is `i18next` at 26.0.3, `react-i18next` at 17.0.2, `i18next-resources-to-backend` at 1.2.1 for lazy loading the translation files, `i18n-iso-countries` at 7.14.0 for country names, and `country-flag-icons` at 1.6.15 for the flags. The README calls it multi-language support with i18n foundations and community translation growth, and there is a dedicated `audit:i18n` script in the package.json that runs `node scripts/audit-i18n.mjs`, which is a tool for finding missing or unused translation keys. That is the kind of tool a project with community translators needs and that a project without them never writes.

Fonts are self-hosted through the `@fontsource` packages for Barlow Condensed and Inter, so the interface does not depend on a font CDN at runtime.

The Tauri side has the API package at 2.11 with plugins for dialog, log and opener, and the CLI in the dev dependencies. Testing on the JavaScript side is Vitest 4 with jsdom, the testing library for React, and coverage through the v8 provider. The Rust side has its own `cargo test --workspace` in the contribution checklist, so the two halves are tested separately.

A strict preflight gate, and Biome instead of ESLint and Prettier

The tooling choices are notable because they are newer than the default.

The linting and formatting are done with Biome rather than the ESLint and Prettier pair. `biome lint --error-on-warnings` is the lint script, with a `lint:fix` variant, and `biome format` is the format check. The configuration is `biome.json` at the root, and the dev dependency is pinned to `@biomejs/biome` at 2.5.5 exactly rather than with a caret, which tells you the team treats the formatter's output as something they do not want to drift.

There is also `knip`, at 6.35.1, with a `knip.json` configuration and a `knip --no-progress` script. Knip finds unused files, dependencies and exports, and for a project of this size that is a real maintenance tool rather than a novelty, since an Electron-style Tauri app accumulates components that nothing imports.

The `preflight` script is the piece to know about.

npm run format:check && npm run lint && npm run knip && npm run build && npm test

That is the full gate in one command, and it runs in the order you would want: formatting, linting, dead code, build, then tests. A contributor who runs preflight before pushing has done everything CI will ask for.

The Rust side has a `rust-toolchain.toml` at the root, which pins the toolchain so everyone builds with the same compiler, and the repository has an `AGENTS.md` and a `CLAUDE.md` for AI coding assistants, plus a `.claude/` directory, a `.vscode/` directory and a `.git-blame-ignore-revs` file, which is a convention for excluding formatting-only commits from blame.

The build script is `tsc && vite build`, so the type check runs before the bundle rather than being left to the editor, and the development server is plain Vite while `npm run tauri dev` starts the desktop application.

Linux graphics is the platform problem, and the project measures it

The README has a short section on Linux graphics, and it is the most operationally honest part of the documentation.

Linux renders through WebKitGTK, which has known trouble with NVIDIA's proprietary driver. The app detects your GPUs at startup and picks a rendering path automatically, and if you get a blank window or a sluggish interface, a document at `docs/LINUX_GRAPHICS.md` explains the `OFM_GPU_PROFILE` override and records the measurements behind the default.

That is a well handled problem. A GPU detection heuristic with an environment variable escape hatch and a document recording the measurements behind the chosen default is what you would want from a project whose users hit this on their first launch. The alternative, a blank window with no explanation, is the common outcome for Tauri applications on Linux with proprietary drivers.

The build requirements are the standard Tauri ones. You install Rust via `rustup`, Node.js v18 or newer, and the Tauri dependencies for your operating system, following the Tauri prerequisites guide.

git clone https://github.com/openfootmanager/openfootmanager.git
cd openfootmanager
npm install

Then the development desktop app.

npm run tauri dev

The tests are run in two halves, the JavaScript side first and then the Rust workspace.

npm test
cd src-tauri
cargo test --workspace

One more detail in the repository layout. The `package-lock.json` is present alongside `package.json`, and the README's install instructions say `npm install` rather than pnpm, so npm is the supported path for contributors even though the nightly release pipeline produces its own artefacts.

Editorial conclusion

Adopt Openfoot Manager if you want a football management game you can inspect, extend with your own data, and run offline, and you are prepared to build it from source rather than download a binary. Do not adopt it expecting a Football Manager equivalent, because the project states plainly that it is not a clone and that there is no licensed database. Verify first that the simulation depth and the data you have will produce the experience you want, since the README makes the depth a deliberate setting rather than an implementation detail, and that the version you run is one of the nightly builds, because the project ships nightlies and the 0.3.0 release train is still in early active development.

Frequently asked questions

Official sources

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