# The Gateway Commercial Model

The Gateway should use an open-source core with paid operations around it.

This document is public-safe. It explains how the project can be funded without weakening the open-source trust story or taking control away from operators.

## Principle

The layer that controls traffic, DNS, routes, fallback, and identity separation should be inspectable.

The core should stay useful and self-hostable. Paid offerings should fund convenience, reliability, support, appliances, managed operations, and long-term maintenance rather than artificial limitations.

## Public Funding Paths

### Donations And Sponsorship

Purpose:

- Fund public maintenance.
- Support documentation and runbooks.
- Pay for test hardware and release infrastructure.
- Fund security review and evidence publishing.

Sponsor benefits can include public credit, roadmap notes, and priority public issue visibility. Sponsorship should not buy hidden telemetry, private control over the core, or guaranteed private feature work.

### Guided Support

Purpose:

- Help operators install, upgrade, recover, and reason about DNS, routes, fallback, and privacy posture.

Support boundaries:

- Operators keep credentials, route choices, and final approvals.
- Remote access, if used, must be explicit, time-limited, revocable, and logged.
- Support bundles should be operator-generated and redacted.
- Support should not require default traffic inspection.
- Support does not guarantee anonymity.

### Appliances And Signed Builds

Purpose:

- Reduce install friction for users who want the outcome without building every layer themselves.

Possible offers:

- Signed images.
- Preconfigured devices.
- Backup and restore workflow.
- Optional guided setup or support.

Any appliance offer should wait for a documented hardware matrix, update path, rollback path, and support boundary.

### Managed Operations

Purpose:

- Help teams keep local control while outsourcing routine operational work.

Possible services:

- Update review.
- Configuration backup.
- Recovery support.
- Policy templates.
- Privacy-safe support bundle review.
- Optional remote support access under explicit customer control.

Managed services should avoid traffic visibility unless the operator explicitly asks for a scoped diagnostic path.

### MSP And Consultant Path

Purpose:

- Let consultants and small IT providers deploy The Gateway repeatedly with documented procedures.

Possible assets:

- Deployment templates.
- Operator runbooks.
- Client handoff docs.
- Redaction and retention rules.
- Offboarding/export process.
- Priority support path.

The MSP path should remain a pilot until install, rollback, hardware support, and evidence collection are stable.

## Keep Open

- Local gateway core.
- Policy model.
- DNS and routing primitives.
- Basic UI or CLI required for self-hosted operation.
- Community runbook specs.
- Docs and examples.

## Charge For

- Guided support.
- Managed operations.
- Hosted status or backup service where appropriate.
- Privacy-safe support bundle review.
- Signed appliance builds.
- Support SLAs.
- MSP tooling.
- Enterprise integration help.

## Public Funding Narrative

Use this framing:

> The Gateway is open source because the layer that controls your traffic should be inspectable. Sponsorship and paid operations fund the work needed to make that layer reliable.

Funding should be tied to concrete public outcomes:

- Better install docs.
- Hardware testing.
- Recovery drills.
- Security review.
- Public runbooks.
- Release maintenance.
- Operator evidence.

## Warnings

- Do not cripple the open-source core.
- Do not sell support that requires credential custody.
- Do not promise anonymity as a service outcome.
- Do not sell enterprise commitments before install/docs/evidence are credible.
- Do not make MSP the primary story before repeat deployment evidence exists.