【Cohort1】关于捐赠Mega的提案

1. 项目简介

Mega 是一个代码管理的 Monorepo 引擎 ，其灵感来源于 Google 内部的 Piper 系统。Mega 的核心目标是：

• 为管理大规模代码库提供一个兼容 Git 的高性能 Monorepo 解决方案3 • 通过重构 Git 底层协议并结合去中心化技术 构建一个去中心化、分布式的开源代码协作网络和生态 。 • 将企业级 Monorepo 引擎精简为个人代码管理应用，通过去中心化协议连接这些应用，从而构建协作网络。

项目官网https://gitmega.dev 代码仓库https://github.com/web3infra-foundation/mega 法律实体Web3 Infrastructure Foundation (香港)

2. 申请资金：20000U

3. 解决的公共问题

Mega 致力于解决开源代码协作中的两大核心问题： • 中心化垄断与地缘政治风险：当前开源代码高度集中在少数中心化托管平台（如 GitHub）16。这导致开源协作受到地缘政治、服务封禁和中心化实体控制的风险影响。Mega 通过构建去中心化网络，保障开源项目抗审查的可用性。 • Monorepo 性能与扩展性：传统 Git 在处理大规模 Monorepo（单体仓库）时存在性能瓶颈。Mega 从底层重写 Git 协议和存储层，为 Monorepo 提供可扩展、高性能的基础设施。

4. 竞品分析

GitHub/GitLab 中心化托管平台。Mega 是去中心化的代码协作网络，旨在打破中心化垄断。Radicle Radicle 在 Git 之上使用过滤器插件（git-filter）实现去中心化，核心 Git 机制未改动 20。Mega 从底层重写 Git 的存储和协议，提供数据库存储、Delta 压缩优化、智能加速等多项增强功能，具备更高的性能和扩展性。 传统 Monorepo 工具通常面向企业级部署。Mega 致力于将 Monorepo 引擎精简为个人开发者应用，并通过 P2P 网络连接，构建面向个人的去中心化协作生态。

5. 团队成员

• 马全一 (Quanyi Ma)：负责项目开发和管理。目前就职于华为技术有限公司，任开源运营总监。 • 王永和：负责项目推广和布道。目前全职从事此工作。

7 GCC权益

1）配合GCC的捐赠宣发，包括但不限于接受访谈、社媒内容制作配合、社媒转发、活动参与等

2）在github仓库和官网将 GCC 列为支持方之一

3）如果项目产生盈利，计划通过 GCC 或类似机制将一定比例的收益回馈给公共物品，如支持在校学生参与开源项目等

4）为GCC推荐开源项目，推动GCC与国内开源组织的合作

8. 里程碑和路线图

Milestone 0- 投票通过即解锁20% 4000u

Milestone1 - 解锁20% 4000u

预计解锁日期：2026-05-31

• 完成面向个人开发者的 Alpha 版 App，Alpha 版本需证明其“可用性”。核心功能包括：

• Git 兼容
• Monorepo 挂载：FUSE 文件系统组件成功挂载并访问 Monorepo 内容
• P2P URL 支持

• 建立第一个 Relay 节点用于去中心化网络测试，验证 QUIC P2P 协议栈 和 Gossip 层的基本功能实现，证明网络可以启动和传输数据

Milestone2 - 解锁30% 6000u

预计解锁日期：2026-09-30

• 完成面向个人开发者的 Beta 版 App
  • 实现绝大部分的 Git 核心命令在本地 Monorepo 上的兼容运行
  • 降低 Critical/Major Bug 数量，测试用户体验基本无碍。
• 构建小规模测试网络
  • 成功部署并持续运行 5个独立的 Relay 节点，构建一个小规模的 Mesh 网络
  • 持续运行 30天的 7/24数据同步测试，数据同步成功率高

Milestone3-解锁30% 6000u

预计解锁日期：2026-12-31

• 完成面向个人开发者版本 0.1.0 发布并稳定实现连续3个月每个月 100+ 月活
• 在 0.1.0 版本发布后 3 个月内，P2P 网络中至少有 10 - 20 个独立、持续在线的节点（不包括自身维护的 Relay 节点）
• 在香港、新加坡等地召开至少2场Meetup 进行推广，场均参与人数≥30人

附：投委打分及意见

| 解决问题的公共性 | 赛道潜力 | 对华语区（潜在）贡献 | 执行能力与团队 | 可持续性 | 平均分 | | --- | --- | --- | --- | --- | --- | | | | | | | 3.15 | | 3 | 4 | 3 | 3 | 4 | 3.4 | | 4 | 3 | 3 | 4 | 3 | 3.4 | | 3 | 3 | 3 | 4 | 3 | 3.2 | | 4 | 2 | 2 | 2 | 3 | 2.6 | | | | | | | | | | | | | | |

附：Demo Day 记录

Q1：这个项目是给大公司使用的吗？小型项目或个人开发者能用得上吗？ • 回答： Mega 整体方向分为两层。面向企业的部分提供大型 Monorepo 的企业级能力，但本次申请的项目重点是给个人开发者打造一个真正去中心化、可直接运行在本地的协作系统。它更像是 Radicle 的替代方案，但底层能力更强、性能更高，专注于个人开发者的应用场景。 Q2：Mega 目前是否得到公司资源支持？是否有其他资金来源？ • 回答： Mega 所有去中心化相关的研发都挂在 Web3 Infra Foundation (香港) 下，与公司主营业务无关，也没有商业化收入支撑。目前除中科院软件所的开源实习生之外，没有其他资金来源。本次资助是推进项目必要且唯一的资源来源，主要用于雇佣前端与全职开发者。 Q3：Mega 与 Radical 的本质区别是什么？为何需要重新做？ • 回答： Radicle 的模式是在 Git 之上加过滤器插件（git-filter），核心 Git 机制没有改动，可扩展性有限。 • Mega 从底层重写 Git：重新实现了存储协议、优化了 Delta 和 Packfile、提供数据库级别的对象存储能力、允许从多节点获取某个对象（Radical 做不到）。 • 这意味着 Mega 不仅能完全兼容 Git，还能**“重新定义 Git 体验”，尤其在大规模仓库、弱网环境、分布式协作下有巨大性能优势。 Q4：Radical 是点对点传输，那 Mega 的 P2P 能做到什么额外能力？ • 回答： Radical 的点对点传输依赖双方在线。Mega 可以做到： ◦ 分片对象存在不同节点。 ◦ 即便原始节点下线，也能从其他节点重组出完整仓库**（网络本身是“可恢复的”）。 ◦ 智能路由 + Gossip + QUIC 多路复用。 Q5：Mega 此前两个版本为什么没有继续推进？这次方案为何更可行？ • 回答： ◦ 纯 DHT 方案在中国网络环境实际穿透效果不佳。 ◦ ZTM 方案编译、跨平台、C++ 维护成本太高。 ◦ 本次采用 Rust QUIC + Gossip 的方案：完全可控、底层依赖统一、与 Mega 现有的 Rust Git 内核深度整合。理论和工程成熟度都明显更高，是最稳定和可落地的版本。 Q6：Mega 最终交付的形态是什么？能实际怎么看到？ • 回答： 最终产出包括： ◦ 完整可运行的 Monorepo 引擎（面向个人开发者）。 ◦ 本地 GUI 客户端（通过资助雇佣前端打造）。 ◦ 基于 QUIC 的去中心化协作网络和 Relay 节点开源。 ◦ CLI 工具与 Git 完全兼容，以及将仓库 mount 成本机文件系统的 FUSE 层。 ◦ 最终将发布 v0.1.0，并在香港与新加坡举办 Meetup 推广。 Q7：这个方向有哪些实际应用场景？是否会有人真正使用？ • 回答： 核心使用场景来自两类用户： ◦ 深度开源开发者：不希望依赖 GitHub/GitLab。 ◦ Web3 / 去中心化生态：需要真正无需中心节点的协作方式。 • Mega 的长期愿景是让“开源协作”不必依赖任何中心平台，所有人都可用自己的设备参与协作，是对开源生态至关重要的基础设施。

PPT链接：

Mega for GCC Cohort1 Demo Day - 20251113.pdf

投票规则

1. 共有9名投委，投票率超过50%(>4人），赞成/ 总票数 ≥2/3视为通过
2. 投委可以继续选择是否增减金额（+10%，+5%，0，-5%，-10%），最终增减比例将直接加总