谁应为源代码的可用性买单？
内容提要
作者探讨了源代码托管可靠性问题，指出GitHub等集中式平台不稳定，分叉或捆绑依赖虽可行但效率低。他推崇Radicle的P2P网络，认为其通过节点播种和去中心化协作，能平衡成本并提高可用性。对比Codeberg和Tangled后，作者认为Radicle更优，并建议Zig包管理器支持Radicle，以实现更经济、高可用的源码分发。
延伸解读
集中式托管的隐性成本
文章指出，GitHub等集中式平台看似免费，但实际成本由平台方承担，最终可能通过限制或商业化转嫁给用户。作者认为，这种模式掩盖了真实成本，导致用户对免费服务的依赖，一旦平台政策变化或服务不稳定，项目构建就会受影响。这提醒开发者，选择托管平台时需考虑长期可用性和成本分担机制。
分叉与捆绑的局限
分叉和捆绑依赖虽能提高源码可用性，但存在效率问题：分叉需维护整个依赖树，捆绑则使代码难以被外部发现和复用。作者指出，这些方法无法自动作为镜像，导致冗余成本高。相比之下，Radicle的P2P播种机制让节点按需共享资源，成本分摊更合理，且保持代码可发现性。
Radicle的协作模式
Radicle将Issues和补丁存储在Git仓库中，通过CRDT同步，无需中央服务器。节点可配置播种策略，按兴趣共享资源，成本分摊更合理。这种设计让协作更去中心化，且每个节点可自主选择内容，避免集中式平台的审查或政策限制。
包索引的可持续性挑战
文章对比了集中式包索引（如PyPI）与分布式镜像（如Zig社区镜像）的成本效益。集中式索引依赖大公司赞助，存在可持续性风险；而分布式镜像通过冗余提供高可用性，成本更低。作者建议包管理器支持Radicle，以降低对集中式服务的依赖，实现更经济的源码分发。
Q&A
为什么作者认为GitHub等集中式代码托管平台不稳定？
作者指出，GitHub等集中式平台一旦出现故障，依赖这些平台的构建就会失败。例如，当GitHub或Codeberg宕机时，依赖它们的项目无法获取依赖，导致构建失败。此外，自托管的Forgejo实例虽然可用性较高，但存在永久性故障的风险，可能永久破坏项目。
Radicle如何实现去中心化的代码托管？
Radicle是一个点对点（P2P）网络，节点可以播种（seed）感兴趣的仓库。它支持将Issues和补丁存储在Git仓库中，通过CRDT同步，无需中央服务器。每个节点可以配置播种策略，按兴趣共享资源，从而分摊成本并提高可用性。
Radicle与Codeberg在成本效益和可用性上有何不同？
Radicle通过P2P网络让节点按兴趣播种，成本分摊更合理，且没有中央服务器，可用性更高。Codeberg是集中式平台，依赖捐赠，存在计划内和计划外停机，且资源消耗较大（如fork存储方式）。Radicle在成本效益和可用性上更优。
为什么作者认为Tangled不如Radicle适合源码托管？
Tangled基于atproto，是联邦制而非P2P，存在中央入口（如tangled.org），且不支持本地优先工作流（如离线查看Issues）。此外，Tangled的fork无法自动用作镜像，且其成本由VC和投资者承担，未来可能面临商业化压力。相比之下，Radicle的P2P设计更高效，且成本分摊更合理。
Zig包管理器如何支持Radicle？
作者建议Zig包管理器实现镜像支持（#14291），并希望rad CLI工具能提供命令将RID解析为HTTP URL，以便在build.zig.zon中配置镜像。这样，即使不运行Radicle节点，也能通过HTTP从多个节点获取源码，提高可用性。
作者对集中式包索引有何看法？
作者认为集中式包索引效率低下，因为维护高可用性成本高昂，且依赖大公司赞助。相比之下，分布式镜像（如Zig社区镜像）能以低成本提供高可用性。因此，作者建议设计更经济、去中心化的基础设施，而不是依赖大公司。
