在威斯康星大学麦迪逊分校开始攻读研究生之前，我从未听说过开源。然而，任何历史悠久的计算机科学系都使用开源软件来支持他们的基础设施。部门系统管理员总是会在我们的桌面上安装 Linux 的一个或另一个变体，而且许多学术程序都是开源的。我或多或少地接受了我所发现的整个情况。
当我加入合作错误隔离（CBI）项目时，开源对我来说变得更加重要。该项目使用开源软件作为自动化错误查找的测试对象。我在该项目的导师 Ben Liblit 教授写了一篇短文，开源试验场，描述了他的经验并评估了开源软件对其错误查找项目的适用性。虽然这篇论文发表于 2005 年，但他的许多观察结果在今天仍然适用。
一旦我开始思考开源软件，特别是当我开始研究一些单独的应用程序时，我感到沮丧地发现其中一些软件编写得很糟糕，因此漏洞百出。天真地，我假设任何人都选择发布的任何软件至少都应该像我自己，一个仅仅是研究生的软件一样精心制作。然后，就像现在一样，人们会使用软件，只要它足够好地满足他们的目的，无论代码看起来如何，即使代码暴露给所有人看。
后来，我致力于扩展 Chromium 项目中的一些宏，以收集 CBI 类型的数据。这些扩展从未打算以任何永久方式合并到项目中；你肯定不会在那里找到它们。Chromium 项目是一个非常严谨的项目，即使我编写的代码永远不会成为项目的一部分，我的补丁也必须符合全面而详细的规范，并在被接受之前经过彻底审查。
我的个人电脑是一台 Mac，但正如大家所知，这只是一个底层 Unix 系统，所以我下载、安装并经常使用许多开源应用程序。我看到了一些应用程序，例如 LyX，变得成熟。在我了解 LyX 的这段时间里，我对它的个人评价已经从“毫无用处”演变为“到目前为止，最好的选择”。我仍然想了解像 LyX 这样雄心勃勃的开源项目是如何度过其早期、脆弱的年代的。
当我离开 CBI 项目时，我已经以某种方式与各种开源项目进行了交互，其中一些项目显然是从混乱中出现的，而另一些项目则是从非常严谨的开发过程中出现的，有些项目令人印象深刻，而另一些则不然。毕业后，我担任了一系列教学职位，并退回到我过去的方式。我很感激这些软件的存在，经常使用它，偶尔贡献一些错误报告，并且除此之外很少考虑它。偶尔，我会想我应该更多地了解这种开源现象以及它是如何维持自身的，但我总是太忙了。
当我决定离开学术界并进入工业界时，我的机会来了。我以前没有在工业界编程，但我已经在 CBI 项目中用多种语言为多种不同目的完成了大量的开发工作。直到去年夏天我实习于Yocto 项目，但我对开源开发机制或可能地理上分布的团队内的沟通一无所知。我了解了每个人不可避免地会收到的海量电子邮件，以及 IRC 的实用性。通过那次实习，我熟练掌握了 git。
自从我于 2013 年 9 月加入 Red Hat 以来，我一直在更多地了解开发周期及其要求，尽管由于时间不长，我还没有完成一个完整的周期。自从我成为开源贡献者以来，我开始将开源视为一种美德，并且更倾向于寻找各种应用程序的开源替代方案。我也更倾向于发布一些位于错误食物链中较高位置的错误报告——例如，在 Python 标准库中，而不是在一些用 Python 编写的应用程序中。我更多地将问题视为开源协作的机会，而不是像以前那样。我从未梦想过开源会如此成功，只希望它的成功会继续增长。
在 Red Hat，我几乎所有的时间都花在安装程序上，主要关注其存储组件 blivet。安装程序 Anaconda 保证在您做出所有选择并按下大红色按钮之前，它实际上不会对您的磁盘做任何事情；此时它应该实现您的所有选择而不会崩溃。这是一个难以解决的问题，因为 Anaconda 依赖的不同工具可能对它们可以做什么有令人惊讶的限制，并且您做出的不同选择之间存在令人惊讶的交互。在允许用户最大的灵活性和同时保证他们所做的选择可以执行之间总是存在紧张关系。
Blivet，存储组件，负责处理设备和设备格式化。它必须为各种不同的文件系统、各种不同的设备和各种不同的架构提供统一的接口。这就像设备驱动程序问题，其中单个设备可能非常不同，但驱动程序必须都呈现相同的应用程序编程接口 (API)。例如，文件系统彼此之间可能非常不同，因为文件系统设计人员在设计文件系统时并没有将安装程序的问题放在首位。此外，大多数文件系统不提供 API；blivet 必须为每个文件系统的命令行界面 (CLI) 生成必要的命令，这可能是一个移动的目标。
虽然 Anaconda 本身是一个相当大的应用程序，而 blivet 是一个相当大的库，但就其本质而言，它们必须依赖于其他重要的应用程序，例如软件包安装程序和文件系统实用程序，以协调这些各种应用程序的操作并查询它们以发现相关的系统状态。通常，这些交互变得更加脆弱，因为必须通过其 CLI 调用应用程序，并且必须通过读取和解析输出进行查询，而输出的格式可能会随着下一次更新而更改。
像 Anaconda 这样的安装程序当然是一个必须依赖其他应用程序的应用程序的极端例子。然而，自动化是今天的常态而不是例外，许多应用程序，特别是 Anaconda 和 blivet 依赖的那种，可能希望像人手动调用它们一样经常被自动调用。它们越成功，情况就越有可能如此。
我认为，如果更多的开源开发人员将 API 和相关绑定视为主要，而将 CLI 视为次要，那么整个开源社区都将受益。理想情况下，应用程序从一开始就应该设计有一个定义良好的 API、一组随着 API 发展的绑定，以及一个（如果必要的话）使用绑定用脚本语言定义的 CLI。这不仅会使应用程序适合自动化，而且可能还会带来额外的好处，即使 API 更好地定义并且更健壮。
评论已关闭。