加载失败
HardenedBSD（基于 FreeBSD 的安全加固项目）把代码协作从传统的 self-hosted GitLab（自托管代码托管平台）迁到 Radicle（一个基于 Git 的 peer-to-peer 代码协作网络）。评论里补充说，这次迁移和他们之前提到的“GitLab 被机器人流量压得很重”有关，也反映出他们早就想尝试更分布式的工具。Radicle 的工作方式是把仓库复制到多个 peer/seed 节点上，并支持 local-first 协作，所以开发者即使离线也能先写 issues 或 patches，之后再同步。争议点则集中在可发现性：和 GitHub（主流代码托管平台）相比，Radicle、ATProto（去中心化社交协议）、Fossil（集成式版本控制系统）这类方案都能解决单点问题，但如何让别人找到项目、做好搜索与入口仍然是最大短板。有人还拿 IPFS（去中心化内容寻址存储网络）类比，提醒如果原始节点退出，数据可用性会变差；支持者则认为源代码比图片、视频更容易长期被镜像和缓存。
很多人先承认自己以前没听过 Radicle，随后补充它是一个基于 Git 的 peer-to-peer 代码协作栈，仓库在节点之间复制，而不是由单一平台控制。有人特别提到它的 Collaborative Objects（COBs），把 issue、discussion、code review 之类的协作内容也做成 Git objects。也有人指出公告本身几乎没有解释 Radicle 是什么，连官网入口都只写着“公共节点”，信息密度很低。
评论把这次迁移和 HardenedBSD 之前的说明连在一起看：他们原本的 self-hosted GitLab 受到机器人流量和压力。迁到 Radicle 既是现实驱动，也是早就想推进的方向。有人质疑这只是把负载从 GitLab 换到 Radicle 节点，但支持者解释说，p2p 的好处不是把单点服务器变成另一个单点，而是让仓库分布到多个 peer/seed 上。即使官方 seed 掉线，仓库同步仍可继续，开发者还能把 Radicle 当作本地 git server 使用。
最集中的担忧是“可发现性”，而不是仓库能不能放上去。有人直言，真正难的是让别人找到项目；Radicle 的 search 站点存在，但对 HardenedBSD 之类的项目几乎搜不到。于是有人建议需要一个 project gateway 或 indexer，甚至讨论用 DHT（分布式哈希表）做节点公告，但又担心去中心化复制会放大不想传播的内容。也有人强调 GitHub（主流代码托管平台）之所以强，不只是托管，更是 code search、社交链接和默认入口的发现能力。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
另一条线是在拿 Radicle 和 ATProto、Fossil、IPFS 这些方案对比。有人认为 Radicle 更像真正的去中心化 p2p，而 ATProto（去中心化社交协议）在实践里仍偏中心化；Radicle 还支持离线创建 issues 和 patches，联网后再同步。也有人觉得它和 Fossil（集成式版本控制系统）思路相近，但区别在于 Radicle 基于 Git 且更强调网络层的去中心化。围绕 IPFS（去中心化内容寻址存储网络）的经验也被拿来提醒：如果原始 seeder 消失，某些数据会变得不可访问，不过代码仓库比图片、视频更适合长期镜像。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
Radicle: 一个基于 Git 的 peer-to-peer 代码协作网络/forge，仓库通过多个节点复制，不依赖单一中心化平台。
local-first: 先在本地完成开发和协作，离线也能工作，联网后再同步到网络。
seed node / seeder: Radicle 中负责承载、传播和同步仓库副本的节点；某个官方 seed 掉线不等于仓库消失。
ATProto: 一个去中心化社交协议；讨论里常被拿来和 Radicle 比较中心化程度与实际部署效果。