回忆 Planet Source Code:在 GitHub 让代码分享变得便捷之前
摘要
作者回顾了 2000 年代初在 Planet Source Code 上分享代码片段的经历,并将那个时代与如今以 GitHub、包管理器和现代社区平台为核心的顺畅开发者生态进行了对比。
暂无内容
查看缓存全文
缓存时间: 2026/05/12 09:58
# 忆往昔:Planet Source Code,那个在 GitHub 让一切变得简单之前的代码分享圣地
原文链接:https://www.pietschsoft.com/post/2026/05/05/remembering-planet-source-code-sharing-code-before-github-made-it-easy
每隔一段时间,软件开发历程早期的某些事物就会重新浮现,带来潮水般的回忆。最近,我偶然发现了一个 PlanetSourceCode.com 的归档 GitHub 页面(https://github.com/Planet-Source-Code/PSCIndex/blob/master/ByAuthor/chris-pietschmann.md),上面列出了我在 20 多年前提交的一些旧代码。
看到自己的名字和那些 2002、2003 年的 Visual Basic 6 与早期 .NET 示例联系在一起,就像开启了一个有趣的小小时间胶囊。
那个页面列出了我以自己名义发布的一些提交,内容包括:
- 为 MSFlexGrid 控件添加复选框(https://github.com/Planet-Source-Code/chris-pietschmann-add-checkbox-to-msflexgrid-control__1-43129)
- VB6 打包与部署向导笔记(https://github.com/Planet-Source-Code/chris-pietschmann-vb6-package-and-deployment-wizard-notes__1-31528)
- 移动或调整大小时使窗体透明(https://github.com/Planet-Source-Code/chris-pietschmann-make-form-transparent-on-move-and-resize__10-2454)
- 文本框 — 只允许输入数字(https://github.com/Planet-Source-Code/chris-pietschmann-textbox-only-accept-numbers__10-1684)
- 使用 Winsock 进行 HTTP 文件下载(https://github.com/Planet-Source-Code/chris-pietschmann-http-file-download-using-winsock__1-44131)
这些都是小段代码。实用工具。示例。技巧。就是那种你刚解决完一个问题,心想可能以后别人也会遇到同样的问题,于是就把代码分享出来的东西。
现在回过头来看,最让我感慨的未必是代码本身。其中有一些在当时也许挺有意思。有一些可能写得很粗糙。还有一些或许会让今天的开发者觉得有点好笑。但真正突出的是这些提交所处的那个时代。
那是在 GitHub 出现之前。
那是在 Stack Overflow 出现之前。
那是在 NuGet、npm、现代包管理器、无所不在的博客、YouTube 教程、Discord 社区、GitHub Discussions 以及所有现在我们在寻找编程帮助时习以为常的渠道出现之前。
那是一个截然不同的时代。
## 在 GitHub 出现之前分享代码
今天,分享代码几乎毫无阻碍。你创建一个 GitHub 仓库,推送你的项目,添加 README,附上许可证,然后分享一个链接。别人可以克隆、复刻(fork)、开 issue、提交拉取请求(pull request)或加星标。搜索引擎会索引它。AI 工具可以分析它。文档可以自动生成。CI/CD 可以验证代码。包注册中心可以分发它。
但在那时,这一切都不寻常。
21 世纪初,如果你想分享代码,选择要少得多。你可以把它发在个人网站上。你可以把 ZIP 文件附在论坛帖子里。你可以把代码片段粘贴到留言板上。你可以通过邮件发给别人。或者,如果你想让它能被其他开发者发现,你就会把它提交到像 Planet Source Code 这样的网站上。
Planet Source Code 是当时非常重要的开发者社区网站之一。它是一个程序员可以上传代码片段、小型应用程序、控件、示例和教程的地方。其他开发者可以浏览分类,下载代码,给提交打分,并留下评论。
对我们许多人来说,这是寻找实现某个功能实用示例的最佳途径之一。
当然,也有书籍。有 MSDN 文章。有邮件列表和论坛。但很多日常编程知识都存在于共享的示例中。你搜索你正在尝试构建的东西,找到别人的示例,下载下来,在 Visual Basic 中打开它,然后开始通过阅读代码来学习。
那就是当时的工作流程。它从来不是你想要的完整解决方案,但你会把多个代码片段拼凑在一起,进行故障排查,最后找出完成任务的解决方案。
## Visual Basic 时代
我在存档中列出的几个提交与 Visual Basic 6 相关,这在那个时期非常合理。VB6 无处不在。它易于上手,生产效率高,被广泛用于构建 Windows 桌面应用程序。如果你在 Windows 上构建商业应用程序,那么里头很可能就有 VB6 的身影。
我的一个旧提交标题是**为 MSFlexGrid 控件添加复选框**。光是这一个例子,就带回了整整一类的记忆。
MSFlexGrid 控件曾是 VB6 应用中用来显示表格数据的常用控件。它很有用,但和那个时代的许多控件一样,它并不总是能开箱即用地完全满足你的需求。因此,开发者们会想方设法去扩展它,绕过它的限制,让它表现得更接近他们想要构建的应用程序。
为网格添加复选框行为是一个非常实际的问题。用户想要选择行。商业应用需要将记录标记为包含或排除。如果能有一个原生的复选框列会很方便,但如果控件没有按你需要的方式提供,你就得自己构建它。
这是 VB6 开发中一个非常普遍的模式:拿你现有控件,让它们按你的意愿行事,使应用程序能够工作。
另一个提交是**使用 Winsock 进行 HTTP 文件下载**。这个也非常能代表那个时代。今天,如果你想通过 HTTP 下载一个文件,用现代库几行代码就能完成。在 .NET 中,你可能会用 `HttpClient`。在 JavaScript 中,你可能会用 `fetch`。在 Python 中,可能用 `requests`。这在现在是再平常不过的事。
但在那时,根据你使用的语言、运行时和环境,你可能需要在更低的层级上工作。直接使用 Winsock 意味着要更紧密地处理网络通信。你得自己发送请求、读取响应、解析头部并管理数据。
用今天的标准看,那是最简单的文件下载方式吗?很可能不是。但它很有教育意义。它迫使你去理解底层究竟发生了什么。
这正是许多老旧编程示例的一大优点。它们并不总是打磨好的库。它们通常是对事物工作原理的演示。
## 早期 .NET 时代
存档中还包含两三个来自早期 .NET 时期的提交:**移动或调整大小时使窗体透明**和**文本框 — 只允许输入数字**。2002 年那会儿,.NET Framework 真的还处于非常早期的阶段。
那些标题立刻让我回想起 .NET 刚出现时令人兴奋的日子。开发者们正从 VB6 转向 VB.NET 或 C#。Windows Forms 既新颖又熟悉。它感觉像是很多我们早已熟悉的桌面开发技术的现代化版本,但背后有一个强大得多的框架支持。
有很多东西要学。
.NET Framework 引入了一种不同的应用开发思维方式。命名空间、程序集、托管代码、垃圾回收、元数据、反射、事件、委托、继承以及更丰富的基类库,这些都成了日常词汇的一部分。
对于从 VB6 过来的开发者,这既令人兴奋又具有颠覆性。
小代码示例在这场转变中扮演了巨大角色。你可能不需要一整章书来学习如何在文本框中限制输入。你需要的是一个清晰的示例。如何处理按键事件?如何只允许数字但阻止字母?如何仍然允许退格键?如何考虑边缘情况?
这类实用知识通过社区代码网站传播开来。
同样的情况也适用于 UI 效果,比如让窗体在移动或调整大小时变透明。这不一定是关键任务功能,但正是这种微小的交互让应用感觉更具动态性。开发者们正在试验 Windows Forms 能做到什么,能把它推到多远,如何让桌面应用展现不同外观和行为。
很多学习是通过实验完成的。
## 在 Stack Overflow 改变开发者问答模式之前
在 Stack Overflow 出现之前,获取编程帮助的方式有多么不同,这一点再怎么强调也不为过。
今天,当开发者遇到问题时,他们搜索网络,通常能找到 Stack Overflow 答案、GitHub issue、官方文档页面、博客文章或 AI 生成的解释。海量的、被索引的开发者知识几乎可以即时获得。
但在 21 世纪初,网络要小得多,组织性也差得多。
搜索引擎当然存在,但要找到正确答案可能需要花时间。搜索结果不稳定。文档常常不完整或难以浏览。许多答案存在于论坛帖子、邮件列表存档、Usenet 帖子、个人网站或代码分享门户中。
你必须深挖才行。
Planet Source Code 之所以有帮助,是因为它围绕代码进行了组织。你可以按语言和分类浏览。你可以搜索示例。你可以看到评分。你可以下载完整的项目,而不仅仅是在论坛回复中读到几行代码。
这很重要。
一个完整可用的示例往往比一段描述更有价值。当你能打开一个项目,运行它,单步调试它,并修改它时,你的学习方式是不同的。你不只是复制代码。你是在探索行为。
这种动手学习的方式塑造了那个时代的许多开发者。
开源当然早在 GitHub 之前就存在了。有大型的开源项目、社区、邮件列表、源代码仓库和协作模式。但对许多日常开发者,特别是那些使用像 VB6 这样 Windows 桌面工具的人来说,随性的代码分享并没有像现在这样标准化的感觉。
GitHub 改变了代码的社交机制。
它给了开发者一个共同的地方来托管项目、跟踪变更、报告问题、贡献改进,并建立一份公开的作品集。它让“你的代码默认可以是可见的、可复刻的、可协作的”这一观念正常化了。
Planet Source Code 不是 GitHub。它更像一个代码画廊或社区档案馆。你上传一个 ZIP 文件或源代码提交。人们下载它,给它打分,也许还会评论。它没有围绕版本历史、拉取请求、分支、问题或持续改进的相同工作流程。
但它起到了一个重要作用。
它让代码变得可见。
它为个人开发者提供了一个贡献有用之物的空间,哪怕只是一小段代码或演示。它让某人得以说:“我搞明白了这个。这是我是怎么做的。”
这听起来可能很简单,但这正是健康开发者社区背后的核心理念之一。
## 博客的早期时代
那也差不多是博客的早期时代。
个人博客正成为开发者分享所学内容的一种方式。开发者们不再只发表正式文章或在论坛发帖,而是可以直接在自己的站点上写作。博客成为了一个记录发现、解释解决方案、分享观点并树立职业形象的地方。
这是一个巨大的转变。
个人博客让你对自己的写作拥有所有权,这是论坛帖子或代码提交所不具备的。你可以整理自己的想法,写教程,发布笔记,并随着时间建立归档。那个时代许多开发者博客都略显粗糙,但它们非常真实。它们是由那些在真实项目中解决真实问题的人写的。
从很多方面来说,代码分享网站和博客是相辅相成的。
一篇博客文章可以解释背景:你遇到了什么问题,你尝试了哪些方法,最终什么奏效了,以及有哪些需要注意的地方。而代码分享网站可以托管实际的示例项目供他人下载。
今天,我们可能会把所有这些整合到一个带 README 的 GitHub 仓库里,或许再加一篇博客文章,也可能还有一个发布包。那时则要分散得多。你在一个地方分享代码,在别处写相关文章,并希望人们能够找到它们。
不过,它还是奏效了。
那时的网络虽小,但充满人情味。
## 回望旧代码
回看几十年前写的代码,总会有种奇怪的感觉。
你的一部分想要批评它。你能看到现在会以不同方式处理的地方。你注意到命名选择、结构、格式、假设和模式,这些都反映了你当时作为开发者的水平。你可能甚至会有点难为情。
这很正常。
但旧代码也是一份成长的记录。每个开发者都有一串在学习过程中构建的东西。小型实用工具。实验项目。半成品想法。演示。变通方案。被复制、修改、改进并最终理解的代码片段。
那些旧的 Planet Source Code 提交就是我成长轨迹的一部分。
它们代表了我曾解决的问题,我当时使用的技术,以及那个时代开发者分享知识的方式。它们也提醒我,为社区做贡献并不总是意味着要构建一个大型框架或维护一个重要的开源项目。
有时,它意味着为一个微小的问题分享一个小小的解决方案。
而有时,20 年后,那个小小的解决方案仍然静静地躺在某个档案库里,默默地提醒你,你从哪里起步。
## 小贡献的价值
现在我更加体会到的一点是小贡献的价值。
在现代软件开发中,人们很容易从大项目的角度来考虑开源:流行的框架、有成千上万星标的库、云原生工具、庞大的生态系统和广泛使用的软件包。这些固然重要,但它们不是故事的全部。
小示例同样重要。
一个展示如何向网格添加复选框的示例可以帮助某人完成一个商业应用程序。一个关于打包和部署问题的笔记可以为某人节省数小时的挫折感。一个文本框输入示例可以帮助初学者理解事件和验证。一个 Winsock 文件下载演示可以教会某人 HTTP 在较低层面是如何工作的。
并不是每个贡献都需要宏大。
有时候,你能发布的最有用的东西就是你刚刚搞明白的事情。
这在 2002 年是正确的,在今天依然正确。
不同之处在于,现在我们有了更好的工具来分享、保存和改进这些贡献。GitHub 仓库可以演进。Issues 可以捕获问题。拉取请求可以修复错误。Discussions 可以添加背景信息。包管理器可以分发更新。文档站点可以自动生成。
但动机是一样的:帮助后来人。
## 保存至关重要
我也很感激像这样的档案库的存在。
最初的 Planet Source Code 网站已不再是开发者们分享和发现代码的核心场所。网络已向前发展。技术已经改变。社区已经迁移。但保存在 GitHub 上的这些代码和索引页面,提供了一窥那个早期时代的机会。
这种保存至关重要,因为软件历史往往是脆弱的。
旧网站消失。域名到期。文件下载失效。论坛数据库离线。个人站点消失。曾经帮助过成千上万人的代码可能在一夜之间变得无法访问。
当旧代码被归档时,它给予我们的不仅仅是怀旧。它给了我们背景。
它展示了开发者在构建什么,他们解决什么问题,他们使用什么工具,以及知识如何在社区中流动。它也提醒我们,今天的最佳实践是建立在数十年的实验、分享和迭代之上的。
具体的代码可能已经过时。但代码背后的精神不会。
## 那是一个不同的时代
当我回想起在 Planet Source Code 上发布代码的时候,我记忆中的网络感觉更像是手工打造的。开发者社区更小、更分散。你通过搜索、下载、实验、搞砸、再尝试来学习。
那时的自动化更少。润色更少。
相似文章
GitHub之前
一篇关于GitHub之前开源开发历史的反思文章,讨论了作者在自托管基础设施、SourceForge以及GitHub带来的文化转变方面的个人经历。
应对大型代码托管平台碎片化
本文探讨了项目离开GitHub导致的代码仓库碎片化问题,介绍了一种跨平台统一git活动热力图的工具,并讨论了抵御AI生成垃圾贡献的信任系统。
@karpathy:对 GitHub Gist 的评论质量之高感到惊讶。更加实用、见解深刻、富有建设性,而且 AI 内容少得多……
Andrej Karpathy 指出,GitHub Gist 的评论质量明显优于其他平台,讨论更具建设性且 AI 生成内容较少,并推测了背后的原因。
@karpathy:哇,这条推文彻底火了!我想在“idea file”中分享这篇推文的优化版本。Th…
在 LLM agents 时代,Andrej Karpathy 阐述了共享思路而非代码的理念,提出了“idea file”格式,强调核心概念本身比具体实现更具价值。
GitHub 源代码泄露 - TeamPCP 声称访问了内部源代码
TeamPCP 声称访问了 GitHub 的内部源代码,表明这个流行的开发平台发生了重大安全漏洞。