不难想出十几个不同的理由来解释为什么开源开发的兴起一直是软件和硬件行业的分水岭事件。我们所有人都可以借助 jQuery、Bootstrap 和 Apache 的力量，更快地构建新的 Web 应用程序。像 Ruby、PHP 和 Python 这样的语言为互联网提供动力，而像 Linux 和 FreeBSD 这样的操作系统为成千上万的公司和服务奠定了基础。
但是，开源不仅仅关乎我们可以免费使用的工具，还关乎开发者社区，他们将帮助支持疯狂的新想法，并给它们一个蓬勃发展、成长和改变世界的机会；这些想法在闭源世界中永远不会出现。
我最喜欢的例子是一个与我息息相关的工具，因为它让我在开发世界中的小众领域再次感到兴奋：Git。在 Git 之前，版本控制领域已经变得陈旧；动荡的 90 年代让位于 21 世纪版本控制超级大国之间的冷战。Git 带回了关于版本控制工作流程的辩论！ 甚至仅仅是人们再次关心版本控制工具就很有趣了。对于版本控制爱好者来说，这简直是天堂。
Git 是一款出色的软件，它重新定义了我们进行开源开发以及更广泛的软件开发的方式。当然，在此之前已经有其他分布式版本控制工具，但在我在这个行业工作期间，没有什么能像它这样戏剧性地改变我们版本控制和共享工作的方式。
但这有点疯狂。其大部分功能和灵活性都由一个核心的版本化文件系统提供，该文件系统可以以多种不同的方式使用。在核心引擎之上构建了数十个命令，每个命令都有数十个标志，所有这些命令都以有用（如果偶尔不可预测）的方式操作该系统。其中许多命令是独立演变的，由不同的开发人员编写。因此，它们可能对类似问题采取非常不同的方法。
Git 也是由一个非常习惯使用命令行的社区编写的。他们习惯于在没有护栏的环境中工作：任何曾经不小心在错误的地方运行过“rm -rf *”的人都会告诉你，这是一个你只会犯一次的错误。 这样做的一个副作用是，Git 的护栏不如用户可能从版本控制系统期望的那么多。
我个人最喜欢的一个例子是 reflog。如果您不熟悉 Git，它可以大致描述为更改了您的版本化文件的版本控制操作的本地日志。当您运行错误的命令并且表面上丢失了所有工作时，reflog 是您的救星。Git 最棒的地方在于它永远不会消失，您只需要知道在哪里查找。
现在想象一下，Git 是在一个典型的闭源公司中创建的世界。想象一下董事会会议，会上揭示了
董事会： “这是一项了不起的技术！这将改变一切。您看到任何挑战吗？”
开发人员： “嗯，我们确实发现有时我们会不小心删除当前分支并丢失所有工作……”
董事会： “嗯，这当然只是一个 bug？我想您会添加一个护栏来防止数据丢失吧？”
开发人员： “这真的不是一个 bug。我们只需要学习如何更好地使用该工具。但是，我们有一个解决方案可以缓解意外数据丢失。”
董事会： “谢天谢地！那是什么？”
开发人员： “我们采用了更通用的解决方案。我们放入了一个名为 reflog 的单独版本控制系统，这样我们就可以对您的版本控制操作进行版本控制。如果您删除了分支，您只需扫描 reflog 以查找相应的 SHA 并恢复它即可！”
董事会慢慢地退出了房间。
正如 Steve Losh 的 Git Koans 等文章所展示的那样，Git 有很多古怪之处。我个人很难想象一家公司会构建和销售像今天这样设计的 Git。对于新用户来说，不一致之处和陷阱太多了。 但是，这些不一致之处和陷阱是作为强大而灵活的工具的自然副作用。没有这些粗糙边缘的 Git 不一定是我们都认识和喜爱的 Git。
好消息是，开源开发社区在那里培育和支持它，添加了很棒的功能（如 bisect），并提供了大量的优秀文档和教程来教新手入门。这种支持帮助一块璞玉几乎成为世界上最流行的版本控制系统。
我们都有一些疯狂的想法，我们一直在思考，但不确定该如何处理。将这些想法变为现实可能很可怕——失败很糟糕。花你的周末构建一些最终没有人关注的东西可能会令人沮丧。好消息是，如果您的想法具有一些潜力，那么会有一个社区愿意帮助您让您疯狂的钻石闪耀光芒。谁知道呢，您一直在脑海中盘旋的周末项目也可能彻底改变软件开发。
4 条评论