Keel — open governance

Keel is an Apache 2.0 open-source React Native platform for the China market. This doc covers the governance model, contribution flow, and decision weights.

License

Apache License 2.0. Why Apache 2.0 over MIT:

Patent grant clause — irrevocable patent license from contributors; enterprise-friendly (safe for commercial use, no ambush patent litigation)
Explicit trademark clause — the “Keel” name / logo is outside the license scope (§ 6); brand rights preserved
Industry convention: Kubernetes / Apache Cassandra / TiDB / Apache Doris and other enterprise-service projects all use Apache 2.0

No CLA (Contributor License Agreement) required — Apache 2.0 § 5 default grant is enough, keeping the contribution barrier low.

Repository

Keel source currently lives at keel/ inside the appunvs/appunvs monorepo, fully open source, external PRs welcome. Other subdirectories are independent Appunvs products and decoupled from Keel — Keel-only contributors only need to focus on the keel/ path.

Why we don’t split into a standalone appunvs/keel repo yet:

Cross-repo PR coordination is expensive
Once the monorepo is public, Keel-only contributors can focus just on the keel/ subtree
We’ll reconsider once user numbers grow (optional, later)

Decision mechanism

Tier 1: core team decision

No RFC; direct PR merge:

Compile errors / bug fixes
Doc typos / link fixes
Internal refactors (no public-API change)
CI / engineering improvements

Tier 2: RFC + open discussion (≥ 7 days)

Goes through a proposal in the RFC channel on GitHub Discussions + ≥ 7-day discussion window:

Public API changes (Keel SDK / CLI / Build / Update / Submit surface)
Adding new Tier-1 modules
License / governance changes
Major roadmap shifts

Template: .github/RFC_TEMPLATE.md.

Tier 3: core team reserved

Regardless of community discussion, the following are decided by the core team to avoid community hijack:

Commercial pricing (pricing)
Trademark / brand identity
Legal compliance
Product boundary with Appunvs / Mortar

Roadmap transparency

roadmap is the public planning doc. Changes go through Tier 2 RFCs.

Engineering tracking: GitHub Project, sorted by roadmap phase.

Contribution flow

Filing issues / discussions

Bug reports: GitHub Issues, add keel label
Feature requests / discussion: GitHub Discussions, keel channel
RFC proposals: Discussions keel-rfc channel (use the RFC template)
Security issues: security@keel.appunvs.com (NOT in public issues)

Submitting PRs

Fork + work on a feature branch
PR title uses conventional commits format (feat(keel): ... / fix(cli): ...)
PR description explains motivation + test approach
CI must be fully green (lint + build + test)
At least 1 maintainer approval to merge; public-API-changing PRs need 2

Test requirements

New native modules: iOS + Android both need minimal tests
Changing Native SDK public API: must bump keel/version.json’s sdk_version number (ABI bump)
CLI changes: unit tests + one e2e (create project → build → verify artifact)

Maintainer list

Initial internal-beta core team (alphabetical):

Path to maintainer:

Sustained high-quality contributions ≥ 3 months
≥ 5 accepted PRs
≥ 50% of existing maintainers agree

Boundary with Appunvs / Mortar

Domain	Whose decision
Keel SDK / CLI / Build / Update / Submit	Keel community (per the mechanism above)
How Keel integrates with Mortar	Keel community (Mortar is an optional Keel plugin)
Mortar internals	Mortar team (Keel doesn’t interfere)
How Appunvs uses Keel internally	Appunvs team (Keel doesn’t interfere, but Keel public-API changes notify Appunvs)

Cross-product PRs (changing keel + mortar or keel + appunvs together) go through joint maintainer review.

Business model + open-source relationship

Keel is fully open source: SDK / CLI / Build server / Update server / Push server are all Apache 2.0 code.

Commercial services (pricing) sell hosting + SLA + premium ops:

Run your own Build server / Update server? ✅ Yes, free per Apache 2.0.
Use Keel’s managed Build? Subscribe to Keel Pro / Team.
Self-hosting reference: deployment.

Same “open core + managed cloud” model as GitLab / Sentry / Supabase. The community edition is not feature-limited — the commercial edition mainly saves ops.

Code of conduct

Contributor Covenant 2.1. Violations go to conduct@keel.appunvs.com (independent inbox, not the core team issue channel).

RFC accept / reject template (for the core team to use)

## Decision

[Accepted / Rejected / Deferred to V_]

## Rationale

(why this decision)

## Action items

- [ ] xxx
- [ ] xxx

License + trademark policy

Code + docs: Apache 2.0
“Keel” name + logo: outside Apache 2.0 scope; allowed only when describing this project, banned for naming forks / derivative works / commercial services (per Apache project convention)
Trademark requests: trademark@keel.appunvs.com (long-term, needed later)