DOCTRINE

Philosophy

The seven principles every system is judged against. This is the criteria the registry filters by and the thing that decides what gets built.

Principles are the criteria systems are judged against — not lifecycle states, not features. First the doctrine, then the seven principles it reduces to.

Applications and utilities made for the people, by the people. The software.

XT Projects exist because too much software serves its maker instead of its user — telemetry where there should be tools, subscriptions where there should be ownership. The Doctrine of XT rejects that trade: quality over quantity, tested and hardened before it ships, silent and efficient when it runs.

One rule covers the rest: a concept never poses as a release. Status is content, printed on every dossier — what you see is the stage it is actually at.

01

OWNERSHIP

Ship only work you can defend line by line.

XTR ships fewer features, but each one is tested, profiled, and hardened. Releases are infrequent because the internal bar is unreasonable on purpose: architecture-specific builds, audited allocations, real-hardware testing.

02

TRANSPARENCY

No hidden behavior in software that claims to serve the user.

Public XT Projects editions are auditable: no hidden telemetry, no silent callbacks, no license phone-home. If a binary does something, a user can find out what and why. What cannot be shown is not shipped as open source.

03

EFFICIENCY

Every byte and cycle must justify itself.

Zero-copy buffers, single-frame IPC dispatch, sub-5ms audio paths, zero-regression benchmarking. Performance is measured in microseconds with flame graphs and latency distributions, not marketing claims.

04

PRIVACY

Collect nothing; the user owes the tool no data.

Telemetry endpoints are disabled at compile time, not toggled in settings. Extensions install via pacman, not a proprietary store. Privacy is the default build configuration, not a mode.

05

DURABILITY

Build for years of use, not launch-week demos.

Tools must survive driver updates, compositor versions, and kernel bumps. XT software prefers stable native APIs (ALSA, PipeWire, Wayland protocols, Unix IPC) over fashionable frameworks that rot.

06

EXPERIMENTATION

Prototype openly, label honestly.

Prototypes are allowed to be unfinished in public as long as they are labeled unfinished. A polished page must never make paused or experimental work look shipped. Status is content, not styling.

07

CRAFT

Quality before quantity, strength before numbers.

Documentation, error messages, and configuration syntax are part of the product. A tool that works but cannot be explained is half-built. Clarity is an engineering requirement.