Governance · TacidOS

Tacid is an open-source project built in public by a community, with one maintainer who decides. This document says exactly what that means.

1. The maintainer

The project has a single maintainer, its founder, who holds final decision on scope, architecture, merges, releases, the trademark and this document. The maintainer is the owner of the TacidOS GitHub organization; contact details are published at tacidos.com.

Final decision is not sole labour. The maintainer appoints area reviewers with merge rights over parts of the tree (see CODEOWNERS once it exists) and may appoint deputies. The maintainer may also revoke those rights. If the maintainer is unreachable for more than 90 days, the area reviewers jointly hold the tiller until they return.

2. How decisions are made

Decisions are written before they are made.

Architecture Decision Records live in docs/decisions/. A decision exists when its ADR is merged. A decision changes only when a new ADR supersedes it and says why. ADRs record the options considered and the reasons they lost, so scrutiny stays visible.
RFCs are required for large changes: a new subsystem, a change to the protocol or to the tacid.* option surface, a change to the security model or the hard invariants, a new supported platform, a new dependency in the signed core. An RFC is a pull request adding docs/rfcs/NNNN-title.md; discussion happens on the pull request; the maintainer accepts or rejects with a written rationale. Accepted RFCs produce one or more ADRs.
Everything else is an issue and a pull request.

The order of authority when documents disagree: hard invariants (SECURITY.md) > ADRs > PLAN.md > everything else. PLAN.md is a living document and the phase tables are expected to change; the invariants are not.

3. Contributions

Contributions are accepted under the project licenses (Apache-2.0 for code, CC-BY-4.0 for documentation) with a Developer Certificate of Origin sign-off on every commit (git commit -s). There is no contributor license agreement.
The signed core (tacid-stem, tacid-keeper, tacid-protocol, the health gate) requires two approvals, one of them the maintainer’s, and a security-focused review.
Agent-drafted changes. A Tacid machine may draft a change to its own source and place it in its owner’s proposals queue with CI and evaluation results attached. Agents never open pull requests against this repository. A human reviews the proposal, signs it off, and opens the pull request in their own name; that human is responsible for it.
AI-contribution disclosure. Any pull request that is substantially machine-generated says so in its description. Undisclosed generated code is grounds for rejection.
Contributors keep copyright in their work.

4. Releases and channels

edge advances automatically when continuous integration is green for every reference configuration on every supported architecture and the binary cache is fully populated.
stable is promoted by the maintainer after the hardware matrix passes and the release quality gates in PLAN.md are met.
Release and channel signing keys, their custody and rotation are described in SECURITY.md.

5. Trademark

“Tacid”, “TacidOS” and the project logo are trademarks of the maintainer. Using the names to refer to the project, to unmodified builds, and in truthful descriptions is always fine. A modified distribution must use a different name. A formal trademark policy will be published before the first stable release; until then, ask.

6. Communication

GitHub Issues and Discussions for work; one Matrix room for conversation; no Discord. Security reports follow SECURITY.md and are never filed as public issues.

7. Funding

Tacid is not a business and has no plans to become one. Costs exist (binary cache and CDN, continuous-integration hardware, domains, test devices) and are covered through GitHub Sponsors or Open Collective. Money pays bills, not salaries, and the ledger is public.

8. Conduct

CODE_OF_CONDUCT.md applies everywhere the project meets. The maintainer enforces it and may delegate.