Locara

23 — Governance

How decisions are made, how contributors join, how disputes resolve, how the project sustains itself.

This document describes the target governance model post-public-launch. In phase 0 (pre-launch), the project lead makes all decisions; this doc describes what we evolve toward.

Principles

  1. Transparent. Decisions and their reasoning are public. ADRs capture the why.
  2. Indie-led, not VC-led. No outside investors with control. Funded by users, sponsors, optional services.
  3. Open spec, open code. Anyone can fork. Forks are tolerated, not fought.
  4. Slow over fast for breaking changes. Stable contracts > novel abstractions.
  5. Founder voice + delegated authority. A recognizable maintainer voice (initially the project lead) with explicit delegation to trusted contributors.
  6. Sustainable. Don’t promise more than the project can deliver long-term.

Code of Conduct

Locara adopts the Contributor Covenant 2.1 (https://www.contributor-covenant.org/version/2/1/code_of_conduct/) verbatim.

Enforcement:

  • Reports go to a published email (conduct@<domain>).
  • Initial response within 48 hours.
  • Investigation by the project lead + one other maintainer (when available).
  • Outcomes: clarification, warning, temporary ban, permanent ban.
  • Bans can be appealed once after 6 months.
  • Patterns of enforcement are reported (anonymously summarized) annually.

Roles

Contributor

Anyone who has opened a PR, filed an issue, or otherwise participated. No formal status; the term is descriptive.

Trusted contributor

Granted by maintainers after sustained, high-quality contributions. Can:

  • Triage issues + label them.
  • Approve PRs in scoped areas (e.g., a specific component, a docs section).
  • Flag content for review in the registry.
  • Comment authoritatively on RFC discussions in their area.

Trust is granted based on:

  • ~5+ merged PRs of meaningful scope.
  • Consistent adherence to the CoC.
  • Demonstrated judgment.

Trust is revocable for cause; otherwise persists.

Maintainer

A small group with merge authority and release authority. Can:

  • Merge PRs after review.
  • Cut releases.
  • Manage the registry’s review queue.
  • Vote on RFC outcomes.
  • Onboard / offboard trusted contributors.

Maintainer status is granted by existing maintainers via consensus. There’s no fixed cap, but the role implies sustained commitment, not just “very active for a while.”

Project lead (BDFL-with-delegation)

Initially the founder. Has final authority on:

  • Strategic direction.
  • Disputed RFCs (when consensus among maintainers fails).
  • Sensitive decisions (legal, brand, financial).

The lead delegates aggressively; “lead” doesn’t mean micromanaging.

Succession: if the lead steps back, they nominate a successor with maintainer + community input. If no successor is named, maintainers convene to elect one.

Reviewer (registry)

A subset of trusted contributors / maintainers who can review submitted apps for the registry. Initially the project lead; phase 4+ involves more.

Decision-making

Day-to-day

PRs follow standard open-source flow: opened, reviewed, merged. Maintainers (and trusted contributors in their scope) approve.

Non-trivial / contested decisions: RFC process

For changes that affect:

  • Spec (anything in /spec/)
  • Public API (@locara/sdk, manifest schema)
  • Capability model
  • Trust / safety mechanics
  • Naming / branding
  • Governance itself

…the proposer opens an RFC as a PR to /rfc/:

/rfc/0001-add-text-to-image-modality.md

Format:

# RFC 0001: Add text-to-image modality

Author: <name>
Date: YYYY-MM-DD
Status: Draft | Discussion | Accepted | Rejected | Withdrawn

## Summary
[One paragraph]

## Motivation
[Why this matters; what problems it solves]

## Detailed design
[The actual proposal]

## Drawbacks
[Honest assessment of downsides]

## Alternatives considered
[What else, why not]

## Open questions
[Things the author isn't sure about]

Process:

  1. Open RFC PR. Status starts as Draft.
  2. Discussion happens in PR comments. Author can revise. Status updates to Discussion when ready for input.
  3. Discussion lasts minimum 7 days (ideally 2 weeks for big changes). No hot-takes-win.
  4. Maintainers vote (simple majority). Project lead has tiebreak.
  5. Status becomes Accepted or Rejected. Accepted RFCs spawn an ADR + the implementation work.

Bypassing RFCs

Hot-fixes for security issues bypass the RFC process. They go through normal PR flow with an after-the-fact ADR documenting the decision.

Spec changes specifically

The spec is versioned. Each numbered doc has a version implicit in its content (the schema version of the artifact it describes — e.g., manifest is locara/v1).

Editorial changes (typos, clarifications, new examples): merge via standard PR.

Substantive changes (changing behavior, adding fields, deprecating fields): require RFC + ADR.

Breaking changes: require RFC + 6+ months of lead time + migration tooling + parallel support of both versions.

Funding & sustainability

Locara’s costs are minimized by design (see phasing). Phase-3 opex < $100/mo: domain, Apple Dev Program, Cloudflare R2 bandwidth, optional managed Postgres.

Funding sources:

  1. GitHub Sponsors / Open Collective. Individual + organizational sponsors. Suggested tiers: $5/mo (individual), $50/mo (small org), $500/mo (corporate).
  2. Optional paid services (24-monetization.md). Verified-privacy certification, enterprise registry features.
  3. Grants. Open-source / digital-rights / privacy-focused grants where applicable (e.g., Mozilla, NLNet).
  4. Founder time, donated. Realistically the largest input in early phases.

What we don’t do:

  • Take VC.
  • Sell user data (we don’t have any).
  • Sell ads.
  • Charge for the framework itself.
  • Charge for the official registry’s basic features.

Sponsor transparency:

  • Public list of sponsors above $500/mo.
  • Sponsors get logo placement on the website (no decision-making influence).
  • Annual financial summary published.

Repository hygiene

Issues

  • Issue templates for: bug report, feature request, RFC, security report.
  • Triage: trusted contributors label and route within 7 days.
  • Stale issues are auto-marked stale after 90 days inactive; closed after 30 more days. Reopen on demand.

PRs

  • All PRs require at least one maintainer review.
  • CI must pass (tests, lint, build).
  • Squash merge by default; preserve history when meaningful.
  • PR templates require: description, testing notes, breaking-changes flag.

Releases

  • Semantic versioning for the framework + SDK.
  • Release notes published with each release.
  • Breaking changes require deprecation notice in the prior minor version.

Branches

  • main — always-deployable; protected; requires PR + review + CI.
  • release/* — long-lived for in-progress major versions.
  • Feature branches off main.

Forks + competing implementations

Locara is OSS. Forks are explicitly allowed and tolerated:

  • The capability + manifest spec is open. Anyone can build a runtime against it.
  • Alternative registries are first-class — anyone can run a competing catalog website serving Locara-built apps.
  • Forks can use the Locara name + brand only with permission (see brand policy in 29-branding.md).
  • We commit to not using technical lock-in (proprietary file formats, undocumented APIs, registry-only artifacts) to fight forks.

If a fork solves a real problem we don’t, that’s a signal to incorporate the idea, not to compete.

Maintainer succession + bus factor

The project lead nominates a successor publicly (in a private will-style document committed to a private repo, accessible by maintainers).

If the project lead is incapacitated and no successor is named:

  1. Existing maintainers convene.
  2. Elect new lead by simple majority.
  3. New lead’s first responsibility: name a successor.

If maintainers cannot reach quorum (e.g., project becomes inactive):

  1. Locara’s domains, certificates, and signing keys are documented in escrow with a trusted third party (e.g., a digital-rights nonprofit).
  2. After 6 months of inactivity, escrow can release control to the largest active fork.
  3. The OSS code remains free under Apache-2.0 regardless of organizational state.

Conflict resolution

When a disagreement can’t be resolved through normal discussion:

  1. De-escalate. Take a 24-hour break from the thread.
  2. Maintainer mediation. A non-involved maintainer summarizes positions + facilitates.
  3. RFC. If the disagreement is structural, formalize it as an RFC.
  4. Project lead decision. Final tiebreak.

Never resolved via:

  • Voting weight tied to financial contribution.
  • Closed-door deals.
  • Public shaming.

Trademark + brand (placeholder)

The project name (currently “Locara” — placeholder per 29-branding.md) and logo are owned by the project’s legal entity (TBD).

  • Free use: linking, factual references, “I built X with [name]” in marketing copy.
  • Permission required: derivative branding, hosted services using the name, commercial products with the name in title.
  • Forks: must rename if they materially diverge from the spec.

Specifics in 29-branding.md.

Annual reporting

Once the project has a meaningful community (phase 4+), publish annually:

  • Active contributor count + diversity (geographic, role).
  • Financial summary (income, opex, cash on hand).
  • Major decisions made + their outcomes.
  • Open-source health metrics (PR turnaround, issue close rate).
  • Anything else the community thinks should be tracked.

Cross-references