Compare the suite, project by project.

GitHub holds source identity, the runner pool, the marketplace, and the merge surface. PMCI replaces the runner + evidence stack; it does not try to replace the marketplace, but it removes the runtime dependency on a single platform.

GitLab couples CI to the forge: change forge, change CI. PMCI is decoupled — source replicates over Radicle, CI runs against any ref, evidence is signed independently.

Both bet that the control plane is best owned by a SaaS provider. PMCI bets the opposite: the control plane is local files plus a Radicle peer set, and the SaaS dashboard is replaced with one a dashboard process anyone can run.

The closest neighbors in spirit. The split is the evidence model: Drone/Woodpecker produce run logs and exit codes; PMCI produces signed attestations + content-addressed artifacts that survive without the dashboard.

Jenkins is the canonical “run anything anywhere” tool. PMCI gives up plugin sprawl in exchange for a tighter protocol contract and content-addressed artifacts. Jenkins wins on flexibility; PMCI wins on auditability.

Tekton requires Kubernetes and lives inside its CRDs. PMCI runs on any host with a shell and produces evidence that does not require a cluster to read.

The deploy authority is “whoever can write a workflow file in a GitHub repo.” PMCD makes the deploy authority “whoever can write the release manifest,” pinned to a sha256, and refuses anything that doesn’t match.

ArgoCD assumes a cluster and a long-running controller. PMCD assumes a host with SSH and a sha256. They solve different shapes of the problem; ArgoCD wins when k8s is non-negotiable.

Closest in spirit to PMCD’s pull-style CD — both poll for promotion changes. The split is the target: Flux is k8s-shaped; PMCD is anything you can SSH into.

Spinnaker brings opinionated multi-cloud orchestration. PMCD is opinionated about evidence, not about clouds. If your problem is “ship to 4 clouds with the same pipeline,” Spinnaker wins.

Both require an agent on the target. PMCD requires SSH and a manifest reader. The trade is agent ergonomics (rich health checks, blue/green automation) vs. fewer moving parts.

The closest UX neighbor — both are SSH-based. PMCD replaces the “run a script” model with “install these bytes if the hash matches.” That swap is the whole product.

GitHub holds source identity, the review surface, and the access decision. Seed Kit gives the access decision back to a Radicle allowlist, and replaces the browser review surface with patches gossiped between peers.

GitLab is a single integrated platform. Seed Kit decomposes that into source replication (Seed Kit), CI (PMCI), CD (PMCD), and backlog (Radicle Priorities) so each piece is replaceable.

Closest UX neighbors for “a small team self-hosts source.” The split: Seed Kit doesn’t give you a browser MR UI — it gives you a seed-backed Radicle network with private-by-default availability.

sourcehut and Seed Kit agree that the browser shouldn’t be the canonical workspace. Seed Kit goes further by making source replication itself peer-to-peer rather than HTTPS-clone-from-a-host.

cgit + gitolite is the “just enough forge” setup that pre-dates GitHub. Seed Kit adds gossip, NAT-friendly onboarding, and a privacy guardrail layer that gitolite doesn’t reach.

The minimum viable Radicle setup. Seed Kit is the “you actually want to operate this” layer on top: DigitalOcean automation, onboarding flows, privacy guardrails, Tor + multi-seed templates, mirroring runbooks.

The closest Lightning-native neighbor. L402 answers “did this client pay for access?” ECSC answers “does this bilateral service state have enough evidence to justify the next channel update?” Same Lightning primitives, different center of gravity: access control vs. evidence-gated bilateral settlement.

V4V generalizes payment cadence (pay continuously, per minute, per listen). ECSC generalizes payment justification (pay only when evidence proves a service-state transition is valid). The two can compose — a streaming-media platform could use ECSC if each segment, royalty split, or transcript job needed evidence-gated settlement — but ECSC is not a media monetization protocol.

The closest abstract family. ECSC deliberately narrows the first implementation to ordinary Lightning HTLCs instead of introducing a new smart-contract state-channel framework. Same idea (application state gates a payment); much narrower scope (one bilateral service contract on Lightning, not a general-purpose VM).

ECSC is not a browser monetization protocol or a ledger-agnostic transport. It is Lightning-focused and binds evidence roots to HTLC / channel receipts. ECSC should borrow the evidence-message discipline of these systems without becoming a value-routing intermediary.

The conceptual overlap is the oracle pattern: PMCI attestations sign facts that get used in a settlement decision. ECSC doesn’t need DLC settlement mechanics; PMCI attests service work, policy, result hashes, freshness, worker identity, and verifier authority rather than acting as a general financial-outcome oracle.

ECSC is not an appchain. It has canonical protocol artifacts, evidence roots, and state machines, but no validator set, no block production, no bridge, no chain consensus layer. The settlement substrate is the Lightning Network, not a new chain.