这有一些建议帮助你的全球化开发团队能够更好地理解你们的讨论并能参与其中。

几周前，我见证了两位同事之间一次有趣的互动，他们分别是 Jason，我们的一位美国员工，和 Raj，一位来自印度的访问工作人员。

Raj 在印度时，他一般会通过电话参加美国中部时间上午 9 点的每日立会，现在他到美国工作了，就可以和组员们坐在同一间会议室里开会了。Jason 拦下了 Raj，说：“Raj 你要去哪？你不是一直和我们开电话会议吗？你突然出现在会议室里我还不太适应。” Raj 听了说，“是这样吗？没问题。”就回到自己工位前准备和以前一样参加电话会议了。

我去找 Raj，问他为什么不去参加每日立会，Raj 说 Jason 让自己给组员们打电话参会，而与此同时，Jason 也在会议室等着 Raj 来参加立会。

到底是哪里出的问题？Jason 明显只是调侃 Raj 终于能来一起开会了，为什么 Raj 没能听懂呢？

Jason 明显是在开玩笑，但 Raj 把它当真了。这就是在两人互相不了解对方文化语境时发生的一个典型误会。

我经常会遇到有人在电子邮件的末尾写“请复原”，最开始我很迷惑，“这有什么需要我复原的内容？”后来我才搞懂，“请复原”其实是“请回复”的意思。

在 Ricardo Fernandez 的TED 演讲“如何管理跨文化团队” 中，他提到了自己与一位南非同事发生的小故事。那位同事用一句“我一会给你打电话。”结束了两人的 IM 会话，Ricardo 回到办公室后就开始等这位同事的电话，十五分钟后他忍不住主动给这位同事打了电话，问他:“你不是说要给我打电话吗？”，这位同事答到:“是啊，我是说以后有机会给你打电话。”这时 Ricardo 才理解那位同事说的“一会”是“以后”的意思。

现在是全球化时代，我们的同事很可能不跟我们面对面接触，甚至不在同一座城市，来自不同的国家。越来越多的技术公司拥有全球化的工作场所，和来自世界各地的员工，他们有着不同的背景和经历。这种多样性使得技术公司能够在这个快速发展的科技大环境下拥有更强的竞争力。

但是这种地域的多样性也会给团队带来挑战。管理和维持高性能的团队发展对于同地协作的团队来说就有着很大难度，对于有着多样背景成员的全球化团队来说，无疑更加困难。成员之间的交流会发生延迟，误解时有发生，成员之间甚至会互相怀疑，这些都会影响着公司的成功。

到底是什么因素让全球化交流间发生误解呢？我们可以参照 Erin Meyer 的书《文化地图》，她在书中将全球文化分为八个类型，其中美国文化被分为低语境文化，与之相对的，日本为高语境文化。

看到这里你可能会问，高、低语境文化到底是什么意思？美国人从小就教育孩子们简洁表达，“直言不讳”是他们的表达准则；另一边，日本人从小学习在高效处理社交线索的同时进行交流，“察言观色”是他们的交流习惯。

大部分亚洲国家的文化都属于高语境文化。作为一个年轻的移民国家，美国毫不意外地拥有着低语境文化。移民来自于世界各地，拥有着不同的文化背景，他们不得不选择简洁而直接的交流方式，这或许就是其拥有低语境文化的原因。

从文化语境的角度与异国同事交流的三个步骤：

怎样面临跨文化交流中遇到的挑战？比如说一位美国人与他的日本同事交流，他更应该注重日本同事的非语言线索，同样的日本同事应当更关注美国人直接表达出的信息。如果你也面临类似的挑战，按照下面这三个步骤做，可以帮助你更有效地和异国同事交流，增进与他们的感情。

认识到文化语境的差异

跨文化交流的第一步是认识到文化差异，跨文化交流从认识其他文化开始。

尊重文化语境的差异

一旦你意识到了文化语境的差异会影响跨文化交流，你要做的就是尊重这些差异。在你遇到一种不同的交流方式时，学会接受差异，学会积极听取他人意见。

调和文化语境的差异

只是认识和尊重差异还远远不够，你还需要学会如何调和这些差异。互相理解和换位思考可以增进差异的调和，你还要学着用它们去提高同事间的交流效率，推动生产力。

五种促进不同文化语境间交流的方法

为了加强组员们之间关系，这么多年来我一直在收集各种各样的方法和建议。这些方法帮助我解决了与外国组员间产生的很多交流问题，下面有其中一些例子：

与外国组员交流时尽量使用视频会议的形式

研究表明，交流中约 55% 的内容不是靠语言传递的。肢体语言传达着一种十分微妙的信息，你可以根据它们理解对方的意思，而视频会议中处于异地的组员们能够看到对方的肢体语言。因此，组织远程会议时我一般都会采用视频会议的形式。

确保每位成员都有机会分享他们的想法

我虽然喜欢开视频会议，但不是每次都能开的成。如果视频会议对你的团队来说并不常用，大家可能要一些时间去适应，你需要积极鼓励大家参与到其中，先从进行语音会议开始。

我们有一个外地的组员，每次都和我们进行语音会议，和我们提到她经常会有些想法想要分享，或者想做些贡献，但是我们互相看不到，她不知道该怎样开口。如果你一直在进行语音会议，注意要给组员们足够的时间和机会分享他们的想法。

互相学习

通过你身边一两名外国朋友来学习他们的文化，你可以把从一位同事身上学到的应用于所有来自这个国家的同事。我有几位南亚和南美的同事，他们帮助我理解他们的文化，而这些也使得我更加专业。

对编程人员来说，我建议请你全世界的同行们检查你的代码，这个过程能让你观察到其他文化中人们怎样进行反馈、劝说他人，和最终进行技术决策。

学会感同身受

同理心是一段牢固关系的核心。你越能换位思考，就越容易获得信任，来建立长久的关系。你可以在每次会议开始之前和大家闲聊几句，这样大家更容易处于一个放松的状态，如果团队中有很多外国人，要确保大家都能参与进来。

和你的外国同事们单独见面

保持长久关系最好的方法是和你的组员们单独见面。如果你的公司可以报销这些费用，那么努力去和组员们见面吧。和一起工作了很长时间的组员们见面能够使你们的关系更加坚固。我所在的公司就有着周期性交换员工的传统，每隔一段时间，世界各地的员工就会来到美国工作，美国员工再到其他分部工作。

另一种聚齐组员们的机会是研讨会。研讨会创造的不仅是学习和培训的机会，你还可以挤出一些时间和组员们培养感情。

在如今，全球化经济不断发展，拥有来自不同国家和地区的员工对维持一个公司的竞争力来说越来越重要。即使组员们来自世界各地，团队中会出现一些交流问题，但拥有一支国际化的高绩效团队不是问题。如果你在工作中有什么促进团队交流的小窍门，请在评论中告诉我们吧。

via: https://opensource.com/article/18/10/think-global-communication-challenges

作者：Avindra Fernando 选题：lujun9972 译者：Valoniakim 校对：wxy

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

对于框架、库或者工具来说，怎样做才算是“简单”？也许有很多的定义，但我的理解通常是易于调试。我经常见到人们宣传某个特定的程序、框架、库、文件格式或者其它什么东西是简单的，因为他们会说“看，我只需要这么一点工作量就能够完成某项工作，这太简单了”。非常好，但并不完善。

你可能只编写一次软件，但几乎总要经历好几个调试周期。注意我说的调试周期并不意味着“代码里面有 bug 你需要修复”，而是说“我需要再看一下这份代码来修复 bug”。为了调试代码，你需要理解它，因此“易于调试”延伸来讲就是“易于理解”。

抽象使得程序易于编写，但往往是以难以理解为代价。有时候这是一个很好的折中，但通常不是。大体上，如果能使程序在日后易于理解和调试，我很乐意花更多的时间来写一些东西，因为这样实际上更省时间。

简洁并不是让程序易于调试的唯一方法，但它也许是最重要的。良好的文档也是，但不幸的是好的文档太少了。（注意，质量并不取决于字数！）

这种影响是真是存在的。难以调试的程序会有更多的 bug，即使最初的 bug 数量与易于调试的程序完全相同，而是因为修复 bug 更加困难、更花时间。

在公司的环境中，把时间花在难以修复的 bug 上通常被认为是不划算的投资。而在开源的环境下，人们花的时间会更少。（大多数项目都有一个或多个定期的维护者，但成百上千的贡献者提交的仅只是几个补丁）

这并不全是 1974 年由 Brian W. Kernighan 和 P. J. Plauger 合著的《 编程风格的元素 The Elements of Programming Style 》中的观点：

每个人都知道调试比起编写程序困难两倍。当你写程序的时候耍小聪明，那么将来应该怎么去调试？

我见过许多看起来写起来“极尽精妙”，但却导致难以调试的代码。我会在下面列出几种样例。争论这些东西本身有多坏并不是我的本意，我仅想强调对于“易于使用”和“易于调试”之间的折中。

• ORM 对象关系映射 库可以让数据库查询变得简单，代价是一旦你想解决某个问题，事情就变得难以理解。
• 许多测试框架让调试变得困难。Ruby 的 rspec 就是一个很好的例子。有一次我不小心使用错了，结果花了很长时间搞清楚究竟哪里出了问题（因为它给出错误提示非常含糊）。

我在《测试并非万能》这篇文章中写了更多关于以上的例子。

• 我用过的许多 JavaScript 框架都很难完全理解。Clever（LCTT 译注：一种 JS 框架）的语句一向很有逻辑，直到某条语句不能如你预期的工作，这时你就只能指望 Stack Overflow 上的某篇文章或 GitHub 上的某个回帖来帮助你了。

这些函数库确实让任务变得非常简单，使用它们也没有什么错。但通常人们都过于关注“易于使用”而忽视了“易于调试”这一点。

• Docker 非常棒，并且让许多事情变得非常简单，直到你看到了这条提示：

ERROR: for elasticsearch Cannot start service elasticsearch:
oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258:
applying cgroup configuration for process caused \"failed to write 898 to cgroup.procs: write
/sys/fs/cgroup/cpu,cpuacct/docker/b13312efc203e518e3864fc3f9d00b4561168ebd4d9aad590cc56da610b8dd0e/cgroup.procs:
invalid argument\""

或者这条：

ERROR: for elasticsearch Cannot start service elasticsearch: EOF

那么…你怎么看？

• Systemd 比起 SysV、init.d 脚本更加简单，因为编写 systemd 单元文件比起编写 shell 脚本更加方便。这也是 Lennart Poetterin 在他的 systemd 神话 中解释 systemd 为何简单时使用的论点。

我非常赞同 Poettering 的观点——也可以看 shell 脚本陷阱 这篇文章。但是这种角度并不全面。单元文件简单的背后意味着 systemd 作为一个整体要复杂的多，并且用户确实会受到它的影响。看看我遇到的这个问题和为它所做的修复。看起来很简单吗？

via: https://arp242.net/weblog/easy.html

作者：Martin Tournoij 选题：lujun9972 译者：LuuMing 校对：wxy

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

有没有想过你喜欢的开源项目或编程语言的名称来自何处？让我们按字母顺序了解一下流行的技术术语背后的起源故事。

GNOME、Java、Jupyter、Python……如果你的朋友或家人曾留意过你的工作对话，他们可能会认为你从事文艺复兴时期的民间文学艺术、咖啡烘焙、天文学或动物学工作。这些开源技术的名称从何而来？我们请我们的作者社区提供意见，并汇总了一些我们最喜欢的技术名称的起源故事。

Ansible

“Ansible”这个名称直接来自科幻小说。Ursula Le Guin 的《Rocannon's World》一书中能进行即时（比光速更快）通信的设备被称为 ansibles（显然来自 “answerable” 一词）。Ansibles 开始流行于科幻小说之中，Orson Scott Card 的《Ender's Game》（后来成为受欢迎的电影）中，该设备控制了许多远程太空飞船。对于控制分布式机器的软件来说，这似乎是一个很好的模型，因此 Michael DeHaan（Ansible 的创建者和创始人）借用了这个名称。

Apache

Apache 是最初于 1995 年发布的开源 Web 服务器。它的名称与著名的美国原住民部落无关；相反，它是指对原始软件代码的重复补丁。因此称之为，“ 一个修补的 A-patchy 服务器”。

awk

“awk(1) 代表着 Aho、Weinberger、Kernighan（作者）”—— Michael Greenberg

Bash

“最初的 Unix shell，即 Bourne shell，是以其创造者的名字命名的。在开发出来 Bash 时，csh（发音为 ‘seashell’）实际上更受交互登录用户的欢迎。Bash 项目旨在赋予 Bourne shell 新的生命，使其更适合于交互式使用，因此它被命名为 ‘Bourne again shell’，是‘ 重生 born again ’的双关语。”——Ken Gaillot

C

在早期，AT&T 的 Ken Thompson 和 Dennis Ritchie 发现可以使用更高级的编程语言（而不是低级的、可移植性更低的汇编编程）来编写操作系统和工具。早期有一个叫做 BCPL（ 基本组合编程语言 Basic Combined programming Language ）的编程系统，Thompson 创建了一个名为 B 的简化版 BCPL，但 B 的灵活性和速度都不高。然后，Ritchie 把 B 的思想扩展成一种叫做 C 的编译语言。”——Jim Hall

dd

“我想你发表这样一篇文章不能不提到 dd。我的外号叫 Didi。发音正确的话听起来像 ‘dd’。我开始学的是 Unix，然后是 Linux，那是在 1993 年，当时我还是个学生。然后我去了军队，来到了我的部队中少数几个使用 Unix（Ultrix）的部门之一（其它部门主要是 VMS），那里的一个人说：‘这么说，你是一个黑客，对吗？你以为你了解 Unix 吗？好的，那么 dd 这个名字的是怎么来的呢？’我不知道，试着猜道：‘ 数据复印机 Data duplicator ？’所以他说，‘我要告诉你 dd 的故事。dd 是 转换 convert 和 复制 copy 的缩写（如今人们仍然可以在手册页中看到），但由于 cc 这个缩写已经被 C 编译器占用，所以它被命名为 dd。’就在几年后，我听闻了关于 JCL 的数据定义和 Unix dd 命令不统一的、半开玩笑的语法的真实故事，某种程度是基于此的。”——Yedidyah Bar David

Emacs

经典的 反 vi anti-vi 编辑器，其名称的真正词源并不明显，因为它源自“ 编辑宏 Editing MACroS ”。但是，它作为一个伟大的宗教亵渎和崇拜的对象，吸引了许多恶作剧般的缩写，例如“Escape Meta Alt Control Shift”（以调侃其对键盘的大量依赖），“ 8MB 并经常发生内存交换 Eight Megabytes And Constantly Swapping ”（从那时起就很吃内存了），“ 最终分配了所有的计算机存储空间 Eventually malloc()s All Computer Storage ”和 “ EMACS 使一台计算机慢 EMACS Makes A Computer Slow ”——改编自 Jargon File/Hacker's Dictionary

Enarx

Enarx 是机密计算领域的一个新项目。该项目的设计原则之一是它应该是“可替代的”。因此最初的名字是“psilocybin”（著名的魔术蘑菇）。一般情况下，经理级别的人可能会对这个名称有所抵触，因此考虑使用新名称。该项目的两位创始人 Mike Bursell 和 Nathaniel McCallum 都是古老语言极客，因此他们考虑了许多不同的想法，包括 тайна（Tayna——俄语中代表秘密或神秘——虽然俄语并不是一门古老的语言，但你就不要在乎这些细节了），crypticon（希腊语的意思是完全私生的），cryptidion（希腊中表示小密室），arconus（拉丁语中表示秘密的褒义形容词），arcanum（拉丁语中表示秘密的中性形容词）和 ærn（盎格鲁撒克逊人表示地方、秘密的地方、壁橱、住所、房子，或小屋的词汇）。最后，由于各种原因，包括域名和 GitHub 项目名称的可用性，他们选择了 enarx，这是两个拉丁词根的组合：en-（表示内部）和 -arx（表示城堡、要塞或堡垒）。

GIMP

没有 GIMP 我们会怎么样？ GNU 图像处理项目 GNU Image Manipulation Project 多年来一直是开源的重要基础。维基百科指出，“1995 年，Spencer Kimball) 和 Peter Mattis 在加州大学伯克利分校开始为 实验计算设施 eXperimental Computing Facility 开发 GIMP，这是一个为期一个学期的项目。”

GNOME

你有没有想过为什么 GNOME 被称为 GNOME？根据维基百科，GNOME 最初是一个表示“ GNU 网络对象模型环境 GNU Network Object Model Environment ”的缩写词。现在，该名称不再表示该项目，并且该项目已被放弃，但这个名称仍然保留了下来。GNOME 3 是 Fedora、红帽企业版、Ubuntu、Debian、SUSE Linux 企业版等发行版的默认桌面环境。

Java

你能想象这种编程语言还有其它名称吗？Java 最初被称为 Oak，但是遗憾的是，Sun Microsystems 的法律团队由于已有该商标而否决了它。所以开发团队又重新给它命名。据说该语言的工作组在 1995 年 1 月举行了一次大规模的头脑风暴。许多其它名称也被扔掉了，包括 Silk、DNA、WebDancer 等。该团队不希望新名称与过度使用的术语“web”或“net”有任何关系。取而代之的是，他们在寻找更有活力、更有趣、更容易记住的东西。Java 满足了这些要求，并且奇迹般地，团队同意通过了！

Jupyter

现在许多数据科学家和学生在工作中使用 Jupyter 笔记本。“Jupyter”这个名字是三种开源计算机语言的融合，这三种语言在这个笔记本中都有使用，在数据科学中也很突出：Julia、Python 和 R。

Kubernetes

Kubernetes 源自希腊语中的舵手。Kubernetes 项目创始人 Craig McLuckie 在 2015 Hacker News 回应中证实了这种词源。他坚持航海主题，解释说，这项技术可以驱动集装箱，就像舵手或驾驶员驾驶集装箱船一样，因此，他选择了 Kubernetes 这个名字。我们中的许多人仍然在尝试正确的发音（koo-bur-NET-eez），因此 替代使用 K8s 也是可以接受的。有趣的是，它与英语单词“ 行政长官 （ governor ） ”具有相同的词源，也与蒸汽机上的机械负反馈装置相同。

KDE

那 K 桌面呢？KDE 最初代表“ 酷桌面环境 Kool Desktop Environment ”。 它由 Matthias Ettrich 于 1996 年创立。根据维基百科上的说法，该名称是对 Unix 上 通用桌面环境 Common Desktop Environment （CDE）一词的调侃。

Linux

Linux 因其发明者 Linus Torvalds 的名字命名的。Linus 最初想将他的作品命名为“Freax”，因为他认为以他自己的名字命名太自负了。根据维基百科的说法，“赫尔辛基科技大学 Torvalds 的同事 Ari Lemmke 当时是 FTP 服务器的志愿管理员之一，他并不认为‘Freax’是个好名字。因此，他没有征询 Torvalds 就将服务器上的这个项目命名为‘Linux’。”

以下是一些最受欢迎的 Linux 发行版。

CentOS

CentOS 是 社区企业操作系统 Community Enterprise Operating System 的缩写。它包含来自 Red Hat Enterprise Linux 的上游软件包。

Debian

Debian Linux 创建于 1993 年 9 月，是其创始人 Ian Murdock 和他当时的女友 Debra Lynn 的名字的混成词。

RHEL

Red Hat Linux 得名于它的创始人 Marc Ewing，他戴着一顶祖父送给他的康奈尔大学红色 软呢帽 fedora 。红帽公司成立于 1993 年 3 月 26 日。Fedora Linux 最初是一个志愿者项目，旨在为红帽发行版提供额外的软件，它的名字来自红帽的“Shadowman”徽标。

Ubuntu

Ubuntu 旨在广泛分享开源软件，它以非洲哲学“ 人的本质 ubuntu ”命名，可以翻译为“对他人的人道主义”或“我之所以是我，是因为我们都是这样的人”。

Moodle

开源学习平台 Moodle 是“ 模块化面向对象动态学习环境 modular object-oriented dynamic learning environment ”的首字母缩写。Moodle 仍然是领先的线上学习平台。全球有近 10.4 万个注册的 Moodle 网站。

另外两个流行的开源内容管理系统是 Drupal 和 Joomla。Drupal 的名字来自荷兰语 “druppel”，意思是“掉落”。根据维基百科，Joomla 是斯瓦希里语单词“jumla”的英式拼写，在阿拉伯语、乌尔都语和其他语言中是“在一起”的意思。

Mozilla

Mozilla 是一个成立于 1998 年的开源软件社区。根据其网站，“Mozilla 项目创建于 1998 年，发布了 Netscape 浏览器套件源代码。其旨在利用互联网上成千上万的程序员的创造力，并推动浏览器市场上前所未有的创新水平。” 这个名字是 Mosaic) 和 Godzilla 的混成词。

Nginx

“许多技术人员都试图装酷，并将它念成‘n’‘g’‘n’‘x’。实际上，很少的一些人做点基本的调查工作，就可以很快发现该名称实际上应该被念成是“EngineX”，指的是功能强大的 web 服务器，像个引擎。”——Jean Sebastien Tougne

Perl

Perl 的创始人 Larry Wall 最初将他的项目命名为“Pearl”。根据维基百科，Wall 想给这种语言起一个有积极含义的简短名字。在 Perl 正式发布之前，Wall 发现了已有 PEARL) 编程语言，于是更改了名称的拼写。

Piet 和 Mondrian

“有两种编程语言以艺术家 Piet Mondrian 命名。一种叫做‘Piet’，另一种叫做‘Mondrian’。（David Morgan-Mar 写道）：‘Piet 是一种编程语言，其中的程序看起来像抽象绘画。该语言以几何抽象艺术的开创者 Piet Mondrian 的名字命名。我曾想将这种语言命名为 Mondrian，但是有人告诉我这会让它看起来像一种很普通的脚本语言。哦，好吧，我想我们不能都是深奥的语言作家。’”——Yuval Lifshitz

Python

Python 编程语言的独特名称来自其创建者 Guido Van Rossum，他是英国六人喜剧团体 Monty Python 的粉丝。

Raspberry Pi

Raspberry Pi 以其微小但强大的功能和对低廉的价格而闻名，在开源社区中是最受欢迎的。但是它可爱（和好吃）的名字是从哪里来的呢？在 70 年代和 80 年代，以水果命名的计算机是一种流行的趋势。苹果、橘子、杏……有人饿了吗？根据创始人 Eben Upton 的 2012 采访，“ 树莓派 Raspberry Pi ”这个名称是对这种趋势的致敬。树莓也很小，但却很有味道。名称中的“Pi”暗示着这样的事实：最初，该计算机只能运行 Python。

Samba

Server Message Block 用于在 Linux 上共享 Windows 文件。

ScummVM

ScummVM（《疯狂大楼》虚拟机的脚本创建实用程序）是一个程序，可以在现代计算机上运行一些经典的计算机冒险游戏。最初，它旨在玩用 SCUMM 构建的 LucasArts 的冒险游戏，该游戏最初用于开发《疯狂大楼》，后来又被用来开发 LucasArts 的其它大多数冒险游戏。目前，ScummVM 支持大量游戏引擎，包括 Sierra Online 的 AGI 和 SCI，但仍保留着名称 ScummVM。

有一个相关的项目 ResidualVM 之所以得名，是因为它涵盖了 ScummVM 未涵盖的“ 剩余的 residual ” LucasArts 冒险游戏。 ResidualVM 涵盖的 LucasArts 游戏是使用 GrimE（Grim Engine）开发的，该引擎最初用于开发 Grim Fandango，因此 ResidualVM 的名称是双关语。

SQL

“你可能知道 SQL 代表 结构化查询语言 Structured Query Language ，但你知道为什么它经常被读作‘sequel’吗？它是作为原本的‘QUEL’（ 查询语言 QUEry Language ）的后续（如 结局 sequel ）而创建的。”——Ken Gaillot

XFCE

XFCE 是由 Olivier Fourdan 创建的一个流行的桌面。它在 1996 年作为 CDE 的替代品出现，最初是 XForms 公共环境 XForms Common Environment 的缩写。

Zsh

Zsh 是一个交互式登录 shell。1990 年，普林斯顿大学的学生 Paul Falstad 写了该 shell 的第一个版本。他在看到当时在普林斯顿大学担任助教的 Zhong Sha 的登录 ID（zsh）后，觉得这个名字听起来像 shell 的好名字，给它起了这个名字。

还有更多的项目和名称还没有包括在这个列表中。请一定要在评论中分享你的收藏。

via: https://opensource.com/article/19/10/open-source-name-origins

作者：Joshua Allen Holm 选题：lujun9972 译者：laingke 校对：wxy

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

似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是 UCloud。在和 UCloud 技术专家的沟通中，我深深感受到这是一支极为自信、动手能力很强的技术团队。

近期，我在UCloud上海办公室采访了 UCloud 虚拟网络负责人徐亮，就如同我采访过的很多一线技术领军人物一样，徐亮给我带来的直接印象就是执着、朴实和认真。

说到自己擅长的网络技术领域，徐亮神采飞扬

在和他的谈话中，我听到了不少 UCloud 有趣的研发故事，让我对 UCloud 技术团队的动手能力有了更深的认识。尤其是， 当UCloud 所倡行的“客户为先”、“客户的需求就是我们的下一个产品”等理念从一个专注于前沿技术的技术领军人物的谈吐中汩汩冒出时，印象更深刻了。

转化：实验室技术能力 ➡️➡️➡️ 生产能力

我为什么认为 UCloud 的技术团队是一支动手能力极强，这得从他们的 25G 智能网卡项目说起。

众所周知，如何将实验室形成的技术能力转化成生产能力，需要很好的工程能力，25G 智能网卡从实验室到生产环境恰恰体现了这样的工程能力。

“去年我们将 25G 智能网卡产品投入到生产环境，实际上，UCloud 从 2016 年就开始跟踪这项技术。这期间我们测试了很多厂商的智能网卡，有的智能网卡的性能相当不错。但是阻碍我们将其投入生产环境的一个重要原因是，它和公有云所要求的热迁移的能力不兼容。所以，虽然这些智能网卡的性能很好，但是没有办法应用到公有云环境。”徐亮介绍道。

其实，业界一些公有云厂商很早就在借助这些智能网卡做加速，但是在处理热迁移的时候做不到用户的无感迁移，必须要用户手动修改虚机里面网络的配置。这虽然能够达到目的，但是对用户并不友好。对此，UCloud 秉持一向的态度：“我们一定要做到用户没有额外的负担，这样对用户来说才是最佳的方案，才是成熟的、用户友好的方案。”

据徐亮回忆，情况在 2017 年底出现了一个转机。彼时，Linux 内核社区开始讨论智能网卡如何能够无感的支持热迁移，UCloud 技术团队第一时间进行了深入的技术追踪和研究。从社区开始讨论和开发，最后到 2018 年 5 月份时该功能趋于稳定，才被接受到 Linux 的内核主线里。

“在发现该功能已经基本成熟后，我们马上就把这个补丁应用回 UCloud 的定制内核当中，跟智能网卡厂商一起研究，很快就在实验室完成了该产品。”徐亮接着谈到，“然后我们就开始在线上做公测。这个时候就非常体现我们的工程能力。”

在徐亮的团队将智能网卡投入生产环境时，虽然也发生了一些问题，但是就算在连固件都升级过两次的情况下、对用户的业务并没有产生太大的影响，我想这就是 UCloud 技术团队的工程能力一个重要体现——“我的固件都升级了，而用户业务不受影响。”

驱动：客户为先 ➡️➡️➡️ 工程能力

在我采访的 UCloud 技术人员中，徐亮并不是第一个提到“客户为先”、“客户的需求就是我们下一个产品”等理念的，在与 UCloud 技术副总裁杨镭、私有云和容器产品线负责人叶理灯等人的采访沟通中他们都曾提及这一贯彻于 UCloud 所有技术、产品研发中的理念。他们对于“客户为先”以及在产品的研发、技术专研中的践行，让我深信他们从骨子里认可这样一个价值观。可以说，“用户为先”的理念驱动着其工程能力的形成。

谈到他们的经典网络升级至 VPC 2.0 项目，也许你会理解我说的。

以“客户为先”为出发点

据我了解，UCloud 应该是全球唯一一家把经典网络升级到 VPC 2.0 网络的公有云厂商。在我和多位 UCloud 技术人员的接触中，这个项目被多次提及，它的实施可谓是历经周折，遇到的困难很多。

“我们的出发点是‘客户是不是有这个诉求？这件事情对客户来说是不是有好处？’如果是的话，那我们为什么不做呢？“。当问及项目出发点时，徐亮谈到。显然，如果能够透明的将经典网络升级至 VPC 网络，对于用户来说无疑是有诉求和好处，不需要自行迁移或是同时维护两个架构。但，UCloud 一开始低估了这个项目的难度。

徐亮说，“为什么这么难？因为一个默认的前提条件出现了变化——我们以前假设用户的 IP 是唯一的，这不光体现在网络产品上，还包括数据库产品、存储产品等，都会假设用户的 IP 是唯一的——在之前的经典网络时，该前提条件似乎是显而易见的。但在我们要升级到 VPC 2.0 时，我们突然发现这个 IP 变得不再唯一，由于不同的租户网络是完全隔离的，IP 完全是可以重复的。”

因此，这个项目不再是一个纯粹的网络项目，意味着 UCloud 平台上的所有产品都需要升级，都要支持这个重要变化，所以在工程上存在非常多的协调工作。这是一件非常、非常难的事，是一个涉及到全公司协调的能力。

“客户为先”驱动产品创新

VPC 2.0 项目过程中，徐亮团队还推出了许多创新产品，如 IPv6 地址转换。

公有云里面会有一些公共服务，比如说，像镜像服务、DNS 服务等，所有的客户都可能会访问这些公共服务，而有些客户的 IP 是彼此重叠的，只是 VPC 不同而已。传统上都是采用 NAT 的方式去做的，因为地址是相同的，肯定需要通过 NAT 翻译成不同的地址，然后再去访问公共服务。

但是，NAT 方式有两个问题，一个是公共服务在获取原地址时变得很复杂，它要用 TOA 或其它手段才能够提取出原地址。另外是这是一个有状态的网关，可扩展性会存在一定的问题，有状态的部分容易成为瓶颈，维护状态代价很大。

UCloud 在这方面做了一个创新——徐亮的团队把用户的地址和用户的 VPC 这两个部分信息组合起来，形成一个 128 位的 IPv6 地址，把用户的 IPv4 的请求无状态地转换成了 IPv6 请求，然后发送给这些公共服务。徐亮说，“我们这个无状态转换的思路，是非常创新的。对用户来说，得到的性能很好，同时不需要为此额外增加成本。”

就这样在“用户为先”的驱动下，UCloud 技术团队一点一点的完成了经典网络到 VPC 网络的升级，历时三年。

“我们的初衷就是从客户为先的角度出发，用我们的技术给客户带去价值，在这个基础上我们就认为这件事情值得就去做。”

自省：关于工程能力的三句话

关于对工程能力的理解，徐亮谈到了几句话： “先于客户发现问题”、 “先扛住再优化”、“这件事情能不能做到24小时止血”、“一周之内能不能拿出一个中期解决方案？”… 让我印象深刻，这也是 UCloud 技术团队的实践路线。

“先于客户发现问题”

据徐亮介绍，其团队做可编程交换机的过程中遇到一个非常隐晦的交换机芯片编译器的 BUG，它会发生哈希冲突，从而导致行为不可预期，但是这个问题在实验室是没办法复现出来。历时一个月时间，UCloud 通过在工程上引入全量测试的环节，提前发现了问题。

这件事情之后，徐亮的团队开发了一个新系统，对所有用户虚机点对点通信的信息进行统计，在做变更时就会针对通信过的场景做全量验证。通过这种方式来发现一些因为软件架构变化导致的问题，能够“先于客户发现问题”，在对客户业务没有产生影响的情况下去解决它。

“先扛住再优化”

发现问题第一时间不是去分析根本原因是什么，而要考虑怎样降低对客户的影响，这就是 UCloud 团队常说的“先扛住再优化”。比如说，智能网卡出现故障了，不会先修复智能网卡，肯定是先把用户的业务切走，让用户的业务正常，然后再想办法解决智能网卡的问题。

“这件事情能不能做 24 小时止血”

一旦发生故障就会做复盘，这时候UCloud技术团队最常说的一句话就是“这件事情能不能做24小时止血”。故障对客户是有影响的，我们要在24小时之内先推出一个方案，这个的方案能够让客户降低损失。不光是出现问题的客户，甚至是其他没有出现问题的客户，我们也要在24小时之内拿出一个方案，让这些问题不会影响到客户。

然后，再问‘一周之内能不能拿出一个中期解决方案？’，最后再考虑长期解决方案，长期方案有的时候就真的很长，比如说体系架构设计的不合理、需要进行重构。

结语

在和包括徐亮在内的多位 UCloud 技术领头人在深入沟通后，深切感受到这是一支极为自信、工程能力极强的技术团队，他们敢于尝试新技术，同时其工程能力能在给用户提高价值的同时，保证不出现问题，我相信这是 UCloud 技术团队自信的底气。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

2019 年 11 月初，数字天堂（北京）网络技术有限公司（下称：数字天堂）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（下称：两柚子）侵犯计算机软件著作权纠纷案，由北京高级人民法院二审作出终审判决。笔者曾密切关注该案，终审判决生效前，囿于关联代理关系的利益冲突，不便多谈。现将本案相关若干问题梳理成文，愿与各位探讨之。

本案之所以受关注，是因为本次计算机软件著作权侵权案涉及开源软件和 GPL 许可证，本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL 相关条款作了阐述，二审法院回避了 GPL 问题。本文，笔者基于本案事实和法院判决做些思考，分享给大家讨论。本文将仅对涉及开源软件及 GPL 许可证的内容进行论述，其他法律问题不作探讨。

案情简介

为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。

经过一审和二审对事实的调查和确认，两柚子认可：

1. 数字天堂是 HBuilder 软件的著作权人；
2. 数字天堂拥有 HBuilder 软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；
3. 两柚子的 APICloud 软件中对应插件源代码部分与涉案的三个插件具有同一性。

基于此，针对本著作权侵权控诉，两柚子抗辩理由只有 GPL 开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。

开源许可证是法律文件

一审法院虽未明确 GPL 许可证的法律效力，但在论述涉案三个插件是否受 GPL 协议限制时，默认了 GPL 许可证具有法律约束力。这一点虽然是意料之中，但毕竟开源理念和大部分开源协议来源于国外，且应用于开源社区特定人群，这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容，下文涉及 GPL 许可证的除特指许可证本身外，都以 GPL 协议指代。

法院虽然默认了 GPL 协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将 GPL 协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释，特别是关于 GPL 传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。

随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国 GPL 第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及 GPL 协议的关键问题进行阐述。当然，也不可能期待 GPL 问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。

关于一审认定的思考

既然法院确认了 GPL 协议的法律约束力，那么对 GPL 协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。

关于 GPL 协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无 GPL 许可证，据此认为涉案三个插件不属于 GPL 协议中所指应被开源的衍生产品或修改版本。

GPL 许可证中有关的原文如下：

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.——GPL 2.0

结合 GPL 协议条款和 GNU 官网对于 GPL 传染性的解释，一审法院这一认定是值得商榷的，就像你不能认为总部在西城的 A 公司与其在昌平拥有独立办公场所的分公司 B 是完全独立的，这需要从 A 和 B 之间的财务、人事、业务等是否独立为基础判断。

同理，GPL 模块 A 与模块 B 之间是否独立，绝对不能以A和B是否位于独立的文件夹中来判断，还是需要从 A 和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断。

插件相对于主程序是否独立，需要看：

1. 插件的使命，是否为该主程序而存在；
2. 插件与主程序的交互方式，如管道、队列、函数调用；
3. 交换消息的密切性 （ intimate communication ） ；
4. 是否有例外声明等。

一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里，两柚子并没有就涉案三个插件的独立性进行抗辩，而这一点对 GPL 是否构成传染非常关键，在一审中被告代理律师对 GPL 许可证条款的理解也存在局限。

关于二审认定的思考

首先，二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性，可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过，法院认为二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，即二审法院基于程序公正的角度考量不予准许。同时，二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性，这一点是值得商榷的，因为 GPL 中作品是否独立直接影响作品是否受GPL约束，进而直接影响本案关于侵权的认定。二审法院的否决理由，直接回避了可能对 GPL 传染性问题的讨论。

其次，二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于 HBuilder 开发工具软件中的其他程序独立运行，但针对不独立的插件却没有进一步讨论这种不独立是否能够进行 GPL 开源抗辩。也就是说，一审法院基于作品的独立认定 GPL 抗辩无效，二审法院采取了一审对 GPL 抗辩的意见，但却否定了作品的独立性这一前提。

是否为独立作品的认定直接决定作品是否属于 衍生作品 （ derivative work ） 或 修改作品 （ modified version ） ，进而直接影响是否受 GPL 约束。

当然，我们可以这样解读二审法院对于作品独立的认定，即 GPL 许可证里所说的作品的独立性，和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次，这是说的通的。但仔细阅读一审判决可知，法院在否决 GPL 抗辩中和赔偿额判定中对独立的认定是一致的，二审认可了一审对 GPL 抗辩部分的认定，却否决了赔偿额中对独立作品的认定，本身前后有矛盾嫌疑。

笔者认为，如果按照上述：GPL 传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设，至少二审中需要重新认定 GPL 传染性的问题，从而将两个维度的独立性认定区分开来。

关于两柚子诉求理由的思考

两柚子在二审中再次申请司法鉴定：

1. 涉案三个插件是否可以脱离 Eclipse 主体软件在 Windows 环境中独立运行；
2. 将涉案三个插件源代码编译为插件以验证插件能否在 Eclipse 主体软件中独立运行；
3. 任意删除 Hbuilder 软件目录下的一个或多个以“org．eclipse”、“org．apache”、“com．aptana”为前缀的文件或目录 JAR 文件以验证涉案三个插件能否正常运行……

关于这三个补充鉴定事项，首先，笔者认为两柚子或者其律师在开源上做足了工作，但其中依然存在问题。首先，插件独立于 Eclipse 主程序，并不一定需要插件可以脱离 Eclipse 主程序在 Windows 中独立运行。插件的独立性在于：插件有明确的功能，可用于特定的主程序，但不依赖于特定的主程序。最后，主程序脱离插件，应当且必须可以独立运行，并且不损失主程序本身的所有功能。

再看诉讼本身

基于以上认识，我们再回头看看案件本身。首先说明，因本案需要进行多处技术鉴定，笔者无法也没有精力一一取证，仅仅基于几个假设，再捋一下 GPL 相关的问题。笔者认为，关于本案 GPL 传染性的认定需要从 3 个方面来看：

1. Eclipse 主程本身；
2. 基于 Eclipse 主程序的 GPL 插件；
3. 涉案插件与主程序，以及涉案插件与上述 GPL 插件的关系。

为方便读者理解，引用数字天堂代理律所对一审结果评述的一张图。

（1）从 Eclipse 主程序看

APICloud 和 HBuilder 都是基于主程序 Eclipse 平台，包含第三方开源插件+各自自研插件组成的集成开发环境 IDE。

首先，主程序 Eclipse 是采用 EPL（Eclipse Public License）许可证公开，EPL 与 GPL 不兼容。即便是 2017 年 8 月发布的 EPL-2.0 版本虽然添加了次级许可证选项，但其与 GPL 依然是不兼容的。因此，HBuilder 作为下游产品，其对 Eclipse 的包装分发不能变更 Eclipse 许可证。

其次，针对插件来说，无非是拓展 Eclipse 某一特定的功能，任何非 Eclipse 本身的第三方插件，可以说对于 Eclipse 主程序来说都是非必须的。其第三方公司开发的 Eclipse 主程序的插件，按照 EPL 传染性的规定，一般不视为 EPL 的衍生作品，不受 EPL 约束。

最后，需要强调的是 EPL 虽然是弱 Copyleft 许可证，但其依然是类似于 GPL 的具有“传染性”的许可证，其在给予用户更大使用方便的同时，对自身软件的 Copyleft 保护依然很强。因此，下游软件开发者在处理 EPL 软件和 GPL 软件时，需要认真对待它们的兼容性问题。

（2）从 Aptana 插件看

Aptana 在 2006 年推出时，以 EPL 1.0 发布，并于 2017 年 9 月 21 日修改为 GPL3.0 和 APL（Aptana Public License ）双许可。APL 不是开源/自由软件许可证，可以认为是商业许可，但对于非分发的内部使用是免费的。

Aptana 作为主程序 Eclipse 的插件，由于 EPL 和 GPL 不兼容，Aptana 中的 GPL 插件要和以 EPL 许可的 Eclipse 主程序连接，必须在 GPL 许可证里作例外声明。毫无疑问，笔者在 Aptana 官网找到了例外声明，即关于独立作品的 GPL 传染性例外声明，以及聚合程序的 GPL 传染性例外声明。部分内容如下：

GPL Section 7 Exception

……which are conveyed to you by Appcelerator, Inc. and licensed under one or more of the licenses identified in the Excepted License List below (each an "Excepted License"), as long as:

1. you obey the GPL in all respects for the Program and the modified version, except for Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
2. all Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
3. are distributed subject to the Excepted License under which they were originally licensed, and
4. are not themselves modified from the form in which they are conveyed to you by Appcelerator, and
5. the object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections, on the same medium as the corresponding object code or executable forms of those sections, and are licensed under the applicable Excepted License as the corresponding object code or executable forms of those sections, and
6. any works which are aggregated with the Program, or with a modified version on a volume of a storage or distribution medium in accordance with the GPL, are aggregates (as defined in Section 5 of the GPL) which can reasonably be considered independent and separate works in themselves and which are not modified versions of either the Program, a modified version, or an Excepted Work.

If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from Appcelerator, Inc. Terms used but not defined in the foregoing paragraph have the meanings given in the GPL

从以上 GPL 例外中可以看出，Aptana 只是部分限定了“衍生作品”解释，也就是运行采用 GPL 许可证的 Aptana 与像 Eclipse 这样独立的程序交互不会发生传染，仅此而已。而如果修改 Aptana，将其他程序并入 Aptana Studio，或者将 Aptana 与其他程序进行整合的作品依然受到 GPL 协议约束。简单的说，加入 GPL 例外的 GPL 程序依然是 GPL 程序，这一点必须强调。关于这一点，Aptana 官网还专门有问题解答：

Can I add EPL'd plugins to Aptana Studio package and redistribute it?
No. You can only redistribute the unmodified binary versions of the EPL'd plugins that are part of Aptana Studio when distributing any of the GPL'd code. Adding any files to Aptana Studio package creates a derivative work, and since all derivative works need to be made GPL'd, you will not be able to add EPL'd (or any other license) plugins without contacting us for a commercial license.

What if I want to make changes to some of Aptana Studio's EPL'd plugins?
You are free to make changes to any of Aptana Studio EPL'd code under the terms of the EPL. To get those redistributed as part of Aptana Studio, we encourage you to contribute those back to Aptana so that we may evaluate your changes for inclusion back into the product.

Can I take unmodified Aptana Studio binaries and combine them with an Eclipse distribution?
No. Combining our GPL'd licensed code with any other product requires that the entire product be GPL'd, and therefore you cannot include any Eclipse distribution.

数字天堂认为，其 HBuilder 是包含 Eclipse 平台框架和众多插件的聚合体软件包，但其基于 Eclipse 开发且打包了 Aptana 中的 GPL 插件。从 GPL 协议对独立程序和聚合程序的规定来看，HBuilder 不被感染很难成立。一旦这种潜在传染可能性成立，数字天堂的 HBuilder 发行版就不满足合规性，其内部 EPL 和 GPL 软件不兼容。直白的说，就是整个发行版都可能受到 GPL 的约束。同时，这对于 Eclipse 是不可接受的，哪怕 EPL 是弱 Copyleft 许可证。这些问题，多是对 EPL 和 GPL 的 Copyleft 性质认识不到位导致。

（3）涉案插件与主程序及 Aptana 插件的关系

其实，以上两步分析一旦得出受 GPL 约束的结论，就不需要下面的分析了。为了完整，同时供未来类似案例参考，简单介绍。

进一步分析 Aptana 与数字天堂的涉案三个插件之间的关系，若涉案三个插件与 Aptana 有调用、通信、依赖关系，那么涉案三个插件必然会被 GPL 传染，也即是受 GPL 约束。

从以上三步的分析可见，在 GPL 传染性判断时，是否为独立作品是非常关键的。这也是我在前面法院判决部分要强调一审法院对独立的认定虽未必符合 GPL 本身解释，但至少前后一致。而二审法院对作品独立的认定甚至前后矛盾。

当然，笔者没太多精力去调查技术细节，点到为止，有兴趣的读者可以进行深入研究。

以上分析，是基于 Eclipse 作为中立主程序（即 Eclipse 主程序著作权人非诉讼参与人），GPL 插件与非 GPL 插件判定的情况，换一种场景以上判断完全或者大部分不成立。关于开源软件和 GPL 的问题还有很多需要注意的，限于篇幅不再进一步说明，对本案或对开源感兴趣的朋友可以找我单独讨论。

付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利分析布局、FTO 调查与风险应对、专利信息应用、开源软件风险与合规指导。

每周开源社区、市场和行业趋势。

作为我在具有开源开发模型的企业软件公司担任高级产品营销经理的角色的一部分，我为产品营销人员、经理和其他影响者定期发布有关开源社区，市场和行业趋势的定期更新。这里有该更新中我和他们最喜欢的四篇文章。

Kubernetes 傻瓜指南

• 文章链接

Kubernetes 已经发展出了新的特性，这使其成为企业软件的更好的容器平台。安全性和高级网络等元素已被纳入 Kubernetes 上游代码的主体，并且现在可供所有人使用。

然而，企业解决方案的其他方面总会有补充需求；比如日志记录和性能监控。这就是像 Istio 等辅助包发挥作用的地方，它带来了额外的功能，但是仍使 Kubernetes 的核心保持了合理的大小和特性集。

影响: 我总是发现，人们很容易把对技术发展的认识视为理所当然。当与你打交道的每个人都处于“最前沿”时，你的观点就会歪曲到这样的程度：你甚至可能会认为对最新的（此处插入首选技术）一无所知的人跟不上潮流，而实际上这并没有开始影响他们做自己需要做的事情的能力。那些人不是白痴；他们是我们的朋友、客户、合作伙伴、合作者和社区。

Gartner: 采用低代码开发之前应该考虑什么

• 文章链接

尽管专注于商业 IT 团队，但 Gartner 发现，一个日益重要的开发人员社区是需要快速开发简单应用程序或构建最低可行产品或多体验功能的核心 IT 专业开发人员。当应用程序领导者在传统的应用程序项目中使用低代码时，他们可能希望使用标准的 IT DevOps 自动化方法和低代码工具。

影响: 越来越多的用例和用户体验可以通过需要更少时间和技能来创建的应用程序来处理和交互。而低代码开发人员也可能会结合成一个具有他们自己的规范和亚文化的独特群体。

诺基亚认为云原生对 5G 核心至关重要

• 文章链接

诺基亚概述了 5G 的五个关键业务目标，这些目标只能通过云原生环境来实现。其中包括：更好的带宽、延迟和密度；通过网络切片将服务扩展到新的企业、行业和物联网市场；根据敏捷性和效率定义的快速服务部署；超越传统带宽、语音和信息传递的新服务；以及利用端到端网络获取更多收入的数字服务的出现。

影响: 在越来越多的事物连接到网络的情况下，这是最有意义的。4G 主要与越来越多的手机有关；只有当你开始连接其他所有东西时，5G 才是真正必要的。4G 意味着我们的手机上有更丰富的应用程序，而 5G 几乎与手机无关。

API：隐藏的业务加速器

• 文章链接

要想让组织成功地进行数字化转型，API 策略至关重要。从解锁有价值的数据到加快开发时间，API 都是数字时代的幕后英雄。那些已经尝试过 API 的人已经感受到了好处。例如，研究表明，使用 API 的企业中，有 53% 认为它们提高了生产力，而 29% 声称它们的收入增长是使用 API 的直接结果。当 API 被视为存在于一个项目之外的可发现和可重用的产品时，它有助于为持续的变更奠定灵活的基础。

影响: 隐藏的业务加速器实际上是这样一种思想，即功能应该以一种方式进行打包，使其能够在原始提供者没有预料到的环境中进行重新利用和组合。

我希望你喜欢这份上周给我留下深刻印象的列表，并于下周一回来了解更多开源社区、市场和行业的趋势。

via: https://opensource.com/article/19/12/technology-advice-and-other-industry-trends

作者：Tim Hildred 选题：lujun9972 译者：algzjh 校对：wxy

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