Landscape / Overview

Open Git platforms

The field is full of capable forges. The open question is whether one can feel as familiar as GitHub, run anywhere, and still belong to a cloud of operators who can help one another recover.

Researched September 2026

01 / The mature set

Self-hosting is solved enough.

GitLab, Forgejo, Gitea, OneDev, and others already prove that an open Git forge can run outside GitHub.

02 / The missing layer

Most homes are still islands.

Federation, replication, and recovery are separate problems. Mirrors move repository data; they do not automatically move identity, permissions, issues, reviews, routing, or a working service.

03 / The Forkalope bet

Fork the home, then connect it.

Make the familiar forge easy to deploy, then make shared access, operations, and recovery part of the product from the start.

The comparison

A directional read of the projects closest to the thesis.

✓ current focus · ~ partial or adjacent · ? unverified · — not the center

Comparison of Forkalope and major open-source Git forge projects.
Capability	forkalopeproposed network	GitLab CEfull DevOps forge	Forgejocommunity forge	Gitealightweight forge	OneDevintegrated DevOps	SourceHutUnix-style suite	Radiclepeer-to-peer forge	TTangledAT Protocol forge	HHarness Open Sourceformerly Gitness
Foundation
Open-source software	plan	✓	✓	✓	✓	✓	✓	✓	✓
Self-hostable	plan	✓	✓	✓	✓	✓	✓	✓	✓
GitHub-familiar UI	target	✓	✓	✓	✓	~	~	~	✓
Collaboration surface
Issues + pull / merge requests	target	✓	✓	✓	✓	~	~	~	✓
CI/CD	target	✓	✓	✓	✓	✓	~	✓	✓
Package registries	target	✓	✓	✓	✓	—	—	—	✓
API + migration tooling	target	✓	✓	✓	~	~	~	~	✓
Network relationship
Federation / shared access	core	~	~	—	—	—	✓	✓	—
Replication beyond mirrors	core	~	~	—	—	—	✓	✓	—
Portable identity + social data	core	~	~	—	—	—	✓	✓	—
Mutual recovery network	core	—	~	—	—	—	~	?	—

Swipe horizontally to compare all platforms

This is a directional comparison, not a product certification. “✓” means the capability is part of a project’s current center of gravity; “~” is partial or adjacent; “?” means the reviewed documentation was not enough to verify the claim; “plan,” “target,” and “core” describe Forkalope’s proposed direction.

Field notes

The lesson each project brings to the table.

Forgejo

closest familiar analogue

Forgejo is a community-driven fork of Gitea, now developed independently, with migration options that depend on the source version. Its federation work is the clearest proof that an open, familiar forge can think beyond one server—but Forgejo documents federation as experimental, with moderation and access-control work still unfinished. Read the upgrade guide ↗

Takeaway: make the familiar surface and the network protocol deliberate parts of the same product.

Radicle

closest network analogue

Radicle is an open-source, peer-to-peer code collaboration stack built on Git. It gives each node a role in replication, uses cryptographic identities, and stores issues and patches as signed collaborative objects. It is the strongest architectural reference here, while its CLI/local-first workflow is intentionally unlike a drop-in GitHub UI. Visit Radicle ↗

Takeaway: decentralization should improve ownership without making everyday collaboration feel foreign.

Gitea

lightweight baseline

Gitea is the lightweight, self-hosted all-in-one baseline: code hosting, code review, team collaboration, package registry, and CI/CD in a small service. Its strength is the simple install and familiar UI; its center is still the independently operated instance rather than a shared network. Read the Gitea docs ↗

Takeaway: deployment has to be easy enough that “run your own” is a normal choice.

GitLab Community Edition

feature-complete benchmark

GitLab CE sets the breadth benchmark: repository management, access control, merge requests, issues, wikis, and a large integrated DevOps surface. It is powerful, but its operational weight and open-core split make it a useful contrast for Forkalope’s goal of keeping the complete deployable core understandable. See GitLab CE ↗

Takeaway: “100% the features” also means respecting the cost of running and upgrading them.

SourceHut

different workflow, strong values

SourceHut takes a modular, Unix-style approach with Git and Mercurial hosting, mailing lists, patch review, CI, wikis, and a CLI. Its no-tracking, no-JavaScript-friendly posture, export tooling, and entirely open-source software that can run on your own infrastructure are valuable ownership references, even though its email-first workflow is not the UI everyone already knows. Explore SourceHut ↗

Takeaway: openness is also a product experience, not only a license.

OneDev

integrated alternative

OneDev packages Git hosting, issue management, Kanban, packages, and CI/CD into a self-hosted service. Its integrated workflow is close to the “one place for the whole team” expectation, but clustering is an enterprise feature and the platform remains a traditional server deployment. Start with OneDev ↗

Takeaway: a distributed product needs a better answer for operations, not only a distributed slogan.

Tangled

closest Forkalope overlap

Tangled combines lightweight Git repository servers called knots with a shared web application built around AT Protocol, so repositories can appear across independently hosted servers. Its open-source, self-hostable stack also includes Spindles, a CI system with self-hosting instructions. The reviewed documentation establishes distributed hosting and shared access; an equivalent cross-operator mutual-recovery commitment remains unverified. Read the Tangled docs ↗ See Spindles ↗

Takeaway: the differentiation is not “distributed Git plus a web app has never been combined”; it is making coordinated recovery explicit.

Harness Open Source

formerly Gitness

Harness Open Source is the next evolution of Gitness: an Apache-2.0-licensed, self-hostable development platform with code hosting, automated pipelines, Gitspaces development environments, and artifact registries. Compare this open-source repository and product surface—not the wider commercial Harness portfolio. Read the repository ↗

Takeaway: a modern forge comparison should count integrated build and artifact infrastructure when it ships in the open core.

Also on the radar

Smaller or more specialized forges that sharpen the comparison.

GitBucketGitHub API-compatible Scala platform with repositories, issues, pull requests, wiki, and plugins.GitHub-shaped ↗

GogsThe lightweight ancestor: simple, stable, extensible self-hosted Git with issues, pull requests, wiki, and mirroring.Minimal baseline ↗

PhorgeCommunity-maintained suite for code hosting, code review, task management, and opinionated team workflows.Review-centric ↗

Apache AlluraApache’s open-source forge for repositories, bug reports, discussions, wikis, and extensible project tools.Extensible forge ↗ GGerrit Code ReviewOpen-source, self-hostable Git hosting and review with fine-grained permissions, CI integration, replication, and clustering capabilities.Review-focused ↗ SSCM-ManagerExtensible repository-management platform for Git, Mercurial, and Subversion, with APIs, permissions, and plugin-based pull / merge requests.Plugin platform ↗ RRhodeCode Community EditionOpen-source core with repository hosting, pull requests, code review, and access controls; enterprise integrations and HA remain commercial extensions.Open core ↗ KKallitheaGPLv3, self-hostable Git and Mercurial platform with access controls, forks, and pull-request review.Git + Mercurial ↗ PGitPrepSmaller Perl-based, self-hosted GitHub-like system with repositories, pull requests, issues, and wikis.Smaller option ↗ BGitblitApache-2.0 Java software for managing, viewing, and serving Git repositories over Git, HTTP, and SSH.Git server ↗

Status caveats

Names worth knowing, but not unqualified current recommendations.

PPagureFedora announced a planned pagure.io decommission at the end of July 2026. That is a hosted-service transition note, not proof that all Pagure software development has ended.Historical / transition ↗ TTuleap Community EditionThe official development site currently says Community Edition development and releases are no longer public. Previously released open-source versions should not be described as having ceased to be open source.Availability caveat ↗

The opening

Forkalope’s focus: familiar collaboration, independent hosting, and coordinated recovery.

Projects such as Tangled show that independent repository hosting and a connected collaboration experience can already coexist. Forkalope’s goal is narrower and more operational: make cross-operator recovery an explicit part of the system—not simply an infrastructure task left to each administrator.

Federation, replication, and recovery are different requirements. The hard part is making identity, permissions, issues, reviews, search, packages, actions, backups, moderation, upgrades, and a successfully restored service behave coherently across independently operated nodes.

Sources

Primary project documentation and repositories used for this first pass.

Checked September 2026

Forgejo FAQ federation status ↗ Radicle protocol guide peer-to-peer model ↗ Gitea documentation feature surface ↗ GitLab CE repository open-source edition ↗ SourceHut open suite + workflow ↗ OneDev docs self-hosted CI/CD ↗ GitBucket repository API compatibility ↗ Tangled docs knots + shared app ↗ Tangled Spindles self-hosted CI ↗ Harness Open Source repository code + pipelines + registries ↗ Harness announcement formerly Gitness ↗ Gerrit Code Review review + operations ↗ SCM-Manager plugins + repositories ↗ RhodeCode editions community vs enterprise ↗ ForgeFed federation protocol ↗ Forgejo upgrade guide migration limits ↗ Fedora on Pagure service transition ↗ Tuleap development site CE status ↗ Hetzner dedicated servers commodity infrastructure ↗

Scope note: this is a product landscape, not an exhaustive catalog of every Git forge. It prioritizes active, open-source projects with meaningful overlap in UI, self-hosting, collaboration, or distributed ownership. Capabilities and availability change; the links above are the source of truth.