Project Governance

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

1. Demonstrate sustained, quality contributions over 3+ months
2. Show understanding of the project's architecture and conventions
3. Be nominated by an existing maintainer or the Project Lead
4. 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#

• Bug fixes, documentation improvements, minor refactors: Maintainer approval + merge
• New features within existing scope: PR review by 1+ maintainer, 72-hour comment period for significant changes

Significant Decisions#

These require broader discussion and explicit approval:

• Specification changes (GraphQL schema modifications affecting generated types)
• New platform support (adding a new language plugin or platform implementation)
• Breaking changes to public APIs
• Governance changes
• License changes

Process for significant decisions:

1. Open a GitHub Issue or Discussion with the proposal
2. Allow minimum 7-day comment period
3. Project Lead (or TSC) makes final decision, documenting rationale
4. For specification changes: affected platform maintainers must be consulted

Specification Change Process#

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

1. Proposal: Open an issue describing the change, motivation, and impact on all platforms
2. Impact Assessment: Document effects on TypeScript, Swift, Kotlin, Dart, C#, and GDScript generated types
3. Review Period: Minimum 14-day review period for platform maintainers
4. Approval: Requires Project Lead approval + no unresolved objections from platform maintainers
5. 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 + 30-day notice to community
• Specification releases: Follow the Specification Change Process above

Release Artifacts

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#

• All contributors must agree to the project's contribution terms
• 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#

Hosted Services#

The IAPKit instance at kit.openiap.dev is a community service operated under project governance: its source is open (packages/kit, MIT, self-hostable as a single binary), its infrastructure costs are funded through the project's OpenCollective with transparent expenses, and its fair-use and capacity policies are documented in the package README. It is operated by project maintainers on the project's behalf — not as a separate commercial offering — and would transfer with the other project assets upon foundation hosting.

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 governance document may be amended through the Significant Decisions process described above. Changes require a minimum 14-day review period and explicit approval from the Project Lead (or TSC majority, when formed).

This governance model is designed to evolve. As OpenIAP grows, we are committed to transitioning toward broader community governance while maintaining the project's technical integrity and mission.