Skip to content
OpenBody OpenBody™

Governance & contributing

OpenBody is community-extensible and stewarded by Thabit Labs. The standard is vendor-neutral: no single vendor — including the steward — should permanently control the format, and the steward is not the brand on the wire. This page summarizes GOVERNANCE.md and CONTRIBUTING.md; those documents (and SPEC §9) are authoritative.

Phased Incubation (v0.2 → v1.0)

During incubation:

  • The Project Lead (Yasir Ahmad) retains final merge authority over the GitHub repository (a BDFL model) to keep the standard coherent while it stabilizes.
  • Specification changes are reviewed and approved by a public Technical Steering Committee (TSC) via asynchronous GitHub RFCs.
  • All contributions require Developer Certificate of Origin (DCO) sign-off.

Transition to a foundation

To secure ecosystem trust, stewardship and ownership of the “OpenBody” trademark are intended to transfer to an independent, neutral foundation (e.g. the Joint Development Foundation, the Linux Foundation, or a dedicated non-profit) once a formal Working Group with corporate sponsors is established, or upon demonstrated adoption by major platforms. If transfer is delayed, the project operates under a permanent open-governance charter on GitHub.

Versioning & change management

  • Released normative text is immutable. A published version’s SPEC.md is never edited in place. Every normative change follows: record the decision (with rationale) → ratify → edit → bump the version with a CHANGELOG.md entry. (Editorial fixes that change no normative meaning may land as a patch.)
  • The standard follows semantic versioning: additive minor / breaking major / editorial patch; deprecate-not-remove within a major line.
  • Vocabulary growth for open registry-backed fields happens via the independently versioned registries, not the spec.
  • New values of a genuinely closed enum are rare and assessed case-by-case for graceful degradation, with lossless passthrough as the backstop.
  • Widely-adopted namespaced extensions may be promoted into the canon as backward-compatible additions — a path from private experimentation to shared standard without forks.

How to contribute

  • Specification changes (anything in SPEC.md §§3–10) are proposed as a GitHub RFC and reviewed by the TSC; the Project Lead retains final merge authority during incubation.
  • Vocabulary growth (new open registry-backed tokens — disciplines, schemes, Load.basis, …) is usually a registry change, opened against the relevant registry repo, not the spec.
  • Editorial fixes (typos, no-schema-effect clarifications) can be a direct PR.
  • DCO: every commit must carry a Signed-off-by: trailer (git commit -s) — this certifies you have the right to submit the contribution and guards against copyright contamination, which matters for an open standard and its CC0 registry data.
  • Extend, don’t modify the core (§8.1): new capability goes under a namespace; unknown extensions must round-trip losslessly.
  • Changes that affect the model must keep the test vectors green (or update them with justification); new core structures arrive with a worked example and a vector.

Trademark

The “OpenBody” trademark remains the property of the steward (and later the foundation). A free, royalty-free Trademark License Policy grants any implementer the right to use an “OpenBody Compatible” mark provided their implementation validates against the official conformance test suite.

Code of Conduct

The project adopts the Contributor Covenant v2.1. Report unacceptable behavior to the maintainers at conduct@openbody.dev; reports are reviewed and handled confidentially.