这是借助 Electron 框架，构建一个在 Linux 桌面上原生运行的开源电子邮件服务的故事。

Tutanota 是一种安全的开源电子邮件服务，它可通过浏览器使用，也有 iOS 和 Android 应用。其客户端代码在 GPLv3 下发布，Android 应用程序可在 F-Droid 上找到，以便每个人都可以使用完全与 Google 无关的版本。

由于 Tutanota 关注开源和 Linux 客户端开发，因此我们希望为 Linux 和其他平台发布一个桌面应用程序。作为一个小团队，我们很快就排除了为 Linux、Windows 和 MacOS 构建原生应用程序的可能性，并决定使用 Electron 来构建我们的应用程序。

对于任何想要快速交付视觉一致的跨平台应用程序的人来说，Electron 是最适合的选择，尤其是如果你已经有一个 Web 应用程序，想要从浏览器 API 的束缚中摆脱出来时。Tutanota 就是这样一个案例。

Tutanota 基于 SystemJS 和 Mithril，旨在为每个人提供简单、安全的电子邮件通信。 因此，它必须提供很多用户期望从电子邮件客户端获得的标准功能。

由于采用了现代 API 和标准，其中一些功能（如基本的推送通知、搜索文本和联系人以及支持双因素身份验证）很容易在浏览器中提供。其它功能（例如自动备份或无需我们的服务器中转的 IMAP 支持）需要对系统资源的限制性访问，而这正是 Electron 框架提供的功能。

虽然有人批评 Electron “只是一个基本的包装”，但它有明显的好处：

• Electron 可以使你能够快速地为 Linux、Windows 和 MacOS 桌面构造 Web 应用。事实上，大多数 Linux 桌面应用都是使用 Electron 构建的。
• Electron 可以轻松地将桌面客户端与 Web 应用程序达到同样的功能水准。
• 发布桌面应用程序后，你可以自由使用开发功能添加桌面端特定的功能，从而增强可用性和安全性。
• 最后但同样重要的是，这是让应用程序具备原生的感觉、融入用户系统，而同时保持其识别度的好方法。 ### 满足用户的需求

Tutanota 不依靠于大笔的投资资金，而是依靠社区驱动的项目。基于越来越多的用户升级到我们的免费服务的付费计划，我们有机地发展我们的团队。倾听用户的需求不仅对我们很重要，而且对我们的成功至关重要。

提供桌面客户端是 Tutanota 用户最想要的功能，我们感到自豪的是，我们现在可以为所有用户提供免费的桌面客户端测试版。（我们还实现了另一个高度要求的功能 —— 搜索加密数据 —— 但这是另一个主题了。）

我们喜欢为用户提供签名版本的 Tutanota 并支持浏览器中无法实现的功能，例如通过后台进程推送通知。 现在，我们计划添加更多特定于桌面的功能，例如 IMAP 支持（而不依赖于我们的服务器充当代理），自动备份和离线可用性。

我们选择 Electron 是因为它的 Chromium 和 Node.js 的组合最适合我们的小型开发团队，因为它只需要对我们的 Web 应用程序进行最小的更改。在我们开始使用时，可以将浏览器 API 用于所有功能特别有用，随着我们的进展，慢慢地用更多原生版本替换这些组件。这种方法对附件下载和通知特别方便。

调整安全性

我们知道有些人关注 Electron 的安全问题，但我们发现 Electron 在 Web 应用程序中微调访问的选项非常令人满意。你可以使用 Electron 的安全文档和 Luca Carettoni 的Electron 安全清单等资源，来帮助防止 Web 应用程序中不受信任的内容发生灾难性事故。

实现特定功能

Tutanota Web 客户端从一开始就构建了一个用于进程间通信的可靠协议。我们利用 Web 线程在加密和请求数据时保持用户界面（UI）响应性。当我们开始实现我们的移动应用时，这就派上用场，这些应用程序使用相同的协议在原生部分和 Web 视图之间进行通信。

这就是为什么当我们开始构建桌面客户端时，很多用于本机推送通知、打开邮箱和使用文件系统的部分等已经存在，因此只需要实现原生端（Node.js）。

另一个便利是我们的构建过程使用 Babel 转译器，它允许我们以现代 ES6 JavaScript 编写整个代码库，并在不同环境之间混合和匹配功能模块。这使我们能够快速调整基于 Electron 的桌面应用程序的代码。但是，我们也遇到了一些挑战。

克服挑战

虽然 Electron 允许我们很容易地与不同平台的桌面环境集成，但你不能低估投入的时间！最后，正是这些小事情占用了比我们预期更多的时间，但对完成桌面客户端项目也至关重要。

特定于平台的代码导致了大部分阻碍：

• 例如，窗口管理和托盘仍然在三个平台上以略有不同的方式处理。
• 注册 Tutanota 作为默认邮件程序并设置自动启动需要深入 Windows 注册表，同时确保以 UAC 兼容的方式提示用户进行管理员访问。
• 我们需要使用 Electron 的 API 作为快捷方式和菜单，以提供复制、粘贴、撤消和重做等标准功能。

由于用户对不同平台上的应用程序的某些（有时不直接兼容）行为的期望，此过程有点复杂。使三个版本感觉像原生的需要一些迭代，甚至需要对 Web 应用程序进行一些适度的补充，以提供类似于浏览器中的文本搜索的功能。

总结

我们在 Electron 方面的经验基本上是积极的，我们在不到四个月的时间内完成了该项目。尽管有一些相当耗时的功能，但我们感到惊讶的是，我们可以轻松地为 Linux 提供一个测试版的 Tutanota 桌面客户端。如果你有兴趣，可以深入了解 GitHub 上的源代码。

via: https://opensource.com/article/19/4/linux-desktop-electron

作者：Nils Ganther 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

技术上的考虑并不是判断一个好的翻译平台的最佳方式。

语言翻译可以使开源软件能够被世界各地的人们使用，这是非开发人员参与他们喜欢的（开源）项目的好方法。有许多翻译工具，你可以根据他们处理翻译中涉及的主要功能区域的能力来评估：技术交互能力、团队支持能力和翻译支持能力。

技术交互方面包括：

• 支持的文件格式
• 与开源存储库的同步
• 自动化支持工具
• 接口可能性

对团队合作（也可称为“社区活力”）的支持包括该平台如何：

• 监控变更（按译者、项目等）
• 跟进由项目推动的更新
• 显示进度状态
• 是否启用审核和验证步骤
• 协助（来自同一团队和跨语言的）翻译人员和项目维护人员之间的讨论
• 平台支持的全球通讯（新闻等）

翻译协助包括：

• 清晰、符合人体工程学的界面
• 简单几步就可以找到项目并开始工作
• 可以简单地了解到翻译和分发之间流程
• 可以使用翻译记忆机
• 词汇表丰富

前两个功能区域与源代码管理平台的差别不大，只有一些小的差别。我觉得最后一个区域也主要与源代码有关。但是，它们处理的数据非常不同，翻译平台的用户通常也不如开发人员了解技术，而数量也更多。

我的推荐

在我看来，GNOME 平台提供了最好的翻译平台，原因如下：

• 其网站包含了团队组织和翻译平台。很容易看出谁在负责以及他们在团队中的角色。一切都集中在几个屏幕之内。
• 很容易找到要处理的内容，并且你会很快意识到你必须将文件下载到本地计算机并在修改后将其发回。这个流程不是很先进，但逻辑很容易理解。
• 一旦你发回文件，平台就可以向邮件列表发送通告，以便团队知道后续步骤，并且可以全局轻松讨论翻译（而不是评论特定句子）。
• 它支持多达 297 种语言。
• 它显示了基本句子、高级菜单和文档的明确的进度百分比。 再加上可预测的 GNOME 发布计划，社区可以使用一切可以促进社区工作的工具。

如果我们看看 Debian 翻译团队，他们多年来一直在为 Debian （LCTT 译注：此处原文是“Fedora”，疑为笔误）翻译了难以想象的大量内容（尤其是新闻），我们看到他们有一个高度以来于规则的翻译流程，完全基于电子邮件，手动推送到存储库。该团队还将所有内容都放在流程中，而不是工具中，尽管这似乎需要相当大的技术能力，但它已成为领先的语言群体之一，已经运作多年。

我认为，成功的翻译平台的主要问题不是基于单一的（技术、翻译）工作的能力，而是基于如何构建和支持翻译团队的流程。这就是可持续性的原因。

生产过程是构建团队最重要的方式；通过正确地将它们组合在一起，新手很容易理解该过程是如何工作的，采用它们，并将它们解释给下一组新人。

要建立一个可持续发展的社区，首先要考虑的是支持协同工作的工具，然后是可用性。

这解释了我为什么对 Zanata 工具沮丧，从技术和界面的角度来看，这是有效的，但在帮助构建社区方面却很差。我认为翻译是一个社区驱动的过程（可能是开源软件开发中最受社区驱动的过程之一），这对我来说是一个关键问题。

本文改编自“什么是一个好的翻译平台？”，最初发表在 Jibec 期刊上，并经许可重复使用。

via: https://opensource.com/article/19/5/translation-platforms

作者：Jean-Baptiste Holcroft 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Libki 是一个跨平台的计算机预约和用时管理系统。

提供公共计算机的图书馆、学校、学院和其他组织需要一种管理用户访问权限的好方法 —— 否则，就无法阻止某些人独占机器并确保每个人都有公平的用时。这是 Libki 要解决的问题。

Libki 是一个面向 Windows 和 Linux PC 的开源、跨平台的计算机预约和用时管理系统。它提供了一个基于 Web 的服务器和一个基于 Web 的管理系统，员工可以使用它来管理计算机访问，包括创建和删除用户、设置帐户用时限制、登出和禁止用户以及设置访问限制。

根据其首席开发人员 Kyle Hall 所说，Libki 主要用于 PC 用时控制，作为 Envisionware 出品的专有计算机访问控制软件的开源替代品。当用户登录 Libki 管理的计算机时，他们会有一段使用计算机的时间。时间到了之后，他们就会被登出。时间默认设置为 45 分钟，但可以使用基于 Web 的管理系统轻松调整。一些组织在登出用户之前提供 24 小时访问权限，而有的组织则使用它来跟踪使用情况而不设置用时限制。

Kyle 目前是 ByWater Solutions 的首席开发人员，该公司为图书馆提供开源软件解决方案（包括 Libki）。在职业生涯早期，他在宾夕法尼亚州的米德维尔公共图书馆担任 IT 技术时开发了 Libki。在其他员工的午休期间，偶尔会要求他关注孩子们的房间。图书馆使用纸质注册表来管理对儿童房间计算机的访问，这意味着不断的监督和检查，以确保来到那里的人能够公平地使用。

Kyle 说，“我发现这很笨拙而不便的，我想找到一个解决方案。这个解决方案需要同时是 FOSS 和跨平台的。最后，没有现有的软件适合我们的特殊需求，那就是为什么我开发了 Libki。“

或者，正如 Libki 的网站所宣称的那样，“Libki 的诞生是为了避免与青少年打交道（的麻烦），现在允许图书馆员避免与世界各地的青少年打交道（的麻烦）！”

易于安装和使用

我最近决定在我经常在那里做志愿者的当地的公共图书馆尝试 Libki。我按照文档在 Ubuntu 18.04 Server 中自动进行了安装，它很快就启动起来了。

我计划在我们当地的图书馆支持 Libki，但我想知道在那些没有 IT 相关经验的人或者无法构建和部署服务器的图书馆是怎样的。Kyle 说：“ByWater Solutions 可以云端托管 Libki 服务器，这使得每个人的维护和管理变得更加简单。”

Kyle 表示，ByWater 并不打算将 Libki 与其最受欢迎的产品，开源集成图书馆系统 （ILS）Koha 或其支持的任何其他项目捆绑在一起。他说： “Libki 和 Koha 是不同[类型]的软件，满足不同的需求，但它们在图书馆中确实很好地协同工作。事实上，我很早就开发了 Libki 的 SIP2 集成，因此它可以支持使用 Koha 进行单点登录。“

如何贡献

Libki 客户端是 GPLv3 许可，Libki 服务器是 AGPLv3 许可。Kyle 说他希望 Libki 拥有一个更加活跃和强大的社区，项目一直在寻找新人加入其贡献者。如果你想参加，请访问 Libki 社区页面并加入邮件列表。

via: https://opensource.com/article/19/5/libki-computer-access

作者：Don Watkins 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你还记得篇流行的博客文章《PHP：设计糟糕的分形》吗？我第一次读到它时，我在一个有很多遗留的 PHP 项目的糟糕地方工作。这篇文章让我觉得我是否应该放弃，并去做与编程完全不同的事情。

还好，我之后很快就换了工作，更重要的是，自从 5.x 版本以来，PHP 成功地进步了很多。今天，我在向那些不再使用 PHP 编程，或者陷入遗留项目的人们致意。

剧透：今天有些事情仍然很糟糕，就像几乎每种编程语言都有它的怪癖一样。许多核心功能仍然有不一致的调用方法，仍然有令人困惑的配置设置，仍然有许多开发人员在那里写蹩脚的代码 —— 因为他们必须如此，或是他们不知道更好的写法。

今天我想看看好的一面：让我们关注已经发生变化的事情，以及编写干净而可维护的 PHP 代码的方法。在此之前，我想请你暂时搁置任何偏见。

然后，你可以像以前一样对 PHP 自由吐槽。虽然，你可能会对 PHP 在过去的几年里的一些改进感到惊讶。（LCTT 译注：说实话，我是真的感到吃惊）

提前看结论

• PHP 在积极地开发，每年都有新版本
• 自 PHP 5 时代以来的性能已经翻倍，如果不是三倍的话
• 有一个非常活跃的框架、包和平台的生态系统
• PHP 在过去几年中添加了许多新功能，并且这种语言在不断发展
• 像静态分析这样的工具在过去几年中已经成熟，并且一直保持增长 更新：人们让我展示一些实际的代码。我觉得这没问题！这是我的一个业余项目的源代码，用 PHP 和 Laravel 编写的；这里列出了我们在办公室维护的几百个自由开源软件包。这两者都是现代 PHP 项目的好例子。

那让我们开始吧。

历史总结

出于更好地衡量的目的，让我们快速回顾一下如今的 PHP 发布周期。我们现在的 PHP 为 7.3，预计在 2019 年底为 7.4。PHP 8.0 将是 7.4 之后的下一个版本。

自从 5.x 时代以来，核心团队试图保持每年发布一个版本的周期，并且他们在过去的四年中成功地做到了这一点。

一般来说，每个新版本都会在两年内得到积极支持，并再获得一年以上的“安全修复”。其目标是激励 PHP 开发人员尽可能保持最新：例如，每年进行小规模升级比在 5.4 到 7.0 之间跳转更容易。

可以在 这里 找到 PHP 时间轴的活动概述。

最后，PHP 5.6 是最新的 5.x 版本，而 8.0 是当前的下一个大版本。如果你想知道 PHP 6 发生了什么，你可以听听 PHP Roundtable 播客。

了解了这个，让我们揭穿一些关于现代 PHP 的常见误解。

PHP 的性能

早在 5.x 时代，PHP 的表现就是……嗯，平均水平。但是在 7.0 版本中，PHP 从头开始重写了核心部分，导致其性能提升了两到三倍！

但光是嘴说是不够的。让我们来看看基准测试。幸运的是，人们花了很多时间对 PHP 性能进行了基准测试。 我发现 Kinsta 有一个很好的更新的测试列表。

自 7.0 升级以来，性能就一直在提升而没有回退。PHP Web 应用程序的性能可与其它语言中的 Web 框架相提并论，甚至在某些情况下更好。你可以看看这个广泛的基准测试套件。

当然 PHP 框架不会胜过 C 和 Rust，但它们比 Rails 或 Django 要好得多，并且与 ExpressJS 相当。

框架和生态系统

说到框架：PHP 可不仅仅是 WordPress。让我告诉你 —— 某些专业的 PHP 开发人员：WordPress 绝不代表当代的 PHP 生态系统。

一般来说，有两个主要的 Web 应用程序框架，Symfony 和 Laravel，以及一些较小的应用程序框架。当然还有 Zend、Yii、Cake、Code Igniter 等等，但是如果你想知道现代 PHP 开发是怎么样的，这两者之一都是很好的选择。

这两个框架都有一个庞大的包和产品的生态系统。从管理面板和 CRM 到独立软件包，从 CI 到分析器，以及几个 Web 套接字服务器、队列管理器、支付集成等众多服务。老实说，要列出的内容太多了。

这些框架虽然适用于实际开发。如果你只是需要个内容管理系统（CMS），WordPress 和 CraftCMS 等平台就够了。

衡量 PHP 生态系统当前状态的一种方法是查看 Packagist，这是 PHP 主要的软件包存储库。它现在呈指数级增长。每天下载量达到了 2500 万次，可以说 PHP 生态系统已不再是以前的小型弱势群体了。

请查看此图表，它列出一段时间内的软件包和版本数量变化。它也可以在 Packagist 网站上找到它。

除了应用程序框架和 CMS 之外，我们还看到过去几年里异步框架的兴起。

这些是用 PHP 或其他语言编写的框架和服务器，允许用户运行真正的异步 PHP，这些例子包括 Swoole（创始人韩天峰），以及 Amp 和 ReactPHP。

我们已经进入了异步的世界，像 Web 套接字和具有大量 I/O 的应用程序之类的东西在 PHP 世界中已经变得非常重要。

在内部邮件列表里（PHP 核心开发人员讨论语言开发的地方）已经谈到了将 libuv 添加到核心。如果你还不知道 libuv：Node.js 全有赖它提供异步性。

语言本身

虽然尚未提供 async 和 await，但在过去几年中，PHP 语言本身已经有了很多改进。这是 PHP 中新功能的非详尽列表：

• 短闭包（箭头函数）
• Null 合并操作符（??）
• Trait（一种代码重用方式）
• 属性类型
• 展开操作符（参数解包 ...）
• JIT 编译器（即时编译器）
• FFI（外部函数接口）
• 匿名类
• 返回类型声明
• 现代化的加密支持
• 生成器
• 等等

当我们讨论语言功能时，我们还要谈谈当今该语言的发展过程。虽然社区可以提出 RFC，但是得有一个活跃的志愿者核心团队才能推着它前进。

接下来，这些 RFC 将在“内部”邮件列表中进行讨论，这个邮件列表也可以在线阅读。在添加新的语言特性之前，必须进行投票。只有得到了至少 2/3 多数同意的 RFC 才能进入核心。

可能有大约 100 人能够投票，但不需要每个人对每个 RFC 进行投票。核心团队的成员当然可以投票，他们是维护代码库的人。除了他们之外，还有一群人从 PHP 社区中被单独挑选出来。这些人包括 PHP 文档的维护者，对 PHP 项目整体有贡献的人，以及 PHP 社区中的杰出开发人员。

虽然大多数核心开发都是在自愿的基础上完成的，但其中一位核心 PHP 开发人员 Nikita Popov 最近受雇于 JetBrains 全职从事于 PHP 语言的开发。另一个例子是 Linux 基金会最近决定投资 Zend 框架。像这样的雇佣和收购确保了 PHP 未来发展的稳定性。

工具

除了核心本身，我们看到过去几年中围绕它的工具有所增加。首先浮现于我脑海中的是静态分析器，比如由 Vimeo 创建 Psalm，以及 Phan 和 PHPStan。

这些工具将静态分析你的 PHP 代码并报告任何类型错误和可能的错误等。在某种程度上，它们提供的功能可以与 TypeScript 进行比较，但是现在这种语言不能 转译 transpiling ，因此不支持使用自定义语法。

尽管这意味着我们需要依赖 docblocks，但是 PHP 之父 Rasmus Lerdorf 确实提到了添加静态分析引擎到核心的想法。虽然会有很多潜力，但这是一项艰巨的任务。

说到转译，以及受到 JavaScript 社区的启发；他们已经努力在用户领域中扩展 PHP 语法。一个名为 Pre 的项目正是如此：允许将新的 PHP 语法转译为普通的 PHP 代码。

虽然这个思路已经在 JavaScript 世界中被证明了，但如果提供了适当的 IDE 和静态分析支持，它就能在 PHP 中工作了。这是一个非常有趣的想法，但必须发展起来才能称之为“主流”。

结语

尽管如此，你仍然可以将 PHP 视为一种糟糕的语言。虽然这种语言肯定有它的缺点和背负了 20 年的遗产；但我可以放胆地说，我喜欢用它工作。

根据我的经验，我能够创建可靠、可维护和高质量的软件。我工作的客户对最终结果感到满意，“俺也一样”。

尽管仍然可以用 PHP 做很多乱七八糟的事情，但我认为如果明智和正确地使用的话，它是 Web 开发的绝佳选择。

你不同意吗？让我知道为什么！你可以通过 Twitter 或 电子邮件 与我联系。

via: https://stitcher.io/blog/php-in-2019

作者：Brent 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。

开源社区中很少有法律话题像《贡献者许可协议》（CLA）一样具有争议性。除非你算上《Fedora 项目贡献者协议》（我一直被视为非 CLA）的特殊历史案例，或者像 Karl Fogel 一样，将《开发者原创证书》（DCO）归类为一种 CLA。目前红帽公司在其维护的项目中没有使用 CLA。

过去情况并非如此。红帽公司最早的项目遵循我称之为 “入站=出站” （ inbound=outbound ） 的传统做法，其中对项目的贡献仅根据项目的开源许可协议提供，不需要执行外部非自由和开源许可协议。但在 21 世纪初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 Apache ICLA 制定的 CLA，而自由软件基金会衍生的版权转让协议和一对定制的 CLA 分别继承自 Cygnus 和 JBoss 的收购。我们甚至采取了一些措施，在快速增长的红帽公司主导项目中采用 Apache 风格的 CLA。

这种情况已经结束，很大程度上是因为我们红帽公司法律团队成员听到并理解了红帽工程师和更广泛的技术社区提出的担忧和异议。我们继续成为一些人称之为反 CLA 运动的事实上的领导者，特别是我们反对 Project Harmony 以及我们努力让 OpenStack 用 DCO 取代其 CLA。（我们不情愿地签署可容忍的不符合实际需要的上游项目 CLA）

为什么 CLA 存在问题

我们不使用 CLA 的选择反映了我们作为一个真正的开源公司的价值观，它在自由软件运动中有着深厚的根源。多年来，许多开源社区已经解释了为什么 CLA 以及类似的版权分配机制对于开源来说是一个糟糕的政策。

其中一个原因是繁文缛节问题。通常情况下，开源开发的特点是 无障碍 （ frictionless ） 贡献，这可以通过“入站=出站”来实现，而不需要进行进一步的法律仪式或流程。这使得新贡献者相对容易参与项目，允许贡献者社区更有效的增长并推动上游的技术创新。无障碍贡献是开源开发针对专有替代品享有优势的关键部分。但是，CLA 否定了无障碍的贡献。在贡献被接受之前签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。尽管采用 CLA 的项目越来越多地使用自动化手段，但这种成本仍然存在。

CLA 还会导致项目参与者之间的法律权力不对称，这也阻碍了项目周边主要贡献者和用户社区的增长。使用 Apache 风格的 CLA，领导项目的公司或组织获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担项目负责人免除的某些法律义务（除了繁文缛节负担）。在 左版 （ copyleft ） 项目中，不对称问题最为严重，即使出站许可协议是宽松的，它也存在。

在评估支持和反对 CLA 的论据时，请记住，今天与过去一样，任何产品中的绝大多数开源代码都源于遵循“入站=出站”实践的项目。相对较少数量的项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某些原因，开源许可协议不足以处理流入项目的贡献。

CLA 的案例

由于 CLA 仍然是少数人的做法，并且源自外部开源社区文化，我认为 CLA 的支持者应该解释清楚为什么它们相对于其成本是必要或有益的。我怀疑大多数使用 CLA 的公司只是在没有经过严格审查的情况下模仿同行公司的行为。肤浅的来说，对于那些倾向于采用更复杂的手续、纸张和流程而不管业务成本如何的风险规避律师而言，CLA 是正常的。尽管如此，一些支持 CLA 的论据往往是先进的，值得考虑。

易于 再许可 （ relicensing ） ：如果管理得当，Apache 风格的 CLA 可以根据管理员的选择，为其提供有效的无限权力来进行分许可。这种做法有时被认为是可取的，因为可能需要依据一些其他开源许可协议再许可该项目。但是，回顾一些涉及大量贡献者的项目（所有这些项目都是在没有使用 CLA 的情况下取得成功）的重要再许可活动的历史案例，易于再许可的价值被夸大了。再许可变得困难很有好处，因为它会让项目产生稳定的法律期望，并鼓励项目在进行重大法律政策变更之前咨询其贡献者社区。在任何情况下，大多数“入站=出站”开源项目在其生命周期中从不尝试再许可，而对于少数这样做的项目来说，再许可将相对轻松，因为通常需要去联系的过去的贡献者的数量不会很大。

原创追踪：有的人声称 CLA 使项目能够严格跟踪具有一定法律效益的贡献的来源。目前尚不清楚在这方面使用 CLA 所取得的成就是因为通过保留 Git 提交历史这样的非 CLA 手段无法更好地处理。DCO 似乎更适合跟踪贡献，因为它通常在每个提交的基础上使用，而 CLA 是每个贡献者签署一次，并且在行政上与代码贡献分开。此外，原创跟踪通常被描述为对公众有益，但我知道项目无法对 CLA 接受记录提供透明的随时可行的公开访问。

许可撤销：一些 CLA 支持者警告说可能有一天，贡献者可能会试图撤销过去授予的许可。如果关注的范围是大量没有供职公司的具有判断力的个人贡献者，则不清楚为什么 Apache 风格的 CLA 与使用开源许可协议相比提供了更有意义的保护。而且，正如在讨论开源法律政策时提出的许多法律风险一样，这似乎是一种幻想的风险。多年来，我只听说过少数声称的许可撤销尝试活动，所有这些都在贡献者面临社区压力而退步时得到迅速解决。

未经授权的员工贡献：这是许可撤销问题的一个特例，最近已成为 CLA 倡导者共同提出的观点。当员工为上游项目提供贡献时，通常雇主拥有项目给予许可的版权和专利，并且只有某些管理人员有权授予此类许可。假设一名员工在未经雇主批准的情况下向项目提供了专有代码，雇主后来发现这一点并要求删除该项贡献或起诉该项目的用户。通过使用类似 Apache CCLA 及其陈述和签名要求的材料，加上一些适当的审查程序以确定 CCLA 签名者可能被授权签署（我怀疑大多数使用 CLA 的公司没有采取任何有意义的措施），可以将这种未经授权的贡献风险最小化。

基于常识和共同经验，我认为，在今天的几乎所有案例中，员工的贡献都是在雇主的实际或建设性知识基础上和同意下完成的。如果围绕开源软件存在高度诉讼风险，也许应该更加重视这种风险，但开源项目引发的诉讼仍然非常罕见。

更重要的是，我不知道任何针对“入站=出站”项目的非源自涉嫌开源许可协议违规的版权或专利侵权指控因使用CLA而被阻止的案例。特别是，当指出未经授权的贡献风险时，CLA 支持者经常引用专利风险，但 Apache 风格的 CLA 中的专利许可授权的设计范围非常狭窄。此外，企业对开源项目的贡献通常很少，规模较小（因此很容易更换），并且随着时间的推移可能会被丢弃。

备选方案

如果您的公司没有对反 CLA 案例买账并且对简单使用“入站=出站”感到不舒服，那么还有其他方法可以替代非对称且管理上繁琐的 Apache 风格的 CLA 要求。使用 DCO 作为“入站=出站”的补充至少消除了厌恶风险的 CLA 倡导者的一些担忧。如果必须使用真正的 CLA，则无需使 用Apach e模式（更不用说它的怪异衍生物）。考虑“Eclipse 贡献者协议”的非规范核心（基本上是包含在 CLA 内的 DCO），或者 软件自由保护协会 （ Software Freedom Conservancy ） 的 Selenium CLA，它仅仅是对“入站=出站”贡献策略进行仪式化。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

消除一些关于 DevOps 的疑惑。

很多人初学 DevOps 时，看到它其中一个结果就问这个是如何得来的。其实理解这部分 Devops 的怎样实现并不重要，重要的是——理解（使用） DevOps 策略的原因——这是做一个行业的领导者还是追随者的差别。

你可能会听过些 Devops 的难以置信的成果，例如生产环境非常有弹性，就算是有个“ 癫狂的猴子 Chaos Monkey ）跳来跳去将不知道哪个插头随便拔下，每天仍可以处理数千个发布。这是令人印象深刻的，但就其本身而言，这是一个 DevOps 的证据不足的案例，其本质上会被一个反例#Proving_a_negative)困扰：DevOps 环境有弹性是因为严重的故障还没有被观测到。

有很多关于 DevOps 的疑惑，并且许多人还在尝试弄清楚它的意义。下面是来自我 LinkedIn Feed 中的某个人的一个案例：

最近我参加一些 #DevOps 的交流会，那里一些演讲人好像在倡导 #敏捷开发是 DevOps 的子集。不知为何，我的理解恰恰相反。

能听一下你们的想法吗？你认为敏捷开发和 DevOps 之间是什么关系呢？

1. DevOps 是敏捷开发的子集
2. 敏捷开发是 DevOps 的子集
3. DevOps 是敏捷开发的扩展，从敏捷开发结束的地方开始
4. DevOps 是敏捷开发的新版本

科技行业的专业人士在那篇 LinkedIn 的帖子上表达了各种各样的答案，你会怎样回复呢？

DevOps 源于精益和敏捷

如果我们从亨利福特的战略和丰田生产系统对福特车型的改进（的历史）开始， DevOps 就更有意义了。精益制造就诞生在那段历史中，人们对精益制作进行了良好的研究。James P. Womack 和 Daniel T. Jones 将精益思维（Lean Thinking）提炼为五个原则：

1. 指明客户所需的价值
2. 确定提供该价值的每个产品的价值流，并对当前提供该价值所需的所有浪费步骤提起挑战
3. 使产品通过剩余的增值步骤持续流动
4. 在可以连续流动的所有步骤之间引入拉力
5. 管理要尽善尽美，以便为客户服务所需的步骤数量和时间以及信息量持续下降

精益致力于持续消除浪费并增加客户的价值流动。这很容易识别并明白精益的核心原则：单一流。我们可以做一些游戏去了解为何同一时间移动单个比批量移动要快得多。其中的两个游戏是硬币游戏和飞机游戏。在硬币游戏中，如果一批 20 个硬币到顾客手中要用 2 分钟，顾客等 2 分钟后能拿到整批硬币。如果一次只移动一个硬币，顾客会在 5 秒内得到第一枚硬币，并会持续获得硬币，直到在大约 25 秒后第 20 个硬币到达。（LCTT 译注：有相关的视频的）

这是巨大的不同，但是不是生活中的所有事都像硬币游戏那样简单并可预测的。这就是敏捷的出现的原因。我们当然看到了高效绩敏捷团队的精益原则，但这些团队需要的不仅仅是精益去做他们要做的事。

为了能够处理典型的软件开发任务的不可预见性和变化，敏捷开发的方法论会将重点放在意识、审议、决策和行动上，以便在不断变化的现实中调整。例如，敏捷框架（如 srcum）通过每日站立会议和冲刺评审会议等仪式提高意识。如果 scrum 团队意识到新的事实，框架允许并鼓励他们在必要时及时调整路线。

要使团队做出这些类型的决策，他们需要高度信任的环境中的自我组织能力。以这种方式工作的高效绩敏捷团队在不断调整的同时实现快速的价值流，消除错误方向上的浪费。

最佳批量大小

要了解 DevOps 在软件开发中的强大功能，这会帮助我们理解批处理大小的经济学。请考虑以下来自Donald Reinertsen 的产品开发流程原则的U曲线优化示例：

这可以类比杂货店购物来解释。假设你需要买一些鸡蛋，而你住的地方离商店只有 30 分钟的路程。买一个鸡蛋（图中最左边）意味着每次要花 30 分钟的路程，这就是你的交易成本。持有成本可能是鸡蛋变质和在你的冰箱中持续地占用空间。总成本是交易成本加上你的持有成本。这个 U 型曲线解释了为什么对大部分人来说，一次买一打鸡蛋是他们的最佳批量大小。如果你就住在商店的旁边，步行到那里不会花费你任何的时候，你可能每次只会买一小盒鸡蛋，以此来节省冰箱的空间并享受新鲜的鸡蛋。

这 U 型优化曲线可以说明为什么在成功的敏捷转换中生产力会显著提高。考虑敏捷转换对组织决策的影响。在传统的分级组织中，决策权是集中的。这会导致较少的人做更大的决策。敏捷方法论会有效地降低组织决策中的交易成本，方法是将决策分散到最被人熟知的认识和信息的位置：跨越高度信任，自组织的敏捷团队。

下面的动画演示了降低事务成本后，最佳批量大小是如何向左移动。在更频繁地做出更快的决策方面，你不能低估组织的价值。

DevOps 适合哪些地方

自动化是 DevOps 最知名的事情之一。前面的插图非常详细地展示了自动化的价值。通过自动化，我们将交易成本降低到接近于零，实质上是可以免费进行测试和部署。这使我们可以利用越来越小的批量工作。较小批量的工作更容易理解、提交、测试、审查和知道何时能完成。这些较小的批量大小也包含较少的差异和风险，使其更易于部署，如果出现问题，可以进行故障排除和恢复。通过自动化与扎实的敏捷实践相结合，我们可以使我们的功能开发非常接近单件流程，从而快速、持续地为客户提供价值。

更传统地说，DevOps 被理解为一种打破开发团队和运营团队之间混乱局面的方法。在这个模型中，开发团队开发新的功能，而运营团队则保持系统的稳定和平稳运行。摩擦的发生是因为开发过程中的新功能将更改引入到系统中，从而增加了停机的风险，运营团队并不认为要对此负责，但无论如何都必须处理这一问题。DevOps 不仅仅尝试让人们一起工作，更重要的是尝试在复杂的环境中安全地进行更频繁的更改。

我们可以看看 Ron Westrum 在有关复杂组织中实现安全性的研究。在研究为什么有些组织比其他组织更安全时，他发现组织的文化可以预测其安全性。他确定了三种文化：病态的、官僚主义的和生产式的。他发现病态的可以预测其安全性较低，而生产式文化被预测为更安全（例如，在他的主要研究领域中，飞机坠毁或意外住院死亡的数量要少得多）。

高效的 DevOps 团队通过精益和敏捷的实践实现了一种生成性文化，这表明速度和安全性是互补的，或者说是同一个问题的两个方面。通过将决策和功能的最佳批量大小减少到非常小，DevOps 实现了更快的信息流和价值，同时消除了浪费并降低了风险。

与 Westrum 的研究一致，在提高安全性和可靠性的同时，变化也很容易发生。当一个敏捷的 DevOps 团队被信任做出自己的决定时，我们将获得 DevOps 目前最为人所知的工具和技术：自动化和持续交付。通过这种自动化，交易成本比以往任何时候都进一步降低，并且实现了近乎单一的精益流程，每天创造数千个决策和发布的潜力，正如我们在高效绩的 DevOps 组织中看到的那样

流动、反馈、学习

DevOps 并不止于此。我们主要讨论了 DevOps 实现了革命性的流程，但通过类似的努力可以进一步放大精益和敏捷实践，从而实现更快的反馈循环和更快的学习。在DevOps手册 中，作者除了详细解释快速流程外， DevOps 如何在整个价值流中实现遥测，从而获得快速且持续的反馈。此外，利用精益求精的突破和 scrum 的回顾，高效的 DevOps 团队将不断推动学习和持续改进深入到他们的组织的基础，实现软件产品开发行业的精益制造革命。

从 DevOps 评估开始

利用 DevOps 的第一步是，经过大量研究或在 DevOps 顾问和教练的帮助下，对高效绩 DevOps 团队中始终存在的一系列维度进行评估。评估应确定需要改进的薄弱或不存在的团队规范。对评估的结果进行评估，以找到具有高成功机会的快速获胜焦点领域，从而产生高影响力的改进。快速获胜非常重要，能让团队获取解决更具挑战性领域所需的动力。团队应该产生可以快速尝试的想法，并开始关注 DevOps 转型。

一段时间后，团队应重新评估相同的维度，以衡量改进并确立新的高影响力重点领域，并再次采纳团队的新想法。一位好的教练将根据需要进行咨询、培训、指导和支持，直到团队拥有自己的持续改进方案，并通过不断地重新评估、试验和学习，在所有维度上实现近乎一致。

在本文的第二部分中，我们将查看 Drupal 社区中 DevOps 调查的结果，并了解最有可能找到快速获胜的位置。

via: https://opensource.com/article/19/3/devops-most-important-tech-strategy

作者：Kelly Albrecht 选题：lujun9972 译者：zgj1024 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出