This project needsmore hands than it has.
Sextant manages real fleets and is written by very few people. That is the honest state of it, and it is why this page exists rather than a pricing table.
Start with two commands.
A console, a database and sixty simulated devices, on your own machine. Nothing leaves it, and Ctrl-c deletes everything it made.
Then open http://127.0.0.1:8080. Enroll a device, change a setting, and watch the change become a git commit. It needs a PostgreSQL on your PATH; nix develop provides one.
git clone https://codeberg.org/DAWO/DAWO-Sextant.git
cd DAWO-Sextant
just demoWhat would help most, right now.
None of this is deep in the domain model. The work with the shortest path from nothing to merged is at the edges.
Hardware profiles
Every laptop model needs a disk layout and imaging notes. Own a machine we do not? That is a self-contained contribution with an obvious test: image it.
Go, for the console and the API
The console is a client of the same API you get. Issues are labelled, and the ones nobody has claimed are the ones to take.
Nix and NixOS modules
The fleet is described in Nix. Knowing that language is worth more here than knowing this codebase.
Translations
The console ships English and Dutch. Adding a language is one map in the catalog.
Documentation
Written by the people who already knew the answer, which is the worst possible authors. Anything you had to work out yourself is worth writing down.
Run it and report what broke
Honestly the most valuable thing anyone can do. The rough edges we know about are named; the ones we do not are the point.
How a change gets in.
Written down before you spend an evening on something that gets turned away for a reason nobody told you.
An issue first
It states the problem and how you would know it is fixed, not the solution. That conversation is cheaper than a rewritten pull request.
A commit that explains why
Conventional Commits for the subject, enforced by a hook and by CI. The body is the part that matters and is where the reasoning goes.
An ADR for anything that shapes the product
We would rather argue about a design in writing than discover the disagreement in review. The existing records are the fastest way to learn how this thing thinks.
DCO, not a copyright assignment
Sign your commits and keep your copyright. Nobody signs their work over to anybody here.
Say when AI helped
Name the model in a commit trailer. Use it where it addresses a real need, and stay accountable for what it wrote: the code has to be understandable by a human who has to fix it later.
English, except in the issue tracker
Documentation, commits and discussion are English. Dutch is fine inside an issue when that is what gets the coordination done.
Where the work happens.
Two forges, on purpose. A pull request in the wrong one is never turned away for being in the wrong place.
codeberg.org/DAWO/DAWO-Sextant
The place to take part today. Issues, pull requests, milestones per release and release notes. A European non-profit forge rather than a company’s platform, which is the same reasoning that put the canonical copy where it is.
code.overheid.nl/MinBZK/DAWO-Sextant
Where the Dutch government’s code belongs and where the history is authoritative. Releases are cut from here. You do not need an account to contribute: a maintainer carries your patch across with your authorship intact.
Where to find the people.
The DAWO community is where the conversation happens that is too small for an issue. Security reports go neither there nor to the tracker; SECURITY.md says where.
Worth reading before you start.
All four live in the repository and are kept current, not written once.
One document for every laptop.site.audit.
Take it, run it, help build it.
The software is yours under the EUPL 1.2 and needs nobody’s permission. What the project needs is people: a laptop model we have never imaged, a language nobody has translated, a bug found by running it for real.