开源软件许可是什么_开源更多的是过程而不是许可

开源软件许可是什么

这证明了开放源代码计划（OSI）的开源软件品牌推广活动的成功，“开源”和“许可”在功能上是同义词。 就人们所熟悉的开源软件而言，它是根据许可发布的源代码，它使任何人都可以看到软件程序的“皇冠上的宝石”，而不是隐藏其基础的不透明二进制或黑盒。

自15年前埃里克·雷蒙德（Eric Raymond）将开放源代码软件推向公众以来，这种广受好评的趋势便成为了主流软件的主流观点。 但是，采用以前专有的代码库并将其过渡到开放源代码项目会使人们对以前有关代码和许可的任何假设提出严重质疑。 正是这项工作使人们认识到过程和治理的价值。 在看到了从封闭到开放的第一手过渡之后，我深信选择将代码作为专有项目还是开放源代码项目发布会导致最终产品的根本变化，这种差异很难回滚。

从大多数人的角度来看，软件许可证是发布开源软件的最重要方面，但是在我看来，许可证属于用户体验，工作流以及与现有数据中心技术集成的一部分。 在“已知”（许可）和实际现实（用户工作流）中，这种区别无处比在负责将其专有产品转换为开源项目的开发团队的恐惧中更为清晰。 实际上，工程师选择的开发方法对生产哪种类型的软件有直接影响。 如果从一开始就选择了开源开发模型，则可以合理地确定最终产品将具有相对的可移植性，并且可以插入最常用的环境中。 如果选择了专有模型，则开发人员很容易做出便宜的捷径，从而导致短期收益和长期痛苦，而这正是经常发生的情况。

就人们认为这些事情的程度而言，通常的看法是，此更改涉及简单的搜索和替换，也许是删除了第三方软件，将其上传到公共存储库并保存了！ 在GitHub上分叉给我！ 但是，事实离真相还很远。 大多数人对软件的遗忘是，与软件许可证相比，它更多地涉及流程，控制和管理。 正如我在《关于创新永远不会》中所说的那样，开源软件成功的关键不是对创新的渴望，而是开源生态系统中的所有参与者都处于平等竞争环境这一事实。 客户，外部开发人员，免费下载人员-都可以坐下来，并可以利用社区权益来对项目施加影响，而社区权益是他们随着时间的推移通过各种方式建立起来的。 这与专有开发模型形成了鲜明的对比，在专有开发模型中，开发人员只要创建满足产品管理提供的产品要求文档（PRD）期望的最终产品，他们就可以做他们想做的事情。

这就是开源和专有开发之间的区别得到明显缓解的地方。 开源开发随附的开放过程将有助于确保该软件可能集成到任何给定环境中，并且经常避免一些不良习惯。 这两件事是齐头并进的。 例如，专有软件开发通常会导致本质上是整体的软件，并且对系统软件的依赖性降到最低，并且通常与自己的一组库和工具捆绑在一起。 这为开发人员提供了做任何他们想做的事情的余地，它们经常使用特定版本的库，重新发明各种轮子，并且通常偏离创建在更广泛的上下文中运行良好的软件的道路。

相比之下，开源软件开发人员则没有这种奢侈。 从第一天开始，他们的用户就要求极高的灵活性，集成性和对标准数据中心系统实践的一致性。 这意味着只要有可能，就可以利用现有的工具和库，从而使您的软件成为大型数据中心计算机中的齿轮的想法得到了体现。 请注意，尽管有可能，但没有人提到开放源代码开发更快或更创新。 一方面，开发人员喜欢这样一个事实，他们可以完全控制最终产品，而不必处理烦恼，例如客户要求其珍贵的软件兑现其现有工作流程。 另一方面，最终用户喜欢这样一个事实，即他们的开源部署可能在大型数据中心内使用已有很长的历史，并且这些以前的用户已确保该软件符合他们的喜好。

这两种方法都是有代价的：由于模型固有的一些间接费用，开放源码开发实际上在生命周期的特定时间可能会变慢，而专有开发（虽然可能更快）会使开发团队失望。维护之路，需要无休止地维护开源开发中通常免费提供的胶水。 最近的大量证据表明，开源方法在数据中心要有效得多。

假设您的团队走了专有开发的道路，但最终得出的结论是，他们可以通过开源方法赢得更多的用户-那又是什么呢？ 难题就在于此：取消专有过程并向项目中注入开源酱非常困难。 科技行业中许多其他有学识的人都不知道涉及多少变化。 地狱，大多数工程师都不知道转换中游马匹实际上涉及什么。 坦率地说，参与此过程意味着在承担开发人员坦率地说要承担的任务的同时，必然会浪费宝贵的开发时间。 要将软件从单一的专有代码库更改为可以与其他软件完美结合的软件库是一项艰巨的任务。

“但是等等！”我听见你说。 “他们难道不能只是在开放源代码许可下释放他们拥有的所有东西，然后再照顾其他东西吗？” 当然可以 ，但是最终结果充其量只能是令人失望的，而最坏的情况是最大的灾难。 对于初学者而言，凡人将无法安装该软件，更不用说从源代码构建它了。 开发人员为了使黑盒整体产品能够为最终用户使用而发挥了一些技巧，这些技巧使开源社区建设变得很糟糕：

• 高度定制的构建环境和工具。 这就是为什么不能将大多数专有软件简单地设置为开放源代码的第一个原因：除了构建该软件的开发人员团队之外，所有其他人都完全无法使用它。 在开发开源软件时，有几种标准的方法来构建软件。 它们全都无法生成高度优化的可执行程序，无法以最高的效率运行，但是它们非常适合为开发人员提供一种简单，标准化的方式来构建和分发软件。 使用标准化的开源构建工具构建专有软件的过程可能并不容易。 相比之下，开源项目来自与GCC一起编译的婴儿床。

• 您没有权限将其包含在开源代码中的第三方库（也是专有库）。 即使您的代码可以使用GNU自动工具和GCC进行构建，使用一个示例，您可能也不得不重写代码中一些无关紧要的部分。 这将使您的开发人员节省时间和精力，他们将花费大量时间删除和替换许多代码而不执行新功能。 每个项目的情况各不相同，但是从封闭到开放的绝大多数项目都受到影响。

• 错误的安全做法。 当开发人员认为没有其他人在看时，他们会做各种疯狂的事情。 只要按计划开发功能，就不会让人大吃一惊。 功能开发超过代码质量的这种首要地位可能会导致一些可怕的安全漏洞。 除了明显的例外，例如“咳嗽”，“伤心欲绝”，“咳嗽”，还有许多证据表明，开源软件比专有软件更安全。

• 错误的编码做法和神奇的独角兽库。 出于与上述相同的原因，即 由于功能无所不在，开发人员往往会使用其他软件包中的最新，最好的软件，尤其是在运行时脚本引擎，库和工具方面。 他们获取了代码，对其进行了修改，然后他们拥有了可以运行的最终产品。 目前。 如果您要在截止日期之前完成代码，并且代码必须在午夜之前工作，并且已接近23:30，那么这很好。 但是，问题在于该产品将在今晚午夜之后使用很长时间，并且您将负责维护，更新和同步原始的独角兽库，并且所使用的代码将不可避免地与您修改的代码有所不同。 这对所有人，开发人员和管理员来说都是可怕的。 想象一下，在分配和安装某人的深夜“创新”操作中，可怜的草皮。

以上所有这些都会导致产品团队得出一个明显的结论：打包和分发软件时，应使其运行方式与所驻留的系统尽可能地相距遥远，通常采用膨胀的虚拟设备形式，至少应采用膨胀形式。一个独立的应用程序的形式，它仅依赖于最少的系统库。 Windows管理员有时应该查看其Program Files目录。 或者更好的是，不要。 所有这些加在一起，就构成了最终产品，它很难作为开源软件发布。

某些操作人员可能会认为设备对他们来说更易于部署和维护，但是更多时候，他们会举起鼻子来使用它。 如果该软件确实使他们的工作更轻松，他们将容忍这种方法，但是他们不喜欢它。 我认识的所有运维人员（我曾经是一个）都更喜欢他们部署的软件符合他们现有的流程和工作流程，而不是强迫他们创建新的。

换种说法：如果您的软件作为一个开源项目开始运行，您的软件会以当前形式存在吗？ 还是最终用户要求使用其他方法？

开源不仅关乎许可，而且关乎流程，而且开源社区中的每个人都有能力影响这些流程。 从开源开始的项目具有许多从一开始就具有的特征，这些特征常常（尽管并非总是如此）使开发人员摆脱了自己最糟糕的直觉。 如果您选择改变方向并转向开放源代码模型，请了解这种变化意味着什么—这是一个雷区，充满了对开发团队来说是新的挑战，他们不习惯看到自己的实践受到挑战，所以不要特别津津乐道的是直接获得客户的反馈，并且对于其他人在编写代码时反省他们的想法完全不满意。 从专有流程更改为开源流程的工作量可能与从瀑布式开发到敏捷开发的顺序相同。

示例：ManageIQ

当Red Hat在2012年末收购ManageIQ时，正是基于这样的理解：该代码最终将是开源的。 但是，有几件事阻碍了这一点：

1. 许多用户界面（UI）脚本和库都是专有的第三方工具。

2. 该软件作为加密的虚拟机分发。

3. ManageIQ曾经是并且是一个Rails应用程序，并且一些随附的Ruby gem从上游资源进行了修改，以实现某些特定功能。

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

＃2在开源项目中无法做到，这使开发团队的内心深处恐惧。 在失去在加密设备中分发软件所带来的（错误）安全感之后，有必要对代码进行一些更改。

＃3意味着开发团队必须继续对自定义gem进行修改，这已成为繁琐的工作，并且随着时间的推移只会变得更糟。 开发人员团队仍在解决此问题，但我很高兴地报告，我们已经聘请了强大的Ruby开发人员Aaron Patterson ，他将维持团队对上游gem的更改并防止将来的分叉和分歧。 他还将领导将ManageIQ转换为Ruby on Rails 4的工作。

结论

要体谅您的开发人员以及他们面临的挑战。 希望他们了解所需的更改将最终产生更好的最终产品。 它是有代价的，但也有其自身的回报。 永远不要忘记提醒人们从一开始就选择开源方法将避免这种痛苦。

翻译自: https://opensource.com/business/14/10/open-source-process

开源软件许可是什么