Use this page with AI

Copy this into your coding assistant and add your request.

Read https://openiap.dev/docs/foundation/governance and https://openiap.dev/llms.txt. Follow the reading instructions, detailed reference, and linked guides relevant to my task before making changes.
Inspect my existing project and reuse its framework and conventions. Ask me for missing product decisions. Implement the requested behavior and run the applicable checks.
Show the working result, the commands and actual test results, and any remaining limitations. Keep your explanation brief.

My request: [describe what customers should be able to do]

Project Governance

How decisions are made in OpenIAP, and who makes them.

Mission#

To establish and maintain an open, vendor-neutral standard for in-app purchase interoperability, verification, and security — enabling consistent behavior across all platforms, frameworks, and store providers.

Governance Model#

OpenIAP currently operates under a founder-led governance model with a clear path toward a Technical Steering Committee (TSC) structure as the community grows.

Current Phase: Founder-Led#

Project Lead: Hyo (hyo.dev) — responsible for overall project direction, releases, and community stewardship
Decision-making: Benevolent dictator model with open discussion encouraged on all proposals
Transparency: All significant decisions are documented in GitHub issues/PRs with rationale

Target Phase: TSC Governance#

As the project grows to include multiple organizational contributors, governance will transition to:

Technical Steering Committee (TSC): 3-7 members representing diverse organizations and perspectives
TSC Chair: Elected by TSC members, rotating annually
Advisory Board: Representatives from sponsoring organizations (non-binding input on direction)

Roles and Responsibilities#

Project Lead (Current)#

Sets project vision and roadmap priorities
Has final authority on technical decisions (until TSC is formed)
Manages releases and deployment processes
Represents the project in external communications

Maintainers#

Maintainers have write access to one or more packages in the monorepo.

Becoming a Maintainer

Demonstrate sustained, quality contributions over 3+ months
Show understanding of the project's architecture and conventions
Be nominated by an existing maintainer or the Project Lead
Receive approval from the Project Lead (or TSC, when formed)

Maintainer Responsibilities

Review and merge pull requests in their area
Triage issues and provide guidance to contributors
Follow the project's coding standards and conventions
Participate in release planning

Removing a Maintainer

Voluntary resignation at any time
Inactivity for 6+ months without communication
Violation of the Code of Conduct
Decision by Project Lead (or TSC majority vote, when formed)

Contributors#

Anyone who contributes code, documentation, bug reports, or other improvements. No formal approval needed — just submit a pull request or open an issue.

Decision-Making Process#

Routine Decisions#

The project lead merges a change once CI, the repository audits and automated review pass.

Significant Decisions#

These require broader discussion and explicit approval:

Specification changes to either protocol: the Client Protocol GraphQL schema, or the Commerce Protocol, which follows its own change rules
New platform support (adding a new language plugin or platform implementation)
Breaking changes to public APIs
Governance changes
License changes

Today the project lead decides and records the rationale in the pull request. Once the TSC forms, a significant decision starts as a GitHub issue or discussion with at least a 7-day comment period, and affected platform maintainers are consulted on specification changes.

Specification Change Process#

Changes to the core GraphQL schema (the source of truth for all platforms) follow a stricter process:

Proposal: Open an issue describing the change, motivation, and impact on all platforms
Impact Assessment: Document effects on TypeScript, Swift, Kotlin, Dart, C#, and GDScript generated types
Review Period: none required today; 14 days for platform maintainers once the TSC forms
Approval: Project Lead approval, and no unresolved objections from platform maintainers once the TSC forms
Implementation: Schema change + regeneration of all platform types in a single PR

Commerce Protocol participation#

Providers, app developers, and event consumers can propose changes or contribute interoperability reports. The protocol contribution procedure defines the required use case, executable evidence, compatibility assessment, and public decision record. IAPKit receives no exemption from the shared contract or its checks.

Decisions remain with the current project lead under the review process above. Reports identify their authors and actual reviewers; a project-authored fixture does not count as independent company validation. The runnable composition example provides a starting point for another implementer to reproduce and challenge the expected results.

Release Authority#

Patch releases (bug fixes): Any maintainer for their package
Minor releases (new features): Project Lead approval required
Major releases (breaking changes): Project Lead approval, announced on Announcements before the release
Specification releases: Follow the Specification Change Process above

Versions are set by CI, never by hand. Every package and where it is published is listed on Versions.

Intellectual Property#

License#

OpenIAP is licensed under the MIT License, with one exception: kmp-iap is licensed under Apache-2.0. All contributions must be compatible with the license of the package they touch.

Contributions#

DCO (Developer Certificate of Origin): adoption is planned as part of foundation onboarding. Until CI enforcement is enabled, contributions are accepted under the project license through pull-request review; a Signed-off-by line is welcome but not yet required
Future consideration: Migration to a CLA (Contributor License Agreement) may occur if/when the project joins a foundation

Trademarks and Assets#

Asset	Current Owner	Direction
"OpenIAP" name and logo	hyo.dev	Upon foundation hosting, trademarks and critical assets would transfer to the foundation for neutral ownership
Domain (openiap.dev)	hyo.dev
GitHub organization	hyodotdev

Hosted Services#

Hyo Dev operates the IAPKit instance at kit.openiap.dev under its terms of service. It runs as a shared pool, free within its fair-use limits, and its running costs are meant to be covered by sponsorship; the plan is to share those costs openly as usage grows. An organization whose load strains the shared servers may be removed from the pool; to keep using it, sponsorship may be required, or it can self-host the server (packages/kit, MIT).

Code of Conduct#

All participants in the OpenIAP project are expected to follow the project's Code of Conduct. Violations should be reported to conduct@hyo.dev (or the designated conduct committee, when formed).

Amendments#

This page changes through a reviewed pull request the Project Lead approves. Once the TSC forms, an amendment gets a 14-day review period and needs a TSC majority.