Extension & Binding Governance

The OPVS organization uses a unified governance framework for both Extensions and Custom Protocol Bindings. This document defines the formal process for proposing, developing, promoting, and maintaining these artifacts within the OPVS organization.

Anyone may develop and publish extensions or custom protocol bindings independently. The tiers and lifecycle described here apply specifically to those hosted under the opvsproject GitHub organization.

Both extensions and custom protocol bindings use a two-tier system within the opvsproject organization. Repository naming and URI prefixes differ by type:

Official artifacts are developed and maintained under the opvsproject GitHub organization, officially recommended by the TSC. Each repository has designated maintainers identified in MAINTAINERS.md.

• Requirements:
• Specifications MUST use the same language as the core specification (RFC 2119)
• MUST be licensed under Apache 2.0
• MUST have at least one reference implementation
• SHOULD have associated documentation on the OPVS website

Experimental artifacts provide an incubation pathway for community contributors to prototype and collaborate on ideas before graduation to official status.

• Creation Requirements:
• An experimental repository can ONLY be created with sponsorship from an OPVS Maintainer
• The sponsoring Maintainer is responsible for initial oversight of the experimental artifact
• Experimental repositories MUST clearly indicate their experimental/non-official status in the README
• Any published packages MUST use naming that clearly indicates experimental status
• The TSC retains oversight, including the ability to archive or remove experimental repositories

Extensions and custom protocol bindings progress through the following phases.

Any community member may propose an extension or custom protocol binding:

• 1. Open an issue: Create an issue in the main opvsproject/OPVS repository describing:
• An abstract describing the extension's purpose or the binding's transport and use case
• Motivation explaining why this cannot be achieved with the core protocol or existing standard bindings
• An initial technical approach or specification draft
• 2. Community Discussion: The proposal is open for community feedback and refinement

For a proposal to proceed to experimental status:

• 1. Secure a Sponsor: An OPVS Maintainer must agree to sponsor the proposal
• 2. Repository Creation: The sponsoring Maintainer creates the experimental-ext-* or experimental-cpb-* repository under opvsproject
• 3. Oversight: The sponsoring Maintainer provides initial oversight and ensures alignment with OPVS design principles

While in experimental status:

• Contributors iterate on the specification and reference implementations
• The experimental artifact MAY be used by early adopters with the understanding that breaking changes are expected
• Community feedback is gathered and incorporated
• The experimental repository MUST clearly indicate its non-official status

To graduate an experimental extension or binding to official status:

• 1. Maturity Requirements:
• At least one production-quality reference implementation
• Documentation meeting OPVS standards
• Evidence of community adoption or interest
• Clear maintainer commitment for ongoing maintenance
• 2. Graduation Proposal: Open an issue in opvsproject/OPVS with:
• Reference to the experimental repository and its implementations
• Summary of community feedback and adoption
• Proposed maintainers for the official artifact
• 3. TSC Vote:
• The proposal is added to the TSC meeting agenda
• Quorum Requirement: At least 50% of TSC voting members must be present
• Approval: Requires majority vote of those in attendance (per OPVS governance)
• The TSC may request revisions before a final vote
• 4. Acceptance:
• (Extensions) The repository is renamed from experimental-ext-* to ext-*; documentation is added to the OPVS website's extensions page
• (Custom Protocol Bindings) The repository is renamed from experimental-cpb-* to cpb-*; documentation is added to the OPVS website's custom protocol bindings page

Once official, extensions and bindings may be iterated on:

• Repository maintainers are responsible for day-to-day governance
• Changes SHOULD be coordinated via the relevant working group if one exists
• Breaking changes require a new identifier
• Breaking changes require TSC review
• Maintainers SHOULD coordinate with SDK maintainers for implementation updates

Some extensions may eventually transition to core protocol features, and some custom protocol bindings may transition to core bindings. This is governed through the existing OPVS specification enhancement process:

• A proposal is submitted following the standard specification change process
• The proposal references the official extension or binding and its adoption
• TSC vote with standard quorum and majority requirements applies
• Not all extensions or bindings are suitable for core inclusion; many will remain as extensions or custom bindings indefinitely

SDK support requirements differ between extensions and official custom protocol bindings, reflecting their different roles in the protocol ecosystem.

Extensions: OPVS SDKs MAY implement extensions. Where implemented:

• Extensions MUST be disabled by default and require explicit opt-in
• SDK documentation SHOULD list supported extensions
• SDK maintainers have full autonomy over extension support decisions
• Extension support is not required for protocol conformance

Official Custom Protocol Bindings: OPVS SDKs SHOULD implement official custom protocol bindings. Where implemented:

• Custom protocol bindings MUST be disabled by default and require explicit opt-in
• SDK documentation SHOULD list supported custom protocol bindings
• SDK maintainers have full autonomy over binding support decisions
• Custom protocol binding support is not required for protocol conformance

Official extensions and custom protocol bindings MUST be available under the Apache 2.0 license, consistent with the core OPVS project.

By submitting a contribution to an official OPVS extension or custom protocol binding repository, contributors represent that:

• 1. They have the legal authority to grant the rights
• 2. The contribution is original work or they have sufficient rights to submit it
• 3. They grant to the Linux Foundation and recipients a perpetual, worldwide, non-exclusive, royalty-free license to use, reproduce, modify, and distribute the contribution

Extension and custom protocol binding developers acknowledge that:

• They may compete with other participants
• They have no obligation to implement any extension or binding
• They are free to develop competing extensions or bindings
• Status as an official extension or binding does not create an exclusive relationship