文章回顾了GitHub成为主流开源平台前，作者使用SourceForge、自建Trac系统和Bitbucket的经历，强调了GitHub对其开源生涯的重要性——不仅托管项目，更成为建立专业关系和友谊的社交平台。

GitHub之前的开源世界：回忆与反思

作者：Armin Ronacher
发布日期：2026年4月28日

开源托管平台的演变

在GitHub成为主流之前，开源项目托管经历了多个阶段： - 早期阶段：作者最初使用自托管的Trac和Subversion系统管理项目，后来迁移到SourceForge和Bitbucket - GitHub时代：GitHub逐渐成为开源社区的核心平台，不仅托管代码，还成为开发者社交和协作的中心

前GitHub时代的开源特点

1. 规模较小但更稳定：

   • 项目数量有限，维护者群体相对固定
   • 依赖关系建立需要更谨慎的评估
   • 项目通常拥有完整的基础设施（网站、邮件列表、发布流程）

2. 自主运维文化：

   • 开发者需要自行搭建和维护项目托管平台
   • 作者曾与Georg共同运营Pocoo社区，分担服务器和Subversion维护成本

GitHub的贡献与问题

积极影响： - 大幅降低了项目创建和发现的难度 - 提供了统一的问题跟踪、PR、CI等工具 - 成为事实上的开源项目档案馆

当前困境： - 产品方向不稳定（Copilot AI等功能的争议） - 领导力不明确 - 部分知名项目开始迁移（如Zig、Ghostty等）

去中心化的挑战与机遇

随着GitHub影响力下降，开源社区可能回归多平台并存的模式： - 优势：恢复项目自主性，减少对单一公司的依赖 - 风险：可能重现"链接失效"问题，丢失项目历史和社会化协作记录

对未来的建议

作者呼吁建立： 1. 公共资助的开源软件档案馆 2. 更完善的项目迁移和镜像机制 3. 能够保存代码之外的项目上下文（讨论、安全公告等）的系统

结语

GitHub开创了开源历史的重要篇章，但其中心化模式可能正在走向终结。未来的开源生态需要从GitHub的成功和不足中吸取经验，在保持分布式优势的同时，解决项目持久性和可发现性的挑战。

（注：本文保留了作者的核心观点和关键论据，删减了部分个人网站导航、版权声明等非主要内容）

以下是评论内容的总结：

1. 对Trac的正面评价

   • simonw认为Trac在开源项目初期设置中非常有用，并提到Django至今仍在使用Trac。
     引用：
     "A absolutely loved Trac. Getting a Trac setup as step 1 in starting a new open source project was just an unbelievable amount of friction."
     "Django is still running on Trac today, and has been for more than 20 years now."

2. 对GitHub历史作用的争议

   • einpoklum反驳了GitHub出现前开源世界规模较小的观点，认为依赖的FOSS项目大多不来自GitHub。
     引用：
     "Most FOSS I realistically depend on I don't obtain from GitHub actually."
     "Post author is just thinking of the names they knew as though those were everybody."

3. 对GitHub集中化存档的批评

   • Lammy认为GitHub的集中化存档削弱了集体存档能力，并提到DMCA删除问题。
     引用：
     "Having something that's centralized but helpful-99%-of-the-time atrophies our collective archival skills."
     "When a project on GitHub gets DMCAed it takes everyones' forks with it too."

4. 对SourceForge和CodePlex的回忆

   • MrAlex94提到SourceForge曾帮助推广项目，但后来因广告和恶意软件问题衰落，并回忆了CodePlex的使用体验。
     引用：
     "They use to promote projects they liked and ended up putting Waterfox on their front page a few times."
     "Felt like I was the only one using it at the time!"

5. 对分散化版本控制的建议

   • ctoth和flaburgan提出分散化版本控制的方案，如基于Git的Bug跟踪或GitLab集成ActivityPub。
     引用：
     "Then it's BYOR -- bring your own renderer."
     "What we need is gitlab to finally integrate ActiviyPub."

6. 对GitHub现状的辩护

   • selectively认为GitHub功能完善，批评文章观点空洞。
     引用：
     "GitHub is fine. The blog post gestures vaguely at nothing."
     "It's just nonsense, brain rot."

7. 对Fossil的推崇

   • wps认为Fossil比Git更适合普通项目，因其内置工具和易用性。
     引用：
     "Fossil’s internal tools (wiki, forum, tickets, etc) are just so useful to have versioned with your code in one file."
     "It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch."