Open Core and Governance

Use this page when you want the project boundary in plain language before you invest in the CLI, docs, or ecosystem.

This is the page that explains what is open, how roadmap and release direction work, and how to participate without guessing.

• what is public in the open core
• how governance and release direction are handled
• what contribution paths are welcome today
• where enterprise work fits without replacing the public contract

• the CLI
• the repo and workspace contracts
• the JSON output and public docs
• examples, specs, and the contract-first readiness model

• ota is maintainer-led open infrastructure
• the core is open source under Apache 2.0, but roadmap and release direction are stewarded by Ota
• schema, JSON, and command-surface changes are treated as product-level decisions
• trust-sensitive behavior such as doctor, detect, init, up, and agent guidance stays under strict maintainer review
• the public core should stay useful on its own, without requiring a hosted control plane

Participation is welcome, but not every contribution path is open right now.

• welcome: bug reports with concrete reproduction steps
• welcome: feature requests tied to real repo or operator pain
• welcome: docs feedback, clarity issues, and real-repo examples
• not currently accepted: external code pull requests
• not currently accepted: drive-by schema changes without maintainer review

• contract and JSON stability matter
• diagnosis must stay honest
• onboarding flows must stay deterministic
• policy and enterprise boundaries must stay explicit
• maintainer-led governance is the current way ota keeps those trust boundaries coherent while the public contract hardens

• enterprise work is planned as a layer around the open core, not as a different contract truth
• the open core remains the public CLI, repo and workspace schemas, JSON output, and documentation
• enterprise value should come from hosted policy, audit, fleet coordination, onboarding, private adapters, and support
• the public contract should stay usable on its own and should not become a thin wrapper around a paid control plane

• read the docs and start with ota doctor if you want to evaluate the product
• open an issue when you hit a bug, docs gap, or real-repo edge case
• use the public JSON output and examples when you are building automation or editor support