开源更多的是关于过程而非许可

图片来源

Opensource.com

“开源”和“许可”在功能上几乎成为同义词，这证明了开源促进会 (OSI) 针对开源软件的品牌推广活动的成功。在人们对开源软件的认知程度上，它是根据许可发布的源代码，允许任何人查看软件程序的“皇冠上的宝石”，而不是隐藏其内部机制的不透明二进制文件或黑盒。

自从 15 年多前埃里克·雷蒙德将这个概念推向公众意识以来，这个老生常谈的比喻一直主导着主流对开源软件的看法。但是，将以前专有的代码库转换为开源项目，会让人认真质疑之前关于代码和许可的任何假设。正是这种尝试让人体会到过程和治理的价值。在亲眼目睹了从封闭到开放的转变之后，我确信，选择以专有项目还是开源项目发布代码，会导致最终产品的根本变化，这种分歧非常难以逆转。

在大多数人看来，软件许可是发布开源软件最重要的方面，但在我看来，许可属于用户体验、工作流程以及集成到现有数据中心技术之下的范畴。在“已知”（许可）与实际现实（用户工作流程）之间的这种差异，在负责将其专有产品转变为开源项目的开发团队恐惧的眼神中体现得最为明显。事实上，工程师选择的开发方法直接影响着所生产的软件类型。如果从一开始就选择了开源开发模型，人们可以合理地确信，最终产品将具有相对的可移植性，并将插入到最常用的环境中。如果选择专有模型，开发人员很容易走捷径，从而导致短期收益和长期痛苦——而这正是经常发生的情况。

在人们思考这些事情的程度上，普遍的看法是，这种改变涉及简单的搜索和替换，或许是删除第三方软件，上传到公共存储库，然后就完成了！在 GitHub 上 Fork 我！但是，没有什么比这更远离真相了。大多数人对软件的误解在于，它更多的是关于过程、控制和管理，而不是软件许可。正如我在《它从未关于创新》中论证的那样，开源软件成功的关键不在于对创新的渴望，而在于开源生态系统中的所有参与者都处于公平的竞争环境中。客户、外部开发人员、白嫖者——他们都有一席之地，并且可以通过利用社区资产来对项目施加影响，这些资产是他们通过长期以各种方式贡献而积累起来的。这与专有开发模型形成鲜明对比，在专有开发模型中，开发人员基本上可以为所欲为，只要他们创建的最终产品符合产品管理部门提供的产品需求文档 (PRD) 的期望即可。

这就是开源开发和专有开发之间差异变得鲜明的地方。伴随开源开发的开放过程将有助于确保软件很可能集成到任何给定的环境中，并且通常可以避免一些不良习惯。这两件事是息息相关的。例如，专有软件开发通常会导致软件本质上是单体式的，对系统软件的依赖性最小，并且通常捆绑了自己的库和工具集。这使开发人员可以自由地为所欲为，经常使用特定版本的库，重新发明各种轮子，并且通常会偏离创建在更广泛的上下文中良好运行的软件的道路。

相比之下，开源软件开发人员没有这种奢侈。从第一天起，他们的用户就要求极致的灵活性、集成性以及符合标准数据中心系统实践。这意味着尽可能地利用现有工具和库，并将您的软件将成为更大的数据中心机器中的一个齿轮的想法融入到流程中。请注意，我没有提到开源开发更快或更具创新性，尽管它可能是。一方面，开发人员喜欢他们可以完全控制最终产品，而不必处理令人讨厌的事情，例如客户要求他们宝贵的软件尊重其现有的工作流程。另一方面，最终用户喜欢他们的开源部署很可能在大型数据中心中拥有悠久的使用历史，并且以前的用户确保了该软件符合他们的喜好。

这两种方法都有代价：开源开发在其生命周期的特定时间可能实际上会更慢，因为该模型固有一些间接成本，而专有开发虽然可能更快，但会将开发团队推向维护地狱，需要不断维护通常在开源开发中免费提供的粘合位。最近的大量证据表明，开源方法在数据中心中效率更高。

假设您的团队走上了专有开发的道路，但最终得出结论，他们可以通过开源方法赢得更多用户——那么该怎么办？这就是难题所在：撤销专有流程并将开源“酱料”注入项目中的过程非常困难。科技行业的许多原本知识渊博的人都不知道其中涉及多少变化。见鬼，大多数工程师都不知道在半路换马实际上涉及什么。参与这个过程必然意味着损失宝贵的开发时间，同时承担开发人员觉得坦率地说有失身份的任务。将软件从单体式专有代码库更改为可以与他人良好协作的代码库是一项艰巨的任务。

“但是等等！”，我仿佛听到您说。“他们难道不能只是以开源许可证发布他们拥有的任何东西，然后稍后处理其他事情吗？” 当然，他们可以，但最终结果很可能充其量是令人失望，最坏的情况是彻底的灾难。首先，凡人甚至无法安装该软件，更不用说从源代码构建它了。开发人员使用多种技巧来使其黑盒单体式产品为最终用户工作，但这使其不利于开源社区建设。

高度定制的构建环境和工具。 这是大多数专有软件无法简单地作为开源软件发布的首要原因：除了构建它的开发团队之外，它对所有人来说都是完全无法使用的。在开发开源软件时，有一些标准的软件构建方法。所有这些方法在生产用于以最高效率运行的高度优化的可执行程序方面都很糟糕，但它们非常适合为开发人员提供一种简单、标准化的构建和分发软件的方法。使用标准化的开源构建工具构建您的专有软件的过程可能并非易事。相比之下，开源项目从一开始就使用 GCC 编译。
第三方库，也是专有的，您没有权限将其包含在您的开源代码中。 即使您的代码可以使用 GNU autotools 和 GCC 构建（以一个示例为例），您可能也必须重写代码的某些重要的部分。这会占用开发人员的时间和精力，他们将花费时间拆卸和替换许多代码片段，而不是实现新功能。这因项目而异，但它困扰着从封闭转向开放的绝大多数项目。
糟糕的安全实践。 当开发人员认为没有人关注时，他们会做各种疯狂的事情。只要按计划开发功能，就没有人会眨眼。正是这种功能开发优先于代码质量的做法，可能会导致一些可怕的安全漏洞。除了明显的例外，*咳嗽*心脏出血*咳嗽*，有很多证据表明开源软件比其专有软件 counterparts 更安全。
糟糕的编码实践和神奇的独角兽库。 出于与上述相同的原因，即功能优先且无人关注，开发人员倾向于使用其他软件包的最新和最强大的功能，尤其是在运行时脚本引擎、库和工具方面。他们获取代码，对其进行修改，然后他们就拥有了一个可以工作的最终产品。目前是这样。如果您赶时间并且您的代码必须在午夜前工作，并且时间快到 23:30 了，那么这非常棒。然而，问题是，该产品将在今晚午夜之后长期存在，您将负责维护、更新和同步您原始的独角兽库与不可避免地与您修改的内容不同的代码。这对每个人，包括开发人员和管理员来说，都是可怕的。想象一下，可怜的运维人员被分配安装和维护某人的深夜“创新”。

以上所有这些都使产品团队得出一个明显的结论：以尽可能远离其所在系统的方式打包和分发软件，通常以臃肿的虚拟设备的形式，或者至少以依赖于最少系统库的独立应用程序的形式。Windows 管理员应该不时查看他们的 Program Files 目录。或者最好不要看。所有这些加在一起，使得最终产品极难作为开源软件发布。

一些运维人员可能会认为设备更容易部署和维护，但更多时候，他们会捏着鼻子使用它。如果该软件实际上使他们的工作更轻松，他们会容忍这种方法，但他们不会喜欢它。我认识的所有运维人员（我以前也是其中之一）都更喜欢他们部署的软件符合他们现有的流程和工作流程，而不是迫使他们创建新的流程和工作流程。

换句话说：如果您的软件最初是作为一个开源项目开始的，那么它还会以当前的形式存在吗？或者最终用户会要求采用不同的方法吗？

开源更多的是关于过程而非许可，开源社区中的每个人都有能力影响这些过程。从一开始就作为开源项目启动的项目，从一开始就内置了许多特性，这些特性通常（但并非总是如此）将开发人员从他们自己最糟糕的本能中拯救出来。如果您选择改变方向并转向开源模型，请了解这种变化需要什么——这是一个雷区，充满了对您的开发团队来说是全新的挑战，他们不习惯看到自己的实践受到质疑，特别不喜欢直接的客户反馈，并且完全不习惯其他人一边阅读一边编写代码的想法。从专有流程更改为开源流程所需的工作量可能与从瀑布式开发转变为敏捷开发的工作量相当。

示例：ManageIQ

当 Red Hat 在 2012 年底收购 ManageIQ 时，其理解是代码最终将开源。但是，有几件事阻碍了这一点

许多用户界面 (UI) 脚本和库都是专有的第三方工具。
该软件以加密虚拟机形式分发。
ManageIQ 过去是现在也是一个 Rails 应用程序，并且一些随附的 Ruby gems 从其上游来源进行了修改，以实现某些特定功能。

#1 意味着代码的许多部分，尤其是在 UI 中，必须被删除，并用开源库替换或重写。这花费了相当多的时间，但这是发布代码必须要做的事情。

#2 是在开源项目中无法做到的事情，这让开发团队感到恐惧。在失去随加密设备分发软件而来的（虚假的）安全感之后，对代码进行了一些必要的更改。

#3 意味着开发团队必须继续推进其对自定义 gems 的修改，这正变得一项繁重的苦差事，并且随着时间的推移只会变得更糟。开发团队仍在修复这个问题，但我很高兴地报告，我们聘请了一位强大的 Ruby 开发人员 Aaron Patterson，他将（除其他事项外）维护团队对上游 gems 的更改并防止未来的分支和分歧。他还将领导将 ManageIQ 转换为 Ruby on Rails 4 的工作。