How we engineer

Tignex is not tied to a single product, language or technology. What holds it together is a short list of commitments — the ones below — that every project under the organization is expected to keep, whether it is a CLI tool, a specification or a piece of server infrastructure.

Control stays with you

Every project is open source, and open in the way that matters: you can read it, fork it, and run it on your own machines. Nothing we publish is a client for a service we operate, because that is the shortest path to a dependency you cannot remove.

• Self-hosting is the first-class path, not a paid tier.
• Data stays in systems you already control.
• Leaving is a supported operation — export before lock-in.

git clone https://github.com/CommitBrief/commitbrief
cd commitbrief
go test ./...

Interoperable by design

We prefer open formats and documented protocols to convenient private ones, even when the private one would ship sooner. A format only one implementation understands is a promise that expires the day that implementation does.

If another team cannot write a second implementation from the specification alone, the specification is not finished.

This is also why projects here keep their own names and homes. A standard that can only be adopted by adopting our whole catalogue is not a standard — it is a brand with extra steps.

Production-oriented

The target is software that survives contact with systems that are already running: real data, real load, real migrations, and an operator who was not in the room when it was designed. Features that only hold together in a demo do not ship.

Transparent by default

Decisions, trade-offs and limits are written down where they can be argued with — in the repository, in the specification, and in the engineering notes. That includes the unflattering parts: what a project does badly, what it has not solved yet, and what we decided not to do.

What this rules out

Taken seriously, these commitments remove options. No telemetry that we would not want pointed at us. No open-core feature walls in the middle of a protocol. No release that depends on infrastructure only we can run. The list is short on purpose: it has to be possible to hold every project to it.