迎着北京雪后冷冽的空气，我专程参加了华为在钓鱼台国宾馆举办的华为 HDC.Cloud 大会预热沟通会。说实话，作为一个技术圈的跑会男人，我参加过林林总总的技术大会，但是还是第一次参加一个技术大会的会前沟通会，而且规模相当不小。

华为这样隆重的介绍这次将要在 2020 年 2 月 11 日至 12 日深圳举办的 华为开发者大会2020（Cloud），这让我心里对这次大会有了不少期许。

主持会议的是人称“茂总”的华为技术有限公司高级副总裁、Cloud & AI 产品与服务 CTO 张顺茂先生，这位可是一路从一线技术冲杀上来的技术型高管，所以整场沟通会显得坦率而真诚。

张顺茂先生

HDC.Cloud 的由来

华为这些年，作为国内顶级技术厂商，所举办的各种大型技术会议层出不穷。就开发者大会而言，早在 2015 年就召开了首届 HDC（Huawei Developers Congress），而在之后的 2016 - 2019 年，HDC 和华为的另外两个顶会 HCC 和 HNC 三会合一为 HC，HDC 原有内容被放在 HC 第三天的开发者专场。

茂总讲到，“在华为云底座上需要开发者生态，而且从历史发展和世界进步来看，开发者的重要意义是不言而喻的，在数字转型的时代，开发者对于产业生态更为重要，新的技术都需要开发者创造出来。”伴随着这些 ICT 技术的发展，华为对开发者以及开发者生态愈加重视，华为在其发布的沃土计划 2.0 中称，未来五年将投资 15 亿美元，携手社区和高校在全球发展开发者 500 万人！据《2018年欧盟工业研发投资排名》，在 2018 年，华为的企业研发投入就高达 113.34 亿欧元，全球排名第五。

在这种形式下，原本只是一天议程的 HC 开发者专场就不足以体现华为在技术开发领域的成绩和重视，因此，这次在深圳专门举办这场开发者大会，并且在两天的多轨议程中，包含多个会议、沟通、动手实践等丰富的活动，可谓是一场技术人员的盛宴。

事实上，华为重视技术，在业界已经是一种共识了，甚至华为连开发者大会都有两场：一场是这次在深圳 2 月份举办的 HDC.Cloud ，以 “.Cloud” 为后缀，突出企业级开发；而另外一场则是面向消费者技术领域的开发者大会也即将露出面纱。

一云两翼下的 HDC.Cloud

在 2019 年 HC 大会上，华为提出了“一云两翼双引擎+开放的生态“的计算产业布局。一云就是华为云，所有业务以云为主，向云上迁移，拥抱云、融入云、接受云。而两翼一个是智能计算，另一个则是智能数据和存储。“一云”和“两翼”的基础是通用计算处理器“鲲鹏”和人工智能处理器“昇腾”。

从历史发展和世界进步来看，开发者的重要意义是不言而喻的，在数字转型的时代，开发者对于产业生态更为重要，新的技术都需要开发者创造出来。HDC.Cloud最主要目的是汇聚开发者和产业伙伴，让基于昇腾、鲲鹏为底座的计算产业生态发展起来。

为谁盛开的 HDC.Cloud？

经常有人问为什么华为为什么能持续高速增长？甚至被美国加入实体清单之后，还能保持 18% 的增长。对此，茂总的理解是，“最主要是华为持续高强度的研发投入，让华为公司有了成长的动力。像汽车的发动机一样，只要有这样的动力，一些小坎挡不住前进的步伐，开发者是前进的引擎和动力，他们用代码在改变世界。”

作为一家国内知名的开源技术社区，我们很关注国内的开源技术生态的建设和发展，这两年也对主要由国内开发者和科技企业推动的开源项目进行了深入观察和数字分析。在今年我们刚刚发布《中国开源项目 Grank 分析报告（2019）》中，我们欣喜的看到国内有很多项目在活跃度、社区健康度上都取得了长足的发展。对比 2018 年的数据，无论是项目还是开发者的数据，都明显可以看到开发者在其中所扮演的积极角色。

开发者的 HDC.Cloud

正如这个大会的名称一样，HDC.Cloud 面对的就是开发者，不仅有 ISV 软件开发者，还有 IHV 硬件开发者和 SI 系统集成商的开发者。除了企业开发者之外，HDC.Cloud 还面对生态培养的高校、师生、科研机构，以及开源社区的开发者。

开发者参加这样的会议有什么收益呢？

如今，ICT 技术正在改变各行各业，随着数字经济、人工智能不断的推进，算力将成为新生产力，数据成为新生产资料，已经形成共识。当下，云、AI 将人类推向智能社会，5G 和 IoT 使得世界万物互联，而区块链正在重塑社会价值。

这些技术改变世界的愿景很美好，怎么样把它实现呢？这就需要开发者把这些愿景落到实处、落到产品和方案上。如何把这些技术转变成日常生活中可以用到的产品和方案，转变成企业创新进步的产品和方案，就需要开发者。这些工程师们是不是都会用最新的技术呢？比如说人工智能，很多企业说我们也要搞个什么样的人工智能，用数据挖掘一下，训练一下模型，但是招一个人工智能工程师很贵，因为这个技术掌握的人太少，怎么样让 AI 普惠，让大家都能用起来，就需要一个学习和培养的环境，需要一个方便使用的平台，华为这样的开发者大会就是提供这样的平台，让更多的人掌握它、学习它、使用它，能够创造出自己的人工智能产品。

华为开发者扶植政策

在沟通会当中，包括 Linux 中国在内的多家媒体和社区，从不同角度对华为开发者生态如何建设进行了提问，作为开发者和开发者社区如何参与到华为所描述出的开放生态当中？

茂总讲到，“我们面向四类开发者：一、企业合作伙伴开发者；二、个人开发者；三、初创企业开发者；四、高校和教研机构开发者。这四类开发者会涉及不同的权益，各自有所侧重。这些权益包括认证培训、技术支持、板卡支持等。从学习阶段到开发阶段，会有开发工程师、OpenLabs 和各地的创新中心支持你。比如说在北京成立了一个北京鲲鹏创新中心，在创新中心里面有工程师驻场，也有设备在那里，支持和帮助北京地区的开发者在这个地方进行自己的产品开发和服务。而产品上市后，华为还会提供市场开发基金进行支持，跟华为一起共享商机。甚至在最后的销售阶段也可以借助华为的地面部队，共享当地的商机、客户关系和渠道关系，这些都可以为开发者提供服务。”

像北京一样，在很多大城市华为都有鲲鹏创新中心。此外，在鲲鹏创新中心成立之前各地也有 OpenLabs，即便是个人开发者也可以去参加他们的活动。

华为这次举办 HDC.Cloud，将会发布一系列基于鲲鹏、昇腾 AI 的开发工具和开发套件，让开发人员——不仅仅是华为的开发人员，包括整个生态的开发人员——能够更快的把应用迁移过来，更快基于这些工具把自己的内容丰富起来，这也是一个长期的战略。

具体来说，华为有三个伙伴计划，都是以鲲鹏打头。它们分别是鲲鹏展翅伙伴计划、鲲鹏凌云伙伴计划、鲲鹏智数伙伴计划。

• 鲲鹏展翅是以盒子，比如说板卡、泰山服务器为主，可以给开发者提供服务和板卡支持。
• 鲲鹏凌云是面向开发者的服务。华为云有很多的基础服务，比如 ECS 早期是基于通用CPU 提供的通用计算服务；但是现在，ECS 下面跑的硬件设施不是 X86，在华为云上引用鲲鹏云服务的时候，就使用的是鲲鹏处理器。
• 鲲鹏智数是基于数据和存储领域展开，去年 11 月份华为专门发布了 HetuEngine 数据虚拟化引擎，围绕数据的全生命周期管理，帮助客户让数据更好用。该引擎后续也会开源。

从上面可以看到，华为在计算、数据、云三个领域给开发者提供一系列的政策和支持。

这次 HDC.Cloud 有什么值得期待的？

让我们言归正传，作为开发者，我们自然更关心这次 HDC.Cloud 会议上能有什么值得期待的收获。

这次于 2 月 11日、12 日在深圳召开的开发者大会是一个面向全球开发者分享、学习、交流、实践的最佳平台。预计会有 1 万 5 千多位开发者参会。大会里有主题演讲、专题演讲，大咖面对面，技术培训、CTO 圆桌、公开演讲、早午餐会等。茂总感慨道，“开发者来的时间不容易，我们把参会者每一分钟都充分使用起来，让他们每分钟都能学到东西，早餐时间也不要耽误，每个桌子有一个技术专题讨论，你对哪个技术感兴趣，就可以到哪个桌子吃早餐，跟技术大拿聊一聊。”

此外，这次 HDC.Cloud 包括还有黑客松大赛、创客行。在整个活动设计里面有 3 万平米的展区动手实验室，包括华为认证竞技场、最强 ICT 大脑、鲲鹏开发挑战赛、昇腾开发挑战赛、Codelabs 动动手指等，可以探索代码的无限可能。大家也可以现场参加开发者大赛和学习，获得 HCIE 认证的资格等。

当然，学习和了解新技术，总是要从最权威的大神身边学习，因此，这次出场都是华为的 IEEE 院士、大咖、天才少年等。大家也知道华为花几百万招了一些天才少年出来，这些天才少年到底做了什么？他们会自己出来跟大家讲他们的故事。还有 2012 实验室的扫地僧，这些扫地僧们会跟大家沟通，看看他们的武艺到底多么的高强。

按照议程，一共有 126 场专题演讲，最燃、最丰富的技术饕餮盛宴，都会在这儿。还有 8 场大师面对面和大家进行 ICT 产业技术、思想的最高峰直接对话。这些人都是首席科学家、IEEE 院士、行业知名架构师。此外，还有开源社区的各路领袖级的人物出场，包括 Linux 基金会执行董事 Jim Zemlin、 Apache 主席 Craig 、MySQL 之父 Monty 等都会来参加。

从透露的议程上看，有几个演讲题目颇为有趣，比如《DNA 存储：1 公斤如何容纳全世界 - 探索 DNA 存储的奥秘》、《华为云 ModelArts 平台上使用 MindSpore 实现 ResNet50 训练速度翻倍》、《如何实现从 x86 到鲲鹏平台 90% 代码自动迁移》、《如何在人形机器人上实现实时的动作识别和智能交互》等等。

不知道从什么时候开始，国内的技术大会也开始充分利用会议间歇的夜间为参会者们提供一些娱乐节目。在白天大家辛苦学东西之余，11 日晚上会安排有音乐电音节，让年轻的开发者们能够跳起来。

让我们期待在 HDC.Cloud 与大家相会~

以及，对 2019 年最受欢迎的 Kubernetes 文章的回顾。

你是怎么追踪一个广受欢迎的项目（如 Kubernetes）的发展轨迹？你是怎么了解它发展到什么程度了？如果你在为这个项目作贡献或加入了特殊兴趣组（SIG），可能你会在潜移默化中了解到它的发展轨迹，但如果你的全日工作不涉及到为 Kubernetes 作贡献，那么你可能需要一点关于未来的预测来帮助你了解。对于一个诸如 Kubernetes 的快速发展的项目，年末是回顾过去的一年和展望新的一年的最好时机。

今年，Kubernetes 取得了很大的进展。除了去查看源码、文档、会议笔记，你也可以去浏览博客。为了深入了解，我在 Opensource.com 上找到了 Kubernetes 排名前十的文章。通过这些文章，我们能了解开发者们更喜欢读和写哪些话题的文章。我们开始吧！

• 为什么数据科学家喜欢Kubernetes
• Kubernetes 机密信息和 ConfigMap 简介
• 怎样在 Kubernetes 上运行 PostgreSQL（译文）
• 为什么说 Kubernetes 是一辆翻斗车（译文）
• 安全扫描你的 DevOps 流程
• 在 Kubernetes 上部署 InfluxDB 和 Grafana 以收集 Twitter 统计信息
• 使用 Kubernetes 操作器扩展 PostgreSQL
• 使用 Kubernetes 控制器减少系统管理员的工作量
• 将 Kubernetes 带到裸金属边缘计算
• 为什么你不必担心 Kubernetes

首先，我要指明这些文章中有 5 篇是关于 Kubernetes 工作负载的扩展以及它们可以运行在什么场景。这些工作负载涵盖数据科学、PostgreSQL、InfluxDB、Grafana（不仅仅监控集群本身）和边缘计算。从历史角度看，Kubernetes 和容器都是在虚拟机上运行的，尤其是运行在由云提供的基础设施上时。抛开对于 Kubernetes 的兴趣因素，这也表明了终端用户们极度希望在裸机上安装 Kubernetes（参照 用 OpenShift 在裸机环境运行 Kubernetes）。

其次，也有很多开发者希望了解操作相关的知识以及 Kubernetes 的最佳实践。从 Kubernetes 操作器 到 Kubernetes 控制器，从 机密信息 到 ConfigMaps，开发者和运维人员都希望能找到简化部署和管理工作的最佳实践。我们经常纠结在怎么去修改配置文件或别人会怎么配置，而不去回头想想这些配置是怎么让应用部署运转的（不是怎么安装，也不是怎么运行 Kubernetes）。

最后，人们似乎对入门教程真的感兴趣。事实上，构建 Kubernetes 所需了解的信息太多了，以至于让人们望而却步，也使他们走了错误的路。流行度高的文章中有几篇讲述了为什么你需要了解用 Kubernetes 运行应用程序，而不仅仅是安装它。就像最佳实践类的文章一样，人们也通常不会回头分析在入门时他们应该在什么地方花费时间。我一直秉持的理念是，把有限的时间和金钱投入到如何使用某项技术上，而不是如何构建它。

2020 年对 Kubernetes 的 5 个预测

回顾了 2019 年的相关主题，这些主题告诉我们 2020 年将如何发展？结合这些文章中的观点，加上我自己的看法，我来分享下我对于 2020 年以及未来发展趋势的想法：

1. 工作负载扩展。我会关注高性能计算、AI/ML 以及使用操作器的有状态工作负载。
2. 更多的生产中的最佳实践，尤其是跟一些成熟的标准相关的，像 PCI、HIPAA、NIST 等等。
3. 提升免 root 和更安全的运行时类（如 gVisor、Kata Containers 等等）的安全性。
4. 在部署和开发者们共享应用时，把 Kubernetes 清单的更好的规范标准作为部署的核心要素。如 podman 生成 kube、podman 运行 kube，还有多合一 Kubernetes 环境，如 CodeReady Containers (CRC)
5. 一个前所未有的网络、存储和专业硬件（如 GPU 等等）供应商的生态系统，为 Kubernetes 提供 BoB（LCTT 译注：best of breed，单项最佳品牌）解决方案（在自由软件中，我们相信开放的生态系统好过垂直整合的解决方案）。

期待 Kubernetes 在新的一年里再创辉煌！

via: https://opensource.com/article/20/1/kubernetes-2020

作者：Scott McCarty 选题：lujun9972 译者：lxbwolf 校对：wxy

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

Linux 中国曾在 2018 年末参与了开源社发布的《2018 中国开源年度报告》的《数据篇 - Grank 篇》的撰写，并为此提出和开源了 Grank 模型。

时光飞逝，如今已是 2020 年，是时候对主要发源于或活跃于中国的开源项目们进行一次年终总结了，因此我们再一次协同开源社完成了这次的 Grank 分析，并将本报告的简化版本作为《2019 年中国开源年度报告》的一部分出现。

在 2019 年报告中，我们使用和 2018 年报告相同的模型进行分析。但与 2018 年报告不同的是，在 2019 年度报告中，我们引入了大量的企业项目和个人项目，整体分析项目数达到了 1200 余个，并对参与分析的项目进行了分离，按照其所属企业、个人等不同的角度进行分类，让读者能够更加明确不同项目、企业之间的关系。

在我们看具体数据之前，先看一下我们从这些数据中得到感受。

洞察

今年在进行 Grank 数据分析的过程中，我们发现了不少有趣的变化，一年时间，如此多的变化，也值得我们思考和讨论。

洞察一：文档类活跃度可达开发类项目的 10 倍

GitHub 项目上一直都有一些文档类的项目，比如各种 Awesome 、各种电子书。我们会发现， 这些项目经常会引起开发者讨论：XXX 到底能不能算做开源项目？。 GitHub 官方的态度是明确的，文档类项目 azure-docs 出现在了 GitHub 2019 年度开发者报告中。

近两年来，我们发现越来越多的企业，开始将自己的文档放置在 GitHub 上，与整个社区共同协作，构建更好的文档。在此次分析中，我们发现腾讯云文档、阿里云文档、PingCAP 等企业文档早已开始在 GitHub 上协作

当我们真正将文档类开源项目进行数据分析后，我们会发现，文档类项目得益于其低参与成本和学习成本，在项目的活跃度层面可以获得极高的评分，同样的原因，文档类项目也获得了极高的社区化程度。文档类项目已经逐渐成为开源项目中的一个非常重要的组成部分。这样的现象值得我们思考，在开源世界，是代码重要，还是社区重要？

今年的文档类活跃项目最为亮眼的项目，莫过于来自于 腾讯云的 tencentyun/qcloud-documents，此项目的活跃度远超其他项目，总活跃度达到 685.33 ，是同类项目第二名的 5 倍，是开发类项目第一名的 10 倍。

近两年，我们看到大量的企业开始将自己的企业项目文档放在 GitHub 与社区开发者共同协作，获取来自社区开发者的贡献。大量的企业文档类项目的出现，表现出了企业对于开源价值观的认同和投入。

洞察二：企业开源治理水平差异较大

在今年的分析过程中，我们将所有参与分析的账号进行企业级别的分类。通过分类后的数据，我们可以明显看出不同企业在开源治理上的水平和成果。

今年参与分析的的项目中，阿里巴巴的 GitHub 账号有 31 个（源自其开源项目官网），而国内其他一线互联网企业百度有 12 个账号、华为有 7 个账号、腾讯有 4 个账号、美团有 3 个账号。

这些账号背后，我们看出的是各企业对于开源的态度和治理能力。显然，拥有 31 个账号的阿里巴巴在治理能力上可能会受到质疑，但 31 个账号，换来的是阿里巴巴开源的生态和声势最为浩大。而账号更少，治理能力更强的腾讯、百度、华为、美团是否就做的更好呢？也不是。这些企业的账号维护的更好，但是，其开源项目的声量、体量却难以与阿里巴巴旗下的众多项目所抗争。

对于阿里巴巴来说，面临的问题是如何教育开发者，以正式、正规、合规的方式来运营、运作开源项目，而对于其他企业，面临的问题可能是如何激励开发者去做开源项目。

洞察三：程序员亚文化兴起

亚文化一直是主流文化的一个阴影，亚文化往往不为人所知，不为广泛群众所接受。但数据不会骗人。在 2019 年的年度报告中，我们评估了一个著名的项目：komeiji-satori/Dress。这是一个在 GitHub 上拥有 16K 星标，3.2K 复刻和 198 位贡献者的项目。

这个项目的数据，让我真正意识到，亚文化或许依然替代不了主流文化，但不代表亚文化就没有自己的存在价值和空间。 Dress 项目的诞生和发展，是亚文化向主流文化发声的存在。这些我们过去忽视的亚文化，正在以自己的方式，表达观点。

洞察四： JavaScript 生态不断扩大

“能被 JavaScript 所实现的，终将被 JavaScript 所实现”，过去这只是一个梗，但是在如今这个梗在开源项目领域中，不断的变成了现实。在今年的榜单中，我们看到其中出现了大量的 JavaScript 开源项目

JavaScript 得益于其脚本语言的特性和其简单易学的语法，在近几年获得了大量的关注度和开发者。而其无需编译，在浏览器环境可以直接运行的特性，也让 JavaScript 项目在活跃度的提升上占据了优势。相比于编译一次需要花费大量时间的 C++ 、Rust 项目，显然 JavaScript 优势十足。

洞察五：服务端相关开发依然非常重要

虽然 JavaScript 占据的席位越来越多，但是我们所熟悉的传统的服务端开发、服务端中间件等领域类依然是占据了更多的席位。在今年的活跃度榜单前 100 名中，50 个项目是服务端开发，占据了所有榜单的一半份额。不仅如此，数据库中间件项目 —— TiDB 占据了非文档类项目的活跃度榜单第一名、总活跃度榜单第三名。

对于开发者来说，虽然前端开源项目的声量赫然，但服务端开发项目依然是目前开源项目的主流。对于开发者来说，如果不愿意贡献 JavaScript 相关项目，服务端中间件项目会给你更多的选择。

洞察六： 各家布局物联网

今年由于拆分出了多个子榜单，所以也能够让我们更加清楚的看到不同的企业布局。今年的物联网榜单中，我们看到了华为 2015 年开源的 LiteOS 、阿里巴巴 2017 年开源的 AliOS-Things ，一直到 2019 年的的 TencentOS-Tiny（此项目因为开源时间短，活跃度也不高，总体健康度排名在 200 名左右，故没有出现在后续的榜单中），各家企业都在积极地布局物联网领域。在 2020 年，我们预期物联网领域还能诞生出重要项目。

数据

分析方案

由于软件开发项目的迭代周期、研发难度有所不同，各种不同类型的项目放在一个榜单内评比略显不公，因此，2019 年的 Grank 报告我们将参与分析的开源项目切分为以下四个类目，开源项目在同一类目下进行对比，具体分为以下四个类目：

1. 前端类：包括 iOS、Android、Web 大前端，主要为用户可感知的内容，常见为各种类库
2. 服务端类：包括 Java、Rust、PHP、Node.js、Python，主要为常见业务后台类库和中间件
3. 工程类：不限制语言，主要为可直接交付给 C 端客户使用的项目，不作为开发工具参与到开发流程中。
4. 文档类：主要是各类型的文档项目。
5. 物联网类：面向物联网场景下的服务端应用、操作系统等应用。
6. 其他类：无法被涵盖在上述分类范围的项目

前端类分析结果

榜单情况

项目点评

ant-design/ant-design

这是一个“服务于企业级产品的设计体系”，是由蚂蚁金服体验技术部采用 React 封装的一套组件库。同时，也是去年的 Grank 评分的第一名。 Ant-Desgin 项目在整体的大方向上于去年并没有太大的区别，甚至从数据的角度上来，2019 年 Ant-Design 有更多的数据更新，保持其一贯优秀的活跃度与社区化程度。

tencent/omi

Omi是一个基于 Web Components 并支持 IE、小程序端的前端跨平台框架。

从数据上来看， Omi 项目的活跃度从 2018 年 9 月开始，有大幅度提升，并在 2019 年年初达到了数据的顶峰。在社区化程度方面，从 2019 年年中开始，其社区活跃度出现了下降的趋势，猜测可能是其在内部拥有了更大的话语钱，致使更多的企业内部开发者开始参与到 Omi 项目的开发。

elemefe/element

Element 是由饿了么前端团队开源的 Vue UI 框架。从项目活跃上看， Element 近年来的更新乏力，略显颓势。整个项目开始逐渐走向减少维护的阶段。

服务端类分析结果

榜单情况

项目点评

pingcap/tidb

TiDB 项目是 PingCAP 公司的明星项目，是一款定位于在线事务处理/在线分析处理融合型开源数据库产品。

从数据上来看，TiDB 项目近年来的活跃度不断攀升，与之成为鲜明对比的，是其项目的社区活跃度的不断下降。不过，PingCAP 是业界非常典型的开源企业，其协作模式是所有开发人员通过 GitHub 进行协作，对于合适的开发人员，PingCAP 会选择提供其职位，允许其远程办公，以这样的方式来吸收社区的优秀开源力量，其社区化程度不断下降也实属正常。毕竟，优秀的开发者都被 PingCAP 转化为正规军，也不失为一个好的方法。

apolloauto/apollo

apollo 是百度开源出来的自动驾驶解决方案，从 2017 年开源至今，已经迭代至第 5 个版本。

apache/incubator-shardingsphere

shardingsphere 是由京东数科捐赠给 Apache 的分布式数据库中间件解决方案，其中包含了 Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar 三款独立的产品。

工程类分析结果

榜单情况

项目点评

diygod/rsshub

RSSHub 是一个帮助用户将各种各样的内容转化成 RSS 的工具，今年也是他的第一次上榜，RSSHub 以 23 的活跃度积分位列榜单 12 名。

作为一个个人项目，RSSHub 可以说做的是非常棒了，而且，RSSHub 的社区化做的非常好，一直处在高位， 拥有 300 位贡献者。

ant-design/ant-design-pro-site

文档类分析结果

榜单情况

项目点评

tencentyun/qcloud-documents

此项目为腾讯云文档，一个令人惊讶的项目，拥有 543 个贡献者和 119441 个提交 ，平均更新频次为 5 分种/次，有非常惊人的高频维护，估计是腾讯云将其整个文档放置在 GitHub 上进行开放协作，同时，所有的内部合作，都需要通过 GitHub 来完成。

此项目虽然活跃度高，由于项目的贡献指南并未说明，绝大多数开发者没有明确的规范参与到项目的更新。

lctt/TranslateProject

此项目为归属 Linux 中国旗下的翻译组主仓库，该项目拥有 464 名贡献者和 47776 个提交 以及 1.5k 星标 ，平均更新频次为 2 小时，更新频次较高。

此项目拥有完善的贡献说明，对于新手开发者来说，更加的友好，对于无法参与到开发阶段的开发者，可以考虑从翻译开始。

xitu/gold-miner

此项目为掘金翻译计划的官方仓库 ，来自社区的开发者们在一个仓库 上协作，贡献自己的翻译文章，该项目拥有 417 名贡献者和 9754 个提交，以及超过 24.9K 的星标。

物联网类分析结果

榜单情况

项目点评

rt-thread/rt-thread

RT-Thread 是一个 2006 年创建的项目，十余年来专注于物联网实时操作系统。其项目自 2018 年起，开始出现明显的活跃度增加。回望 2017 、2018，物联网生态企业和产品的蓬勃发展，让开源项目也随之获得了大量的关注度，项目维护团队、社区开源爱好者的参与，让 RT-Thread 能够跑的更快。

liteos/LiteOS

LiteOS 是华为开源的物联网操作系统，从 2015 年发布，到 2019年结束，LiteOS 的各项数据有着明显的变化。从 2017 年的不怎么维护，到 2018 年的迅猛发展，再到 2019 年的归为平淡，从某种角度来说，LiteOS 颇具 KPI 项目的潜质。而社区化程度的低位，也会让用户去思考，这个系统是否值得我去使用？

alibaba/AliOS-Things

AliOS-Things 源自阿里巴巴，自 2017 年开源以来，项目总体来说，维护的节奏比较平稳，从初期的大幅度维护，到后期的小幅度维护。从活跃度的角度来看，是一个不错的项目，不过，社区化的变化，可能是由于 AliOS-Things 在内部的权重变重，更多的企业开发者参与到项目中来，去推进项目的进度。

其他类分析结果

榜单情况

项目点评

996icu/996.ICU

996.ICU 项目作为 2019 年现象级的一个项目，一度得到了社会和社区的广泛关注，但是由于种种原因，这个项目的消亡也很快。不胜叹息。

活跃度总榜前 100 名

致谢与反馈报告问题

由于时间有限，本次报告仅收录部分项目，如果其中存在数据错误或希望补充收录，请通过 邮件 联系我们。

如果报告撰写过程中出现文字错误等问题，你可以直接访问 GRank 仓库，提交 PR 修正。

本次数据分析所引用的企业账号的部分数据源自《InfoQ:中国互联网公司开源项目调研报告》。

附录

附录一 研究方法综述

Grank 是本报告制定的一个指数，用于综合评估一个开源项目、开源组织的健康程度。

Grank 模型介绍

我们认为，一个健康的开源项目应该体现为以下两个方面：

• 项目的活跃度趋势
• 项目的社区化（去中心化）程度

而这两个方面分别有多个因素组成：

活跃度和活跃度趋势

项目的活跃度，我们定义为项目的提交数、 拉取请求数和贡献者数（其它数据，如代码行数、文件数、提案数、复刻数、星标数，要么是权重相对低得多，要么是代表意义不够确定，此处忽略不计入模型）。

但是，对于不同的项目，其横向比较其活跃度，或有不同的活跃度形态，或不具备可比性。很难说一个项目比另外一个项目的提交数高，而拉取请求（PR）数低代表的确切含义。因此我们不认为对不同项目的这些数据进行绝对值的比较有太多的科学意义。

所以，我们认为一个项目本身的活跃度变化的趋势和幅度，会更有项目间比较的意义。

如果以三维空间来描述一个项目的活跃度，以提交数、拉取请求数、贡献者数为三维，可以确定在某个时间点某个项目的坐标，那么计算一段时间内，该坐标点的移动轨迹和速率，可以真实的反映该项目的活跃度趋势。

考虑到按周工作的作息时间的普遍影响，我们以一个工作周作为一个时间采样点，然后计算连续的几周内该坐标的移动速率。这反映了该项目的发展速度。

社区化程度

开源诞生于社区，繁荣于社区，根植于社区，虽然现在大型组织、商业公司也纷纷投身于开源生态，但是我们认为，开源项目的生命力仍然在于社区。我们并不否认机构、商业公司对开源的巨大贡献和影响力，但是如果一个开源项目变成了一家或几家大企业的私人游戏，其必然失去开源项目的生命力，它或许会在商业上取得成功，但是那个成功不是开源项目的成功模式。

因此，我们认为需要有一个评估开源项目的社区化（去中心化）程度的指标。项目（尤其是软件项目）的一个重要属性是开发人员的社区化身份，因此，我们以实际向项目贡献了代码的人员的社区化离散程度来评估项目的社区化程度。

每个参与项目开发的人员均有其身份属性，这个身份可能是企业雇佣身份，也可能是社区志愿者身份。我们通过对项目的提交中的提交者数据进行收集，然后根据开发人员的身份信息、邮件后缀等依优先级来判断其所属身份。然后对这些信息进行聚类，以一个离散评估模型来评估该数据集的离散程度。

虽然项目越中心化，其发展风险越高，但是，并不是社区化程度越高的项目就越健康，过于离散的项目也容易出现项目分裂、迭代缓慢等问题。这显然是存在一个适当的区域。

通过上述两个指数，我们可以对项目进行象限划分，以“项目活跃度”和“社区化程度”为两个象限轴。

附录二 数据采集方式、工具与时间

• 数据采集方式：基于 Github Developers API V4 进行数据抓取
• 数据采集所用工具：https://github.com/LCTT/Grank
• 数据抓取时间范围： 2017 年 1 月 1 日 ～ 2019 年 12 月 31 日

附录三 参与分析账号

企业及组织账号

百度

阿里巴巴

腾讯

华为

美团

360

小米

PingCAP

有赞

京东

字节跳动

RT-Thread

网易

滴滴出行

唯品会

武汉深之度

hyperf

微众银行

SwiftOldDriver

SwiftGGTeam

豆瓣

Linux 中国

studygolang

涛思数据

携程

去哪儿

当当

个人账号

在 Github 上关注者数大于 10000 的账号。

• 996icu
• diygod
• ruanyf
• yyx990803
• michaelliao
• daimajia
• JacksonTian
• Trinea
• phodal
• stormzhang
• cloudwu
• lifesinger
• astaxie
• onevcat
• justjavac
• breakwa11
• RubyLouvre
• hongyangAndroid
• laruence
• ibireme
• bailicangdu
• bestony

好吧，你可能会发现从最佳 Linux 发行版列表中选择一个发行版很容易，但是，将两个类似的 Linux 发行版进行比较通常会令人困惑，就像 Pop!\_OS 与 Ubuntu 一样。

有趣的是，Pop!\_OS 是基于 Ubuntu 的。那么，Pop!\_OS 和 Ubuntu 之间有什么区别呢？为什么要从中选择一个呢？

在本文中，我将比较 Pop!\_OS 和 Ubuntu（两者都是我的最爱）。

注意：你可能会发现一些武断的观点，而本文只是一份比较的参考。随着 Linux 发行版的不断开发和更新，随着时间的流逝，很多事情都会改变。

比较 Ubuntu 和 Pop!\_OS

发现相似之处可帮助你区分其他差异之处。因此，让我们从一些明显的相似之处开始。

就像我提到的，Pop!\_OS 是基于 Ubuntu 之上的 Linux 发行版。因此，当你使用 Pop!\_OS 时，你将获得使用 Ubuntu 的所有好处（从技术上说，其核心是一样的）。

它们都默认带有 GNOME 桌面环境，因此它们具有相似的用户界面（UI）。

在不讨论所有底层差异的情况下，我将在这里重点介绍一些重要的差异。

用户体验及主题

许多用户认为 Pop!\_OS 只是具有不同外观的 Ubuntu。

根据我的经验，我觉得这并非完全正确。

是的，它们俩都很喜欢 GNOME 桌面环境 —— 但是，Pop!\_OS 让人感觉更加优美。

除了外观之外，Ubuntu 还通过添加程序坞和其他一些小花巧来定制了 GNOME 的体验。如果你喜欢定制的 GNOME 体验，可能会发现它更好。

但是，如果你更喜欢纯粹的 GNOME 体验，Pop!\_OS 默认情况下为你提供的就是这样。

在你亲自尝试之前，我无法说服你。但是，Pop!\_OS 中的总体配色方案、图标和主题可以说是令人愉悦的高级用户体验。

这可能是一个主观的事情，但这是我所观察到的。你还可以查看 Ubuntu 19.10 的视频教程，亲自感受一下。

易于安装第三方应用

Ubuntu 非常重视 Snap 软件包。这增加了它提供的应用程序的数量。

但是 Snap 软件包存在一些重要的问题。它们占用了过多的磁盘空间，并且启动要花费大量的时间。

这就是为什么我更喜欢使用应用程序的 APT 版本的原因。

我为什么要说这个呢？

因为 Pop!\_OS 具有其自己的官方 PPA，并已默认启用。你会在此处找到一些有用的应用程序，例如 Android Studio、TensorFlow。无需下载 Android Studio 的 1GB 大的 Snap 程序包。只需使用 apt-get install就可以了。

预装应用

对于某些人来说，它可能不是最大的问题，但是拥有大量预安装的应用程序可能会影响体验和性能。即使不影响性能，某些用户也只喜欢较少的预装应用程序。

与 Ubuntu 相比，Pop!\_OS 捆绑了更少的默认应用程序（潜在地减少了胖软件）。

再一次提醒，这是主观的看法。如果你希望预安装更多应用程序，则可以考虑使用 Ubuntu 而不是 Pop!\_OS。

Snap 软件包支持

对于熟悉 Snap 程序包的用户来说，Ubuntu 的软件中心是比 Pop!\_OS 商店更好的解决方案，因为你可以在软件中心中列出 Snap 程序包。

你无法在软件中心中过滤 Snap 软件包，但是当你在软件中心中发现一个 Snap 软件包（查看应用程序来源的详细信息为 “Snap store”/“Snapcraft”）时安装它就更容易了。

可能你会感到困惑，Pop!\_OS 也确实支持 Snap 软件包。但是，你不会在 Pop!\_OS 商店中找到它们，这是唯一的区别。

如果不确定什么是 Snap 软件包及其功能，可以查看我们的文章《在 Linux 上安装 Snap 应用》。

单独的 NVIDIA/AMD ISO 文件

从技术上讲，它不是内部比较的一部分，而是某些用户关心的一个因素。

因此，值得强调的是 Pop!\_OS 提供了单独的 ISO。一个用于带 NVIDIA 显卡的系统，另一个用于带/不带 AMD 显卡的系统。

使用 Ubuntu 19.10，你可以在 Ubuntu ISO 上获得 NVIDIA 驱动程序，但 AMD 显卡没有这个。

可靠性与问题

毫无疑问，这两个发行版都适合初学者，并且相当可靠。如果你想要更好的可靠性和更少的问题，则可能希望一直使用长期支持（LTS）版本。

当出现新版本的 Ubuntu 时，Pop!\_OS 将在其上开发，并有可能解决用户在 Ubuntu 原始发行版上遇到的问题，然后再进行新的升级。这给它们带来了一点优势，但这没什么实质性的不同，因为这些修复最终都可以运用于 Ubuntu。

性能

性能将高度取决于你所安装的内容以及所安装的硬件配置。

除非你有一个超级旧的系统，否则这两个发行版似乎都表现良好。

我的机器是 i5-7400 处理器和 16GB 的 RAM（带有 GTX 1050ti 显卡），我发现两种发行版上的体验都足够好。

当然，你可以手动进行一些优化调整以满足要求——无论它们中的哪个不满足你的硬件配置。

但是，如果你想使用 System76 笔记本电脑，那么 Pop!\_OS 将可以证明自己是 Linux 领域的苹果，因为 Pop!\_OS 是针对其硬件量身定制的，与 Ubuntu 有所不同。

硬件兼容性

在比较其他 Linux 发行版时，这绝对是要考虑的事情。但是，在这种情况下，实际上并没有太大的区别。

你可能会考虑 Pop!\_OS 一直在使用较新的硬件配置，因为他们主要是为他们的笔记本电脑量身定制具有各种配置的 OS。而且，这只是一个观察，而不是事实。

结语

我知道在不亲自尝试的情况下从两个流行的 Linux 发行版中选择一个并不容易。如果可能的话，我建议你在进行比较的同时尝试两者，以供参考。

你在这两者之间有何选择？我在比较中错过了什么吗？在下面的评论中让我知道。

via: https://itsfoss.com/pop-os-vs-ubuntu/

作者：Ankush Das 选题：lujun9972 译者：wxy 校对：wxy

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

Unix 时间（又称为“ 纪元时间 epoch time ”）是自 1970 年 1 月 1 日以来经过的秒数。当 Unix 即将 50 岁时，让我们看一下让内核开发人员担心的地方。

对于 Unix 而言，2020 年是重要的一年。在这一年年初，Unix 进入 50 岁。

尽管 Unix 的某些早期开发早于其“纪元”的正式开始，但 1970 年 1 月 1 日仍然是 POSIX 时间的零点，也是公认的 Unix 的万物之始。自那一刻算起，2020 年 1 月 1 日将是其 50 周年。（LCTT 译注：实际上，在 1971/11/3 出版的第一版《Unix 程序员手册》中，将 1971/1/1 作为 Unix 纪元的开始，并且一秒钟记录 60 个数，但是后来发现这样 32 位整型数字只能记录两年多，后来这个纪元被一再重新定义，改为从 1970/1/1 开始，每秒 1 个数。）

Unix 时间与人类时间

就人类时间而言，50 年是很重要的。就 Unix 时间而言，50 年没有什么特别的。48.7 年同样重要。

Unix（包括 Linux）系统将日期/时间值存储为自 1970-01-01 00:00:00 UTC 以来经过的秒数（32 位整型）。要确定自该时间以来经过了多少秒钟，看看 Unix 时间值是什么样子，你可以发出如下命令：

$ date +%s
1576883876

％s 参数告诉 date 命令将当前日期/时间显示为自 1970-01-01 开始以来的秒数。

Unix 系统可以管理多少时间？

要了解 Unix 系统可以容纳多少时间，我们需要查看 32 位字段的容量。可以这样计算：

$ echo '2^32' | bc
4294967296

但是，由于 Unix 需要容纳负数，因此它会为数字的符号保留一位，从而将其减少为：

$ echo '2^31' | bc
2147483648

并且，由于 Unix 计数以 0 开头，这意味着我们有 2,147,483,648 个值，但最大的可能值为 2,147,483,647 个。Unix 日期/时间值不能超过该数字——就像汽车上的里程表可能不能超过 999,999 英里一样。加 1 该值就变为了 -2147483648。（LCTT 译注：此处原文描述有误，已修改。在达到最大值之后，即 2038/1/19 03:14:07，下 1 秒导致符号位变为 1，其余 31 位为 0，即 -2147483648，时间变为 1901/12/13 20:45:52，这就是 Y2K38 问题。）

一年有多少秒？

大多数年份的秒数可以这样计算：每天的小时数乘以每小时的分钟数乘以每分钟的秒数乘以一年中的天数：

$ expr 24 \* 60 \* 60 \* 365
31536000

在闰年，我们再增加一天：

$ expr 24 \* 60 \* 60 \* 366
31622400

（LCTT 译注：Unix 时间将一天精确定义为 24 * 60 * 60 = 86400 秒，忽略闰秒。）

Unix 将如何庆祝其 50 岁生日？

2020 年 1 月 1 日中午 12:00 是纪元时间的 1577836800。这个计算有些棘手，但主要是因为我们必须适应闰年。自该纪元开始以来，我们经历了 12 个闰年，从 1972 年开始，到上一个闰年是 2016 年。而且，当我们达到 2020 年时，我们将有 38 个常规年份。

这是使用 expr 命令进行的计算，以计算这 50 年的秒数：

$ expr 24 \* 60 \* 60 \* 365 \* 38 + 24 \* 60 \* 60 \* 366 \* 12
1577836800

前半部分是计算 38 个非闰年的秒数。然后，我们加上闰年的 366 天的类似计算。或者，你可以使用前面介绍的每年秒数，然后执行以下操作：

$ expr 31536000 \* 38 + 31622400 \* 12
1577836800

这种跟踪日期和时间的方式使 Unix 系统完全不受 Y2K 恐慌的影响，1999 年末人们开始担心进入 2000 年会对计算机系统造成严重破坏，但是实际遇到的问题比人们担心的少得多。实际上，只有以两位数格式存储年份的应用程序才会将年份变为 00，以表示时间倒退。尽管如此，许多应用程序开发人员还是做了很多额外的繁琐工作，以确保 2000 年到来时，他们的系统不会出现严重问题。

Unix 时间何时会遇到问题？

在 2038 年之前，Unix 系统不会遇到 Y2K 类型的问题，直到如上所述存储的日期将超过其 32 位空间分配。但这距离现在已经只有 18 年了，内核开发人员已经在研究如何避免灾难。但现在开始恐慌还为时过早。

2038 年的问题有时称为 Y2K38 问题。我们必须在 2038 年 1 月 19 日星期二之前解决这个问题。如果问题到时候仍未解决，则该日期之后的系统可能会认为是 1901 年。解决该问题的一种方法是切换为日期/时间信息的 64 位表示形式。有些人认为，即使那样，也会有比听起来更复杂的问题。无论如何，恐慌还为时过早。并且，与此同时，也许在新年前夜演唱了《Auld Lang Syne》之后，你可以向 Unix 唱《生日快乐》歌了。Unix 50 岁了，这仍然是大事。

（LCTT 译注：建议阅读一下 Unix 时间的维基百科页面，有更多有趣和不为人知的信息。）

via: https://www.networkworld.com/article/3511428/unix-is-turning-50-what-does-that-mean.html

作者：Sandra Henry-Stocker 选题：lujun9972 译者：wxy 校对：wxy

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

我们邀请 Opensource.com 的 DevOps 团队，希望他们能够谈一谈作为 DevOps 内向者的休验，同时给 DevOps 外向者一些建议。下面是他们的回答。

我们邀请我们的 DevOps 团队 谈一谈他们作为一个内向者的体验，并给外向者们一些建议。但是在我们开始了解他们的回答之前，让我们先来定义一下这些词汇。

“内向者”是什么意思？

内向者通常指的是一部分人群，当他们和别人相处的时候，会使他们的能量耗尽，而不是激发他们更多的能量。当我们思考我们是如何恢复能量时，这是一个非常有用的词汇：内向者通常需要更多的独处时间来恢复能量，特别是和一群人在一起很长时间后。关于内向者的一个非常大的误解就是他们一定是“害羞的”，但是科学表明，那不过是另一种不同的性格特征。

内向性与外向性是通过 Myers Briggs 类型指标 而为人所知的，现在也常常被称作一个 光谱 的两端。虽然这个世界看起来好像外向者比内向者要多，但是心理学者则倾向于认为大部分人在光谱上的位置是落在 中间性格或偏内向性格的。

现在，我们来看看问答。

DevOps 技术主管可以通过哪些方式来让内向者感觉他们是团队的一部分并且愿意分享他们的想法？

“每个人都会不大一样，所以观察敏锐就很重要了。从 GitLab 过来的一个人告诉我，他们的哲学就是如果他们没有提供任何意见，那么他们就是被排除在外的。如果有人在一个会议上没有提供任何的意见，那就想办法让他们加入进来。当我知道一个内向者对我们将要讨论的会议论题感兴趣的时候，我会提前请他写一些书面文本。有非常多的会议其实是可以避免的，只要通过把讨论放到 Slack 或者 GitLab 上就行了，内向者会更愿意参与进来。在站立会议中，每个人都会交代最新的进展，在这个环境下，内向者表现得很好。有时候我们在其实会议上会重复做一些事情，仅仅是为了保证每个人都有时间发言。我同时也会鼓励内向者在工作小组或者社区小组面前发言，以此来锻炼他们的这些技能。”—— 丹·巴克

“我觉得别人对我做的最好的事情，就是他们保证了当重大问题来临的时候，我拥有必要的技能去回答它。彼时，我作为一名非常年轻的入伍空军的一员，我需要给我们部队的高级领导做状态简报的汇报。我必须在任何时候都有一些可用的数据点，以及在实现我们确立的目标的过程中，产生延误以及偏差的背后的原因。那样的经历推动着我从一个‘幕后人员’逐渐变得更加愿意和别人分享自己的观点和想法。”—— 克里斯·肖特

“通过文化去领导。为你的同僚一起设计和尝试仪式。你可以为给你的小组或团队设计一个小的每周仪式，甚至给你的部门或组织设计一个年度的大仪式。它的意义在于去尝试一些事物，并观察你在其中的领导角色。去找到你们文化当中的代沟以及对立。回顾团队的信仰和行为。你能从哪里观察到对立？你们的文化中缺失了什么？从一个小陈述开始‘我从 X 和 Y 之间看到了对立’，或者‘我的团队缺少了 Z’。接着，将代沟与对立转换为问题：写下三个‘我们如何能……(How might we’s, HMWs)’。”—— 凯瑟琳·路易斯

“内向者不是一个不同的群体，他们要么是在分享他们的想法之前想得太多或等得太久的一些人，要么就是一些根本不知道发生了什么的人。我就是第一种，我想太多了，有时候还担心我的意见会被其他人嘲笑，或者没有什么意思，或者想偏了。形成那样的思维方式很难，但它同时也在吞噬着我学习更好事物的机会。有一次，我们团队在讨论一个实现问题。我当时的老大一次又一次地问我，为什么我没有作为团队中更具经验的人参与进来，然后我就（集齐了全宇宙的力量之后）开口说我想说的大家都已经说过了。他说，有时候我可以重复说一次，事情纷繁，如果你能够重复一遍你的想法，即使它已经被讨论过了，也会大有裨益。好吧，虽然它不是一种特别信服的方式，但是我知道了至少有人想听听我怎么说，它给了我一点信心。

“现在，我所使用的让团队中的人发言的方法是我经常向内向的人求助，即使我知道解决方法，并且在团队会议和讨论中感谢他们来建立他们的自信心，通过给他们时间让他们一点一点的从他们寡言的本性中走出来，从而跟团队分享很多的知识。他们在外面的世界中可能仍然会有一点点孤立，但是在团队里面，有些会成为我们可以信赖的人。”—— 阿布希什克·塔姆拉卡尔

“我给参加会议的内向者的建议是，找一个同样要参加会议的朋友或者同事，这样到时你就会有人可以跟你一起舒服地交谈，在会议开始之前，提前跟其他的与会者（朋友、行业联系人、前同事等等）约着见个面或者吃顿饭，要注意你的疲劳程度，并且照顾好自己：如果你需要重新恢复能量，就跳过那些社交或者夜晚的活动，在事后回顾中记录一下自己的感受。”—— 伊丽莎白·约瑟夫

和一个内向者倾向的同事一起工作时，有什么提高生产效率的小建议？

“在保证质量时，生产效率会越来越具备挑战性。在大多数时候，工作中的一个小憩或者轻松随意的交谈，可能正是我们的创造性活动中需要的一个火花。再说一次，我发现当你的团队中有内向者时， Slack 和 Github 会是一个非常有用的用于交换想法以及和其他人互动的媒介。我同时也发现，结对编程对于大部分的内向者也非常有用，虽然一对一的交流对于他们来说，并不像交税那么频繁，但是生产质量和效率的提升却是重大的。但是，当一个内向者在独自工作的时间，团队中的所有人都不应该去打断他们。最好是发个邮件，或者使用没有那么强的侵入性的媒介。”—— 丹·巴克

“给他们趁手的工具，让他们工作并归档他们的工作。让他们能够在他们的工作上做到最好。要足够经常地去检查一下，保证他们没有走偏路，但是要记住，相比外向者而言，这样做是更大的一种让人分心的困扰。”—— 克里斯·肖特

“当我低着头的时候，不要打断我。真的，别打断我！当我沉浸在某件事物中时，这样做会造成我至少需要花费两个小时，才能让我的大脑重新回到之前的状态。感觉很痛苦。真的。你可以发个邮件让我去有白板的地方。然后从客户的角度而不是你的角度——通过画图的方式——分享下有什么问题。要知道，可能同时会有十几个客户问题缠绕在我的脑海中，如果你的问题听起来就是‘这样子做会让我在我的领导面前显得很好’的那一类问题，那么相比我脑袋中已经有的真正的客户问题而言，它不会得到更多的关注的。画个图，给我点时间思考。当我准备分享我的看法的时候，保证有多支马克笔可以使用。准备好接受你对问题的假设有可能完全是错误的。”—— 凯瑟琳·路易斯

“感谢和鼓励就是解决的方法，感谢可能不是一份工作评估，但是感谢能让人舒服地感受到自己并不仅仅是一个活着的独立实体，因而每个人都能够感觉到自己是被倾听的，而不是被嘲笑或者低估的。”—— 阿布希什克·塔姆拉卡尔

结语

在与内向的 DevOps 爱好者的这次交谈中，我们最大的启迪就是平等：其他人需要被怎样对待，就怎样对待他们，同时你想被怎样对待，就去要求别人怎样对待你。无论你是内向还是外向，我们都需要承认我们并非全以相同的一种方式体验这个世界。我们的同事应当被给予足够的空间以完成他们的工作，通过讨论他们的需求作为了解如何支持他们的开始。我们的差异正是我们的社区如此特别的原因，它让我们的工作对更多的人更加的有用。与别人沟通最有效的方式，就是对于你们两者而言都可行的方式。

via: https://opensource.com/article/19/7/devops-introverted-people

作者：Matthew Broberg 选题：lujun9972 译者：XLCYun 校对：wxy

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