Governance

OMIR is developed in the open by a vendor-neutral Working Group. Veld convenes it and seeds the reference implementation; Veld does not own the standard. Neutrality is not a nicety here — it is the product. A standard wins on neutrality, not features.

This page summarizes the canonical GOVERNANCE.md. Where this summary and that document differ, GOVERNANCE.md governs.

The Working Group

OMIR is stewarded by the OMIR Working Group in a neutral GitHub organization (OMIR-Working-Group). Membership is open; participation follows the Code of Conduct (Contributor Covenant). A Technical Steering Committee (TSC) arbitrates technical direction and ratifies ballots.

How changes happen: RFC → ballot

  1. Propose. Open an RFC describing the change — a new resource, a field, a profile, a vocabulary — and the problem it solves. See CONTRIBUTING.md.
  2. Discuss. The Working Group reviews in the open. The single most persuasive input is an independent implementer who needs the change.
  3. Ballot. The TSC calls a ballot. Accepted changes land in a numbered release and enter the maturity model at a low OMM level.
  4. Earn maturity. A resource or field rises through OMM only as real, independent implementations adopt it. Nothing is graded mature on assertion.

Versioning & deprecation

Licensing

Licensing is deliberately decoupled from any implementation — including Veld's:

A standard under a restrictive license is dead on arrival. The split keeps the spec free to adopt and the tooling free to embed, with neither encumbered by any contributor's commercial terms.

Read the full process, the complete OMM 0–5 definitions, the TSC charter, and the license rationale in GOVERNANCE.md.