Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions CHARTER.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Helpthread is the answer for people who already live on serverless infrastructur

## 3. Licensing & intellectual property

Helpthread's core is licensed **AGPL-3.0**. Contributions are accepted under the **Developer Certificate of Origin (DCO)** — a sign-off on every commit, inbound license identical to outbound, no CLA, no copyright assignment. Contributors keep the copyright on their work, which makes the core's license permanent by structure rather than by promise. What makes it lawful to sell first-party commercial modules alongside the AGPL core is not ownership of the core — it is the module boundary and its plugin exception, defined below. Paid first-party modules ship under a separate proprietary/commercial license from their own closed repositories, distributed through an official marketplace — a later phase, not a launch-day feature.
Helpthread's core is licensed **AGPL-3.0**. Contributions are accepted under the **Developer Certificate of Origin (DCO)** — a sign-off on every commit, inbound license identical to outbound, no CLA, no copyright assignment. Contributors keep the copyright on their work, which makes the core's license permanent by structure rather than by promise. What makes it lawful to sell first-party commercial modules alongside the AGPL core is not ownership of the core — it is the module boundary and its plugin exception, defined below. Paid first-party modules ship under a separate proprietary/commercial license from their own closed repositories, distributed through an official marketplace — live at public launch, proven first as the project's own dogfood install path (amended 2026-07-19; see below).

**Given up, deliberately:** dual-licensing the core — selling AGPL exceptions or relicensing later — is off the table once outside contributions land; no one can relicense the core without the consent of every contributor. That option is worth little here: the demonstrated buyers of AGPL exceptions *embed* a component in their own product, and Helpthread is an end application its users operate (running an unmodified AGPL helpdesk carries no copyleft obligations at all) — what remains, white-label resellers and blanket-AGPL-ban enterprises, is small. Also given up: a CLA's patent grant, warranties, and employer sign-offs — AGPL §11's per-contributor patent grant partially substitutes, and any indemnity offered to module customers is priced without upstream contributor representations. The revenue model is modules and the marketplace, not license arbitrage. The same structure binds Resonant IQ symmetrically: the company is a licensee of its contributors' code like anyone else, so core modifications running in any hosted offering get source-offered to its users under AGPL §13.

Expand All @@ -42,7 +42,7 @@ This charter is not legal advice. Counsel reviews the licensing structure, the p

## 4. Architecture direction

Serverless kills the traditional runtime plugin-folder model — there's no long-lived filesystem to drop a module into. Helpthread's extension model is designed in from day one along two tracks: **build-time npm plugins**, where an operator adds a package and redeploys — the install *is* the Vercel build — and **typed event hooks / webhooks** for integrations that live out-of-process entirely. The plumbing paid modules will need (license keys, a private registry, an update channel) is marketplace-phase work, not something we're speculatively building now.
Serverless kills the traditional runtime plugin-folder model — there's no long-lived filesystem to drop a module into. Helpthread's extension model is designed in from day one along two tracks: **build-time npm modules**, where an operator adds a package and redeploys — the install *is* the Vercel build — and **typed event hooks / webhooks** for integrations that live out-of-process entirely. The plumbing paid modules need (license keys, license-gated distribution, an update channel) is built alongside the modules themselves and exercised through the project's own installs long before a stranger's money touches it — never as a runtime restriction: a license authenticates downloads and updates, and no shipped module ever phones home or stops working when a license lapses (`specs/modules/catalog.md` §5).

**Platform posture: Vercel-first, not Vercel-only.** The first-class deployment target is Vercel + Supabase, and the deploy story is optimized for it without apology. But the engine's core never calls a platform directly: queueing, scheduled and durable work, blob storage, and inbound email all sit behind thin provider interfaces the project owns, with today's implementations (Vercel Queues, Vercel Cron and Workflows, Supabase Storage, Gmail push) as adapters rather than assumptions. Inbound email forces this discipline anyway — Gmail can't be the only supported mailbox forever — and applying it to the other seams keeps a future plain-Node-plus-Postgres deployment mode reachable without an engine rewrite. Supabase itself is open source and self-hostable, so that half of the stack is a soft dependency by construction. No additional deployment targets are promised at launch: every supported target is a permanent test matrix, and that cost gets taken on only when demand justifies it.

Expand All @@ -61,7 +61,7 @@ No dates; phases are ordered by dependency, not calendar.
- **Phase 0 — Foundations.** Name, domains, GitHub org, and npm org secured (done). This charter. A public-ready engine repo with clean history.
- **Phase 1 — Core engine, dogfooded.** Mail engine: event-driven ingestion (bounded reconciliation fetches, never a long-running poller), parsing, threading, sending, signed reply tokens, auto-responder handling, bounce handling, HTML sanitization. The six-operation conversation API. An agent inbox UI. Gmail push for inbound. This runs as Resonant IQ's actual production support desk before it runs as anyone else's.
- **Phase 2 — Production cutover.** Resonant IQ retires its FreeScout instance and switches to Helpthread at the config level — a clean cutover with no legacy data requiring migration.
- **Phase 3 — Public launch.** Deploy-to-Vercel button, public docs site, the operator-facing knowledge base, and the start of a community. The marketplace license keys, module registry, first paid modules — follows once there's demand to justify it; AI-powered modules (draft-reply suggestions, auto-triage, knowledge-base-grounded auto-answers in the widget) are the leading candidates for those first commercial offerings.
- **Phase 3 — Public launch.** Deploy-to-Vercel button, public docs site, and the start of a community — **with the marketplace live on day one**: license keys, module distribution, and the first paid modules (the knowledge base and AI-powered modules draft-reply suggestions, auto-triage, KB-grounded auto-answers in the widget — lead the catalog), all having served as Resonant IQ's own install path through the dogfood phase. A helpdesk launched free with its commercial layer already real avoids the worse story: a community formed around ambiguity about how the project sustains itself.

The full helpdesk surface — mailbox management, roles and permissions, workflows, SLAs, saved replies, reporting, admin, search, and the chat channel plus embeddable support widget described in the architecture section — gets built incrementally, prioritized by what real usage demands. The map of that territory is drawn from the helpdesks we know best — Help Scout's experience and FreeScout's feature surface — as a guide, not a contract; the measure Helpthread holds itself to is Help Scout's ease of use, for customers and operators alike. The mail engine, for all the care it gets, is only something like 10–15% of that eventual surface. This is a multi-month-plus endeavor, not a weekend rewrite, and nobody involved should pretend otherwise.

Expand All @@ -85,4 +85,6 @@ Solo-maintainer, BDFL model for now — there is one project, one person account

**Amended 2026-07-10 (HT-21):** §3 and §7 — the CLA/consolidated-copyright model replaced with DCO-only contributions; the module boundary's plugin exception promoted to the load-bearing legal mechanism, its counsel deadline moved to before the first external contribution; dual-licensing of the core deliberately given up; trademark policy added to pre-launch counsel work.

**Amended 2026-07-19 (HT-79):** §3, §4, §5 — the marketplace moves from "a later phase, once demand justifies it" to a launch-day component of Phase 3, built now and proven as the project's own dogfood install path. Rationale: the original deferral assumed the module substrate and first modules would not exist until after launch; both shipped during the dogfood phase, so the remaining marketplace work is commerce plumbing, not speculation — and launching the free helpdesk with its sustainability model already visible is the more honest story. The §7 plugin exception's counsel deadline is unchanged (before first external contribution): every v1 marketplace module is out-of-process and needs no exception. New counsel items before the marketplace takes real money: the commercial module license text and terms of sale.

**Amended 2026-07-19 (HT-75):** §3 and §4 — the knowledge base reclassified from free-forever core to a paid first-party module. FreeScout's own reference instance runs its Knowledge Base as a paid purchase (`specs/ui/admin-ia.md`); keeping ours core was chosen 2026-07-18 as a marketed free-vs-FreeScout differentiator (`specs/modules/catalog.md` §1), and TJ reversed that call on review. Not a retroactive paywall under the §3 invariant — the knowledge base was never shipped (`specs/modules/catalog.md` §2.1's shipped list never included it). Full paid-module catalog: `specs/modules/catalog.md`.
Loading