opencode-forges

Context and upstream proposals for running public-sector code platforms on Forgejo .

Several governments are building public code hosting on Forgejo — the Netherlands' code.overheid.nl and the planned Swiss opencode.swiss — alongside GitLab-based predecessors like Germany's opencode.de. The plural in the name is deliberate: this is about a network of national public-sector forges (one per country, each sovereign), not a single project — and the concrete bet here is Forgejo, not a forge-software-neutral abstraction.

This repository is the living context behind a set of Forgejo upstream discussions and feature requests. It exists so those tickets can link to a stable, evolving place for the why and the how-it-all-fits — the tickets themselves remain the source of truth for discussion.

Documents

• BLUEPRINT.md — the strategy: why Forgejo, the build-around-the-forge / upstream-first discipline, MVP shape, reusable components, identity-as-trust model, multi-country governance, funding, and federation as the cross-border future.
• ROADMAP.md — the phased execution plan: a gated rollout (Phase 0 discovery mirror → closed beta → controlled opening → federation) with concrete prerequisites, success metrics, per-phase budgets, and gate-driven pacing. BLUEPRINT is the why; ROADMAP is the when.
• ARCHITECTURE.md — the component map: how Forgejo, the identity broker, public-sector IdPs (PS-IdP), the reverse proxy, companion apps, and runners fit together, with the main login and request flows. Start here for the big picture.
• EXTENSIBILITY.md — adding custom UI + SSO without forking core: the injection seam, external-IdP brokering, one-origin reverse-proxy hosting, accessibility, and a realistic "ask upstream for stable edges" ladder.
• RUNNERS.md — CI/CD as a service: why Forgejo Actions is poorly suited to multi-tenant use, and the build-around answer (Woodpecker on Kubernetes / Stretchy / bring-your-own runners).
• ACCESS_CONTROL.md — open registration with controlled creation, forks, and provenance — requirements & design.
• MODERATION_AND_SECURITY.md — keeping the open floor safe: content moderation, abuse/anti-spam hardening, platform security posture, incident response, and the legal/compliance hooks (the access-trust and provenance pieces stay in ACCESS_CONTROL).
• ONBOARDING.md — preparing a repo for publication: license selection, publiccode.yml, and pre-publication hygiene (secrets/history/PII scrubbing, the gitleaks gate, clean-snapshot vs. history rewrite).
• TICKETS.md — the registry of upstream asks (filed, draft, and existing threads to back), each a self-contained, fileable entry linking back to its design doc.
• TO_INVESTIGATE.md — the live-instance test registry: questions needing a running Forgejo to settle, added by title and removed once verified into a design doc (none open at present).

Upstream tickets

All upstream asks — filed, draft, and existing threads to back — live in TICKETS.md , each a self-contained entry linking back to its design doc.

Relation to the publiccode.yml metadata proposal

A controlled forge is also a natural place to prove out a broader publiccode.yml metadata proposal (faceted classification, supply-chain references, a usage registry). That work lives with the proposal itself — see its TOOLING.md — and is intentionally kept out of this repository to avoid conflating the two efforts.

On the name: "opencode" as an umbrella

The term opencode has emerged as the preferred name for national, public-sector code platforms — independent of the underlying forge software: opencode.swiss (Forgejo), opencode.de (GitLab), and others in the network. This repository recommends Forgejo (see BLUEPRINT.md), but the name is a forge-neutral umbrella, not a bet on one technology. It captures the dual commitment:

• Open — transparent, freely auditable source code (a public-sector duty).
• Code — software development and collaboration as a first-class platform practice.

By establishing opencode as the umbrella term, we create a recognizable, cross-border brand for sovereign, community-governed code hosting — distinct from commercial forge services and from the specific instance names (which may include regional qualifiers like .swiss or .de). This repository, opencode-forges, documents the shared strategy and components that make such instances possible and interoperable.

Who's behind this & how to engage

Driven by Zentrum SDS (a Swiss public-sector digital-sovereignty initiative, anchored at the Bern University of Applied Sciences) planning the Forgejo-based opencode.swiss, in conversation with public-sector peers (NL / BZK, ZenDiS, Schleswig-Holstein) under equivalent obligations.

The approach is deliberately upstream-first: we'd rather co-design and help fund features that benefit every Forgejo instance than carry a soft fork. If you're working on a related upstream effort, or run a public-sector forge yourself, we'd like to coordinate — please comment on the tickets above.

Inline markers

Two greppable markers flag things inline, in context, so the surrounding rationale travels with them.

OPEN[<facet>] — a question only an outside expert can settle:

> ⚠️ OPEN[legal]: <the question>

Collect them with grep -rn 'OPEN\[' ., or by facet with grep -rn 'OPEN\[legal\]' .. (Codeberg's code search uses Bleve, which ignores punctuation — search the bare words OPEN legal there rather than the literal OPEN[legal]; grep remains the exact method.) A facet is added only when there is a genuine external-review handoff — currently legal (questions for counsel: content liability, data protection, accessibility-conformance obligations, non-endorsement). a11y-audit / security-review would be added only if such an audit is actually commissioned. Topic coverage lives in the relevant sections, not in markers.

ASSUMED: — a load-bearing claim not yet verified:

> ⚠️ ASSUMED: <claim> — <how to verify>

Forgejo behaviours, config effects, and third-party capabilities are stated as fact only once confirmed — empirically on a live instance or read in source. So anything without an ASSUMED: marker is taken to be verified; the marker flags the exceptions still owed a check. Collect them with grep -rn 'ASSUMED:' .. A marker is removed once the claim is verified (it becomes plain text) — or, if it fails, the design changes.

Status

Living documents; expect them to evolve. The linked Forgejo discussions and issues are the canonical place for design discussion — this repository is background and cross-document context, not a substitute for them.

Authoring note: the documents in this repository were drafted with the assistance of Claude (Anthropic) and reviewed and edited by the author.