Machine-translated draft — terminology + flow still being reviewed.

Mortar — open governance

Mortar is an Apache 2.0 open-source BaaS for the China market. This doc covers the governance model, contribution flow, and decision weights.

Mortar and Keel are two independent products in the same monorepo, with no interdependencies — Mortar can be sold standalone to any BaaS user; Keel can be sold standalone to any RN developer. The two products have separate governance; this doc is Mortar’s, and /keel/docs/governance.md is Keel’s.

License

Apache License 2.0. Why Apache 2.0 over MIT (same as Keel):

  • Patent grant clause — irrevocable patent license from contributors; enterprise-friendly
  • Explicit trademark clause — the “Mortar” name / logo is outside the license scope (§ 6)
  • Industry convention: Kubernetes / TiDB / Apache Cassandra and other enterprise-service projects all use Apache 2.0

No CLA. Keep the contribution barrier low.

Repository

Mortar lives in the mortar/ subdirectory of the appunvs/appunvs monorepo:

mortar/
├── internal/{primitive,feature}/   ← Go server implementation
├── sdk/{typescript,dart,swift,kotlin}/  ← 4-language client SDKs
├── docs/                            ← this doc + architecture / pricing / etc.
└── LICENSE                          ← Apache 2.0

Why we don’t split into a separate repo:

  • Sharing the Keel monorepo makes cross-product PRs easy (even though the two products have no hard dependency)
  • Once the monorepo is public, Mortar-only contributors can focus just on the mortar/ subtree
  • We’ll reconsider splitting once user numbers grow

Decision mechanism

Tier 1: core team decision

No RFC; direct PR merge:

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

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

Discussed in the mortar-rfc channel on GitHub Discussions:

  • Public wire schema changes (OpenAPI / proto)
  • New primitives or features
  • Breaking changes in the 4 SDKs
  • License / governance changes
  • Major roadmap shifts

Tier 3: core team reserved

  • Mortar Cloud commercial pricing (pricing)
  • Trademark / brand identity
  • Legal compliance (data export, ICP filing)
  • Cross-product boundaries (how we work with Keel / appunvs)

Roadmap transparency

roadmap.md is public. Changes go through Tier 2 RFCs.

The GitHub Project tracker is sorted by milestone.

Contribution flow

7 + 5 + 3 boundary preservation

Mortar’s core architecture is 7 primitives + 5 core features + 3 extension features. That boundary is what makes Mortar recognizable, and we don’t change it lightly.

Adding a new primitive or feature must demonstrate:

  • Real user demand (≥ 30% of customers have asked)
  • No overlap with existing items
  • Feasible backend implementation (Aliyun / self-hosted)
  • Maintenance commitment
  • Goes through a Tier 2 RFC, ≥ 7 days discussion

Planned additions:

  • primitive/payment (a payment-channel primitive for WeChat Pay / Alipay server-side signature verification)

The bar for removing an existing primitive / feature is higher (Tier 2 RFC + 14 days + 3-maintainer consent) because removals break users.

Maintainer list

Current core team (alphabetical):

  • TBD

Path to maintainer:

  • Sustained high-quality contributions ≥ 3 months
  • ≥ 5 accepted PRs (at least 1 changing a primitive / feature)
  • ≥ 50% of existing maintainers agree

Boundary with Keel / appunvs

DomainWhose decision
Mortar primitive / feature / SDK / wire schemaMortar community
Mortar Cloud operations (managed offering)Mortar team
Mortar self-host / private deployThe user
Keel internalsKeel team (/keel/docs/governance.md)
appunvs internalsappunvs team
How Keel integrates with MortarNo special integration exists — Keel users wire Mortar with the standard Mortar SDK, identical to any other BaaS customer

Important: Mortar does not reference Keel or appunvs in the opposite direction. Mortar is an independent BaaS product, with no “optimized-for-Keel” code paths. A Keel user calling Mortar uses exactly the same SDK as an Expo user calling Mortar — no differentiation.

Business model + open-source relationship

Mortar’s core code is fully open-source: every primitive impl, every feature, every SDK, the wire schema — all Apache 2.0.

Mortar Cloud (managed) wraps the open-source core. The closed parts include:

  • Multi-tenant orchestration / billing / quota system
  • Aliyun-specific backend optimizations (production-grade RDS / OSS / Tair config)
  • Customer support ticketing

The self-hosted build uses the same open-source core code, with no features stripped — it just lacks Mortar Cloud’s ops / SLA / multi-tenant managed offering.

Same “open core + managed cloud” model as GitLab / Sentry / Supabase. See deployment.

Code of conduct

Contributor Covenant 2.1.

Violations go to conduct@appunvs.com (a separate inbox, not the core team issue channel).

License + trademark policy

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

Edit this page on GitHub →