Project governance and sustainability¶

What enterprise evaluators can determine from published documentation and repository policy. This is not a commercial vendor statement.

Project model¶

Fortune 500 teams should plan internal OSS adoption with their own escalation path and pinned versions.

Release cadence (observed)¶

Recent documented releases (see changelog):

• 0.27.x — Current tagged release (Strixonomy rename; legacy OntoCore/OntoCode compatibility through ≥1.0).

Pre-1.0 releases may ship frequently. No committed future cadence is documented.

Maintainers follow releasing.md: version bump, CHANGELOG, SHIPPED matrix, ./scripts/build-docs.sh, ./scripts/check-doc-versions.sh, GitHub Release artifacts with SHA256SUMS and NOTICES.

Version support policy¶

Pin versions in CI and desktop rollouts; do not assume automatic long-term backports. Canonical table: security policy.

Security response¶

• Report via GitHub Security Advisories — not public issues
• Acknowledgment target: within a few business days (SECURITY.md)
• No published SLA for patch delivery
• Historical advisories: check the repository Security tab (not summarized in docs)

Supply chain: cargo audit in CI; release integrity via SHA256 — release integrity. Code signing: not shipped.

Quality gates (documented)¶

Roadmap governance¶

• Target specs live under Contributing → Design (may describe future behavior)
• Shipped behavior is canonical in SHIPPED.md
• v1.0 is a product goal, not a committed date — Release timeline (non-commitment)

Contributing¶

Community contributions welcome — contributing.md. No documented contributor license agreement beyond standard GitHub inbound licensing.

Enterprise implications¶

Related¶

• Enterprise evaluation
• Production readiness
• Release timeline
• Security policy