在刚刚过去的 4 月 20 日，Docker 公司在德克萨斯州的奥斯汀市召开了 DockerCon 2017 大会。作为当下最受关注的容器公司，我们来看看他们在 DockerCon 2017 上都说了些什么。

快速阅读

1. Docker 公司将 Docker 项目改名为 Moby Project，Docker 这个名称保留用作其产品名
2. Docker 公司发布 Linux Kit，这是一个快速构建、安全可移植系统的工具集
3. Docker 企业版发布，阿里云飞天敏捷版为国内唯一具有全商业版支持能力的容器云平台
4. 微软为 Docker 站台，为 LinuxKit 提供基于 Hyper-V 的原生支持

Docker 变成了 Moby ？

在本次 DockerCon 上最大的新闻莫过于 Solomon Hykes 宣布 Moby Project 了，这在网上引起了轩然大波，毕竟作为 Docker 这种顶级开源项目，一举一动都会引起人们的关注，更何况是更名？

简单的来说，Docker 公司出于某些考虑，决定将软件产品 “Docker” 和开源项目 “Docker” 区分开来，而 Moby Project 项目将作为开源项目的新名称。Moby 将由开源社区的开发者共同维护。而 Docker 公司会基于 Moby 构建 Docker 社区版 (CE) 和企业版 (EE) 等软件产品。Moby 和 Docker 在逻辑上就像我们所熟知的 Fedora 开源项目和 Red Hat Enterprise Linux 的关系。

经过此次更名，Docker 公司将限制 “Docker” 名称的使用范围，Docker 作为 Docker 公司的注册商标，只能被用于 Docker 的产品（比如社区版、企业版、Docker Hub、Docker Store 等）。项目开源代码的地址也将变为 https://github.com/moby/moby。

编辑点评

更名这么重大的事情在没有充分沟通的情况下进行，导致了不少开发者的不满；Docker 名称的使用范围限制对于 Docker 公司来说，是一个不错的选择，但是对于整个开源项目来说，或许是由盛转衰的开始。从 Docker 到 Moby ，大量的普通用户可能因此而丢失，开发者也可能选择不再对该项目贡献。但反过来说，Docker 公司将继续推动Docker 技术的组件化和开放性，从向 Linux 和 CNCF 基金会贡献 runc 到 containerd，到今天将 Moby Project 交给开发者社区主导。一个初创公司已经为容器开源社区做出了众多贡献，预见的是更多有创意的容器应用可以从开放的社区中孕育出来。

至于项目最终如何，我们将拭目以待。

点击链接，前往 Github 查看开发者们对于 Moby Project 更名的讨论：https://github.com/moby/moby/pull/32691

国内也有相应的讨论：对于 Docker 改名 Moby ，大家怎么看？ https://www.zhihu.com/question/58805021

LinuxKit

在本次大会上，还有一个值得大家关注的重磅消息，便是 LinuxKit 的开源发布。

LinuxKit 是一个用来构建安全、可移植、精益的专门为容器服务的操作系统的工具集。它可以构建一个所有的系统服务都是基于容器的非常轻量的操作系统，这样的操作系统最小可以达到 35 MB！

LinuxKit 打包出来的新的操作系统，相比于现在的 Linux 发行版，具有更强的安全型性和易用性，其设计也使其拥有了更强的拓展性。同时，其可移植性也更高。借助 LinuxKit，可以在 Windows 上原生运行 Docker 容器。其本身虽然不是 OS ，但是其产生的产品却实实在在的成为了 CoreOS 之类面向容器的操作系统的竞品。

编辑点评

LinuxKit 作为一个工具，给用户更大的安全防护和选择自由，用户可以根据自己的需要，构建适合自己的 Linux 的最小镜像，借助这样的最小镜像， 最大程度的利用好数据中心和硬件资源。Docker 开始发觉标准的 Linux 发行版的不足。借助于 Moby 和 LinuxKit ，Docker 可以像 CoreOS 一样，掌控底层，但是又不完全和 CoreOS 的路线相同。

国外知名科技媒体 ZDNet 对于此事也有报道，有兴趣的可以去看看：http://www.zdnet.com/article/docker-linuxkit-secure-linux-containers-for-windows-macos-and-clouds/

Docker EE 的发布 和阿里飞天敏捷版支持 Docker 企业版

在 Moby 项目出现的同时，也就意味着 Docker EE (Enterprise Edition) 正式走上台前。

相比于 Docker CE（Community Edition），Docker EE 强化了其安全特性，为企业提供更加安全和可靠的容器服务，提供了一系列的安全组件和认证设施，更加满足企业的安全需求。并通过认证生态系统，笼络了大量的能够为用户提供服务的企业。

此外，Docker 的 CEO Ben 在大会上宣布 Docker 将会在阿里云平台的飞天敏捷版（Apsara Stack Agility）中落地，这是国内第一个支持 Docker 官方企业版（Enterprise Edition，EE）的容器类产品，可以部署在企业自有数据中心环境内，特别适用于企业专有云及混合云场景。

飞天敏捷版深度整合了 Docker 商业版套件和阿里的容器服务，成为国内唯一具有全商业版支持能力的容器云平台，可以部署在客户自有数据中心，包含从容器的创建到运行以及镜像的全生命周期管理。

Ben 在演讲中还提及阿里巴巴电商平台已经全面容器化，能够部署和管控超过几十万容器规模，在双 11 狂欢节稳定支撑了每秒 175000 次的订单交易。并重点并强调说阿里云不但是 Docker 的业务伙伴，同时也将为 Docker 带来大规模容器应用的实践经验。

编辑点评

Docker EE 的出现，虽然说导致了 Docker 项目的更名，但是对于 Docker 公司来说，有了盈利的可能和机会。一个能够盈利、并且活下来的公司，显然更加容易为整个世界作出更大的贡献。而阿里云成为国内首家支持 Docker EE 的产品，也为 Docker 在国内的商业应用打下了坚实的基础。

如果对 Reddit 上关于 Docker EE 和 Docker CE 的讨论有兴趣，可以看看 https://www.reddit.com/r/docker/comments/5x3os0/docker_announces_enterprise_community_editions/

微软为 Docker 站台，提供 Windows 下的 Docker 原生支持

在过去的三年中，Docker 公司和微软公司合作，开发了多款产品。

如今，Windows 开发者也可以在 Windows 基于 Hyper-V 的内核原生地运行 Linux 内核容器。

微软通过 Hyper-V 来支持了 Linux 容器在 Windows 下的运行，给开发者以更好的体验。用户可以选择使用主流的Linux 的操作系统和 Linux Kit 来运行自己需要的容器。

编辑点评

虽然微软已经不再是曾经那个叱咤风云的微软了，但依旧强大，近些年来，微软在开源社区动作频频，不断的开放、自我改变。

相信 Docker 会在微软的帮助下，能够变得更加的完善。

小结

随着 Docker 的不断演进，我们不断的看到更多新的特性被释放出来，但是同样的，随着商业化的不断进行，Docker 公司也开始走上类似红帽公司的道路。从长远的角度来说，商业化是必然的，只有不断的获取盈利，Docker 才能够不断的走下去，持续为我们提供服务。

背景

开源目前已经成为全球IT 界和互联网界一致推崇的文化和战略，而阿里巴巴作为国际顶级的互联网企业之一，在开源方面也一直秉持坚定而热忱的态度，积极地将其一些成熟或发展中的产品和技术以开源、开放的态度回馈到社区。

据目前已知的数据，阿里巴巴（以下简称阿里）已经贡献了上百款软件项目，其中去年到现在就开源了三十个左右的项目，得到了开源界和业界积极关注和参与，其中不乏重量级的开源项目。

不过，对于阿里的开源举措，业界也有一些不同的声音，比如有人认为阿里的开源项目虎头蛇尾，往往开源后就置之不理，活跃度走低，缺乏进一步的维护；也有人认为阿里的开源项目实际并没有得到社区的广泛参与和认可，更多还是阿里自身的员工在进行维护，社区并没有对这些项目提供有力的贡献，也没有衍生出重要的分支项目。

为了对中国企业在开源方面的情况进行深入的了解，从而对开源和企业之间的关系做一些定性、定量的分析，那么，让我们来具体分析一下阿里高调开源几年以来的开源项目的发展情况。

说明：我们本次的分析仅以阿里在 GitHub 上的开源项目的公开数据为基础，并不涉及到阿里在其它开源社区和代码托管网站的情况。

首先，我们在 GitHub 上找到阿里的开源团队，其在 GitHub 以团队形式出现的有几个，这里我们主要分析 https://github.com/alibaba和https://github.com/ant-design 两个团队的情况。

在上述的 alibaba团队中，我们可以发现，其名下的 代码库 （ repository ） 截止至本文写作时多达 133 个。但是有些项目仅仅是对上游项目的 复刻 （ fork ） ，并无或甚少进行修改提交，也有一些项目无实际意义，因此经过筛选后，我们得到了大约110 个项目。

而在 alibaba 团队中正式公开登记的成员（员工和前员工）有101 个，有不少参与贡献的成员没有公开登记，但是我们在做数据分析时，将邮件后缀域是 alibaba-inc.com、alipay.com、taobao.com、aliyun.com 的贡献者也归类为阿里员工。

阿里团队在 GitHub 旗下的项目数量和登记成员数在国内互联网公司来说，已经不算少了，虽然据统计，阿里团队所获得的 星标 （ star ） 数全球排名第12位，国内排到了第一，但是和国际上的一些开源领袖公司相比，还有较大距离。（注：如果累计 ant-design 团队项目的星标数，由于该团队旗下的开源项目包括了去年的一个重点项目 ant-design，其排名应该可以更高一些。）

在本文中，我们将从这些开源项目的各个维度的数据来进行分析，主要关注于以下两个方面：

• 项目的活跃程度
• 社区的参与程度

在分析之前，我们需要先了解哪些数据对我们来说是重要的，以及其背后反映的意义。

GitHub 上的开源项目指标

在 GitHub 上开源的项目有那些指标呢？可以反映出什么信息？

我们认为可以从以下几个指标进行分析：

1、项目的 提交 （ commit ） 数量、 分支 （ branch ） 数量、 发布 （ release ） 数量。

这代表了项目代码的活跃程度，其中提交数量是主要指标，而分支数量和发布数量虽然也可以侧面反映出代码的活跃程度，但是更多是不同的相关项目管理方式导致的。

2、项目的 拉取请求 （ pull request ） （PR）数量、 贡献者 （ contributor ） 数量、 问题 （ issue ） 数量。

这代表了项目参与者的参与程度，其中拉取请求数量是主要指标，而贡献者数量和问题数量与之正相关，可以反映出贡献者分布密度和项目反馈速度。

3、项目的 复刻 （ fork ） 数量、 星标 （ star ） 数量、 关注 （ watch ） 数量。

这代表了项目的受关注程度，其中复刻数量是主要指标，因为复刻一个项目往往代表了社区更多的参与意愿，并进而通过提交拉取请求、问题等进行参与，这也是社区生态发展不同的下游衍生版本的必由之路。而星标数量和关注数量，现在由于逐渐蔓延的 GitHub 营销潮流，其水分比较大，可以作为辅助指标参考。

4、项目的持续时长和最后更新时间。

项目的持续时长是从项目建立开始到最后更新时间之间的时长，这代表了项目的生存时间。如果最后更新时间是很久以前，则代表该项目已经陷入消亡中。

项目的提交数量

阿里开源的项目很多，但如同大多数企业组织一样，各个项目的活跃程度大相径庭。有的活跃项目得到了来自社区上万的 星标 （ star ） 、数千的 复刻 （ fork ） 乃至上千的 拉取请求 （ pull request ） ，项目本身也拥有数万的 提交 （ commit ） 乃至几十个 分支 （ branch ） ；而有的项目则数据寥寥，基本上陷入沉寂，其中有一半数量的项目最后提交于一年前，甚至还有 5 个项目的最后更新于 5 年前——基本上可以判定已经停止维护。

在统计时，我们发现一种情况，复刻或衍生的上游项目，会将上游的提交数量、分支数量等数据继承下来，因此在针对阿里对该项目的贡献和发展方面进行分析时，应该将这部分数据减去。这样的话，在阿里团队名下列出的一些知名项目，如复刻自 CocoaPods/Specs 的 Specs 项目拥有 14 万之多的提交数，但是阿里本身并没有对其复刻的版本进行任何提交；又比如阿里的重点项目 AliSQL 是基于 MySQL 官方版本的一个衍生版，因此其近 10万的提交数中绝大部分是 来自MySQL 发展多年来积累下的提交数量，本身阿里在将其衍生为 AliSQL 之后，只有 52 个提交数；同样 AliSQLBackup 的 10 万多个提交数也是来自于上游项目，阿里几乎没有做过更新提交，并且也停止维护两年了；因此，这些项目在统计时，我们会从阿里复刻或衍生该项目时开始计数提交数量。

当然，我们知道，仅仅以提交数来评估一个项目的活跃度是片面的，比如说，上述的 AliSQL 虽然只有 52 个提交，但是其由于开发模式和审慎态度的缘故，往往一次提交的代码量比较多，其中某次提交行数高达 5 万多行，而对上游 MariaDB 的贡献虽然只有三次提交，但是已经占到了总代码量的 1%。鉴于此，我们会不仅仅从提交数，还从复刻数、问题数等多个方面来综合进行观察。

下表是阿里旗下开源的提交数前十的项目：

我们可从上表中看到，阿里旗下开源的项目提交数最多的是 ant-design 项目，这是蚂蚁金服旗下推出的一种 UI 设计语言，在开源两年来，得到了快速的发展。我们可以看到，其提交数约计比第二名高过 1/3，其中社区提交数是成员提交数的两倍，并且日均提交数也达到了很高的水平。

第二名是 weex 项目，这是一个用于构建跨平台移动应用 UI 的框架，前些时间刚刚捐献给 Apache 基金会孵化管理。项目开源于 2016 年底，目前已有近 6 千提交，其中社区提交数量是阿里员工的提交数的 6 倍！而且，日均提交数竟然达到了 14.52 个，其发展速度还要超过了第一名 ant-design。这代表了社区强烈的参与意愿，并且该项目得到了社区的广泛应用。

第三名是 druid 项目，这是一个是“为监控而生的数据库连接池”，自称“是 Java 语言中最好的数据库连接池”。采用 Java 开发，也是阿里重点发展的项目之一，2011 年底开源发布，目前已经有 4 千余个提交，代码迭代很快。而且，非阿里员工的提交数量是阿里员工的提交数量的三倍左右。

应该说，这些排名较高的项目的活跃度都不错，其中只有一个项目是更新于半年前的，其它的项目都在近期有不同程度的更新维护。

从上面的项目的提交来源看，提交数最高前三名来自社区的提交要超过了阿里员工的提交，甚至远远超过，这说明这三个项目得到了社区的普遍支持，我们在后面分析复刻情况时也可以看到，这两个项目的复刻数都很高。而之后排名的项目，却呈现了另外一种趋势，即来自阿里员工的提交数要超过或远超来自社区的提交数，相应的表示出这些项目在社区的受欢迎程度要差一些。

从整体的这些项目来看，各个项目的提交数明显呈长尾样分布：

项目提交数分布

而且，我们可以看到，从提交数排名第 8 位的项目开始，提交数呈断崖式下降，但是整体的以正态分布呈现：

项目提交数分布（去除前 7 名）

从上述分布上来看，阿里旗下的开源项目的发展情况正常，既有活跃项目，也有消亡项目。

我们判断，阿里对其开源项目的管理处于自由生长状况，并没有从统一管理的层面来督导、辅导各个开源项目的发展，也没有对陷入消亡的项目进行进一步处置和收尾，也就是说，一些烂尾的项目并没有进行妥善处置。

为了验证这个结论，我们来看一下阿里旗下开源的项目的最近更新时间。

项目的最近更新时间

抛开一些项目内的无关紧要的更新（如修订一些 README，pom.xml 等），我们发现这 133 个项目当中有 60 个项目更新于一年前，其中更新于 4 年前及以上的有 30 个。可见有不少遗留项目缺乏处置。

当然，根据上图也可以反映出近年来阿里的开源项目整体的发展趋势要超过过去几年。

项目的拉取请求数和问题数

GitHub 开创性的使用了 拉取请求 （ pull request ） （经常简称为 PR）的方式来为开源项目提供社区协作支持。无论是项目成员还是外部合作者，以及偶尔的关注该项目的贡献者，都可以通过发起拉取请求来给某个项目提交补丁，项目维护人员可以对该拉取请求进行审核，如果审核通过，就会“拉取”该合并请求到项目中，从而将贡献者提交的代码融合到项目代码之中。

作为社区贡献者，对一个项目发起贡献的主要方式就是给该项目发起拉取请求。虽然也有不少项目要求几乎所有成员都必须以拉取请求的方式来提交其代码，而不允许直接提交到仓库中，但是通常而言，一个项目的拉取请求数可以从侧面反映出一个项目的社区（外部）参与程度。

而对一个项目作出贡献的方式不仅仅是贡献代码，还有对项目中发现的问题、缺失功能所提交的报告也是一种重要的方式，这些信息在 GitHub 中统一被称之为 问题 （ issue ） 。

每个拉取请求和问题，都会被项目维护者进行审核，并进行处置。比如对于拉取请求，可以接受、可以拒绝；对于问题，可以回复、也可以忽略/关闭。

一般来说，活跃的项目其拉取请求数量和问题数量也会越大，但是我们这里不去做这些数量的排名，我们感兴趣的是，这些拉取请求和问题中，开放和关闭的比例情况。

如下表，我们列出了拉取请求未接纳比例最高的前十名（这里略去了拉取请求数低于10的项目）。

我们可以看到，这些项目中拉取请求未接纳的比例最高的有的高达 70% 以上，当然，另外一方面，我们也看到了这些项目的拉取请求数都不高。这可以反映出该项目的社区参与积极性不高。

但是几个提交数比较高的项目，除个别情况外，其拉取请求未接纳的比例都很低：

这说明这些项目的活跃不是没有道理的。

究竟是由于社区参与积极性不高导致的未接纳比例高，还是反之，我们认为或许是彼此互相影响导致的。

再让我们来看看问题数。

我们可以看到，有些项目，居然所有的问题都没有处置，比如 oceanbase，甚至连被寄予厚望的 dubbo 和 DataX 也有相当比例的问题没有解决——难怪有人对阿里开源项目烂尾颇有微词。

那么我们同样来看看几个活跃项目的问题解决比例：

我们可以看到，这些活跃项目的问题解决比例还是比较高的。

项目的复刻数

下面我们来看看这些项目的复刻数。前面我们说过，开源项目的复刻数代表了（外部）社区参与该项目的积极性。因为复刻一个项目的意图可能有以下几种：

• 保留（冻结）该项目当前的代码以做将来之用，以避免该项目出于种种原因被删除、关闭。
• 要对该项目提交补丁（拉取请求），需要复刻一份，完成修改后发起拉取请求。
• 意图衍生该项目，通常是为了发展不同的方向。
• 只是为了方便找到该项目？可能更习惯这种方式，而不是加以星标、关注等方式来标记该项目。

无论是哪种情况，我们可以看到，复刻这种行为基本上可以代表复刻者对该项目的积极参与意愿。

以下是阿里开源的项目中复刻数最高十个项目：

从上面我们可以看到，复刻数最高的项目是一个名为 dubbo 的分布式、高性能的 RPC 框架，是阿里巴巴 SOA 服务化治理方案的核心框架，每天为 2,000+ 个服务提供 3,000,000,000+ 次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo 的复刻数远高于第二名的 fastjson，但是其相应的拉取请求数和问题数却不相称的低——这代表了什么？社区或业界觉得这个项目有价值，但是鲜于应用场景，也缺乏参与回馈的能力（或动力？）。

而第二名，fastjson 却显著的问题数比较高，这表明社区在大量使用该项目，因此产生（发现）的问题或需求也比较多。但是其拉取请求数却没有与问题数相应的提高，侧面说明了该项目本身参与开发的难度较高。

第三名 druid，是一个 java 的数据库连接池，其问题数和拉取请求数都很高，我们认为它的活跃度和社区参与程度都很健康。

第四到六名 ant-design 、RocketMQ 、 weex 都是阿里重点发展的项目，并且后两者都捐赠给了 apache 基金会孵化管理，而且 weex 的发展更是后来居上，就拉取请求和问题数来说，weex 的发展更健康一些。

那么，结论呢？可以大致的看出，复刻数较高的项目其日均复刻数也存在较大的波动，说明其发展速度不一，但是复刻数可以作为一个项目是否健康发展的指标之一，但是该指标应和拉取请求数和问题数综合来看。

项目的星标数和关注数

对 GitHub 上的开源项目的观察久已有之，但是人们一般习惯于按项目的星标数来进行排名。不过，现在随着 GitHub 的日益流行，星标这种成本低廉简单操作已经逐渐失去了作为排名依据的意义，以至于一些 markdown 项目（也称为 awesome 项目）虽然并无代码，仅仅一篇以 markdown 格式提交的资源大全，也往往取得了不错的星标数。我们认为，对于开源项目，尤其是特指代码方面的开源项目时，其星标数并不应该与那些 markdown 项目进行横向比较。当然，同样作为开源代码项目，星标数还是有一定的参考价值的。

我们来看看阿里旗下开源项目的星标数前十的项目：

啊哦，不出意外，这些项目基本上还是和复刻数排名比较相近。Weex 在该项排名中又取得了第一。令我们比较感兴趣的是，排名稍后的几个项目的开源时间并不算长。让我们来以日均星标数排名看看，这回我们多取几名：

发现什么没有？日均星标数的前几名，或者说大多数都是相当年轻的开源项目，其星标增长速度要让几个已经开源了几年的项目瞠目其后。我们判断，这说明阿里现在在开源方面已经处于高调宣传模式，对于新开源的项目，都有一波持续和明确的传播意图。但是我们认为，作为一家商业企业，这也代表了阿里已经将开源作为一个主流战略、也是其企业文化和品牌形象推广的重要方面，那么是不是代表着阿里以后的开源项目的支持力度和维护热情会更高、更持久呢？

总结

以上，我们通过对阿里旗下开源的多个项目的各个指标进行了横向和纵向的比较，从中也观察到了一些有趣的现象。但是这些数据并不能完全的反映出一个一致的结论，只是，从整体来看我们认为，阿里巴巴旗下的开源项目，正在以更快、更主动的方式在发展，至于说是否还会出现之前的那种开源之后被抛弃的情况，下定论还为时尚早。这或许要看阿里的开源委员会是否能够制定更宏观的发展战略而定。

不过，无论如何，我们欣喜的看到，阿里在践行开源理念、积极主动的拥抱、回馈开源方面，取得了瞩目的成就。我们也期待国内的更多互联网企业、IT 企业可以在开源方面有更多的实际行动，让中国这个世界上除了美国之外第二大的互联网大国在开源方面也取得相应的成就。

自从 4 月 5 号 Canonical 宣布放弃 Unity 8 转投 GNOME 之后，开源社区就对此议论纷纷，赞成者有之，惋惜者有之。

然而，有很多人没有注意到，就在 Ubuntu 17.04 发布的前一天（13 日），Canonical 现任 CEO Jane Silber 下台，由 Ubuntu 创始人 Mark Shuttleworth 重新接过了她的职位，而 Jane Silber 则会在董事会任职，并负责社区事务。这背后所代表的意味，或许说明了 Canonical 对过去这几年的战略方向的反思和调整。与之同时的是，Canonical 内部的部门裁撤和人员的离开。

但无论社区是如何看待的， Ubuntu 17.04 还是在次日不慌不忙地陆续发布，就在我们以为 GNOME 成为 Ubuntu 主发行版本要在一年以后才能见分晓时，Canonical 内部却呈现加速逃离 Unity 8 的情形：

Ubuntu GNOME 风味版在 17.04 的发布公告中表示它们将和主发行版版本融合，现有的 Ubuntu GNOME 用户以后将升级到 Ubuntu 上（其实还是 GNOME）。

不过这似乎还不足以代表其转投 GNOME 的迫切心，Ubuntu 桌面开发团队已经在 IRC 中讨论，在 17.10 就转到 GNOME，这比原计划的 18.04 LTS 要早一个发布版本。事实上，他们除了已经准备发布的 Ubuntu 17.10 alpha 1 实在是来不及了，alpha 2 就会默认使用 GNOME 了。

但这还不是最快的。最快的是另外一个不太引人注目的 Ubuntu 官方风味版本，国内人可能知道的多一点的“优麒麟”（Ubuntu Kylin），这个发行版在 17.04 发布时，就决定抛弃 Unity 桌面，而是使用了一个基于 MATE 的自己设计的 UKUI 桌面。并且，据闻优麒麟将在 18.04 脱离 Ubuntu 主要分支行列，自己干了！

而 Kubuntu 仍旧不温不火地发布着 KDE Plasma 5.9 ，表示“我就看看”；新升级为官方分支的 Ubuntu Budgie 还沉浸在去掉“-remix”后缀而转正成功的喜悦之中，对大人们的事情表示不懂。

Canonical 放弃辛苦开发了几年的 Unity，重新投入到 GNOME 怀抱，是否代表着 Canonical 要减少在桌面和移动互联网上的投入、加大在云和物联网方面的力度？以及将来的发展如何，让我们拭目以待。

继前一段时间 Linux 中国推出了“运维密码”微信小程序之后，经过开发团队的努力，重构了代码和使用了全新的现代 UI 后，同时在 GitHub 上开源了！

“运维密码”小程序是一款工作在微信环境中的小程序，主要的功能是提供一款方便、可靠、美观的 TOTP 密钥管理工具。TOTP 是基于时间的一次性密钥方案，可以为用户认证提供双因子认证（2FA）的支持，即在通常的密码之外，还额外通过另外一种方式来交叉认证以提升安全。

TOTP 认证，或者说双因子认证，在得到 Google 的大力推进之后，得到了广泛的互联网业界的支持，包括 Google、GitHub 等重视互联网安全的大型网站，也包括各类比特币网站，均支持 TOTP RFC 草案所规定的 TOTP 算法，并且 Google 还开源了其服务器端实现和客户端代码。除此之外，TOTP 还广泛应用于 Apple 、QQ、微博等各种需要双因子认证的场景中。除了网站之外，对于我们运维人员来说，TOTP 还可以应用与服务器的远程管理上，为 SSH、SFTP、FTP 等提供安全、简单、可靠的保障！

新版本介绍

好了，言归正传，我们来介绍一下本次新版本发布的情况。

本次版本迭代，我们毫不谦虚的将版本定位到 1.0.x，我们认为“运维密码”的第一阶段功能目标已经达成，目前主要有：

• 添加 TOTP 场景
• 查看 TOTP 密钥
• 修改和删除 TOTP 场景
• 生成场景二维码
• 分享（克隆） TOTP 场景给朋友
• 本地备份 TOTP 场景信息
• 本地恢复 TOTP 场景信息

新的版本，采用了现代化的 UI 设计，看起来会更专业一点。

场景列表

场景列表会列出你已经添加的所有场景，最上方是时间进度条会显示场景密钥要更新的时间。在列表最下方，可以点击“添加场景”，调出摄像头来扫描密钥二维码来添加场景。

点击场景列表中的场景密钥，会复制该密钥，以备手机上使用。

场景详情

点击场景列表中的场景（非密钥区域），可以查看场景具体详情，在此可以“分享”、“生成二维码”、“编辑”乃至于“删除”场景。

• 分享：请点击页面右上角的菜单，可以将该场景分享给你的朋友，这样你的朋友就会得到一份该场景的完全复制品。切记！分享该场景会导致别人一直拥有该场景信息，并随时生成密钥（和你的场景生成相同的密钥）。如果这不是你希望的结果，切勿分享。
• 生成二维码：可以生成一份该场景特定的二维码，将其打印出来贴于服务器等物理环境处，使用时直接用微信扫描即可调出“运维密码”小程序添加该场景。（注：该场景二维码不同于用于添加场景的种子二维码）
• 编辑和删除：也可以对此场景进行编辑，尤其是你在添加场景时输入的信息不够明确时。也可以在此修改该场景的地点（我们后继的版本会推出地点感知功能）。

生成的场景二维码

场景备份与恢复

场景备份信息，请截屏安全保存

最重要的，“运维密码”小程序提供了备份和恢复功能，这是 Google 所开源的 Google 身份验证器所缺乏的最重要功能。有了备份功能，你就不用担心手机丢失或更换手机的麻烦了。

目前我们提供了本地备份功能。限于微信小程序的限制，我们不能保存文件，只能将备份信息以二维码的方式备份出来。您可以将该二维码截屏，保存到安全可靠的地方，以备以后需要时恢复。

现阶段没有提供远程云端备份功能的主要原因是用户可能忧虑云端备份的隐私保障，因此，我们在没有办法提供一个可靠备份，连服务提供方也不能破解的方法之前，不会提供云端备份功能。

开源啦！

作为一家倡导开源的社区，我们一定要亲自践行开源才算得上名至实归。因此，我们在代码重构稳定之后，第一时间就将“运维密码”开源了出来。开源地址在：

https://github.com/LCTT/WeApp-Password

本项目采用 AGPL 3.0 协议开源。

欢迎大家复刻和提交拉取请求，有什么错误和功能建议，也非常欢迎大家给我们提出 issue。

欢迎体验

我们还开设了“运维密码”小程序体验群，欢迎大家到群内发表意见，以及寻求帮助。加入本群也可以及时体验我们发布前的体验版本，第一时刻尝鲜。

运维密码体验群

扫描识别添加上面的好友，验证信息：“运维密码”，可获得入群邀请。

使用参考

要在 OpenSSH 上使用 TOTP，请参考 netb2c 写的《SSH 安全加固篇：通过“运维密码”小程序实现 SSH 双因子认证》。

我们还会陆续推出更多使用 “运维密码”的文章，也欢迎大家给我们投稿。

哦，好像我没有说到如何找到“运维密码”——我想这一定难不倒你，不过假如你不知道的话，你可以如此这般：

• 在微信中“发现”->“小程序”中搜索“运维密码”即可。
• 什么，你的“发现”中没有“小程序”，那你可以扫描下面这个二维码，来尝鲜你的第一个小程序：

运维密码

致谢

感谢开发团队的 @Bestony、betty、wxy；

感谢撰写使用“运维密码”的文章的同学：netb2c；

感谢“运维密码”体验群的诸位同学；

感谢 Google 开源的程序；

感谢微信提供的环境。

昨天发布了一则《阿里云成为中国唯一一家Linux 基金会的金牌成员》的新闻，引来了不少关注和议论。主要的议论有几个方面：

• 阿里云支持开源和 Linux，值得赞
• 阿里云有钱，有钱谁都能当上金牌会员，乃至于白金会员
• 别的公司早就是白金会员了，要继续努力

对于这样的观点和评论，基本上还是在我的意料之内。其实在编发这篇新闻稿之前，老王也对中国的科技公司参与、赞助国际性的开源组织的情况有过一些了解和思考，借着这个机会，想和大家探讨一下。

国内科技公司参与国际性开源组织已经成为了趋势

不知道从什么时候开始，国内的科技公司，已经开始或低调、或高调的加入一些国际性的开源组织，比如说：

• 早在 2010 年，中国移动就成为了 Linux 基金会的首个中国会员，还是金牌会员；现在它是银牌会员。
• 华为也在同年加入了 Linux 基金会，是以银牌会员身份加入的。
• 而中国电信不知道什么时候悄然成为了 Linux 基金会的会员，并一直保持到现在。
• ……
• 2016 年，阿里巴巴以银牌会员身份加入 Linux 基金会。
• 2016 年，中国电信、中国移动、华为、中兴等成为 OpenStack 基金会黄金会员。
• 2016 年，阿里云的彭立勋成为 MariaDB 基金会六位成员之一。
• 2017 年，阿里云将 Linux 基金会的会员身份升级为金牌会员。
• 2017 年，EasyStack 的郭长波和 Intel 的王庆获选 OpenStack 个人独立董事。
• 2017 年，DaoCloud 加入 CNCF（云计算基金会）。

可以看出，近些年来，中国国内的科技公司纷纷注意到开源生态的发展，并主动积极的拥抱开源、加入并影响开源的发展。

企业加入国际开源组织能做什么？

作为营利性机构，企业加入开源组织必然有其商业上和战略上的考量，大致来说，会有如下几点：

• 回馈开源社区。在开源文化的影响已经深入到世界的各个角落的今天，很多企业的发展都极大地得益于开源文化、开源生态和开源技术的帮助，因此，就如阿里云资深总监李津说的，“参与 Linux 基金会……是对 Linux 带来的帮助表示感谢”。
• 扩大在技术领域和开源领域的影响力，吸引更多的人才。成为顶尖的开源组织的成员，并积极参与到开源事务当中，将企业的形象、实力和愿景传递给更多的人，也会吸引更多有志于该领域发展的尖端人才加入。
• 影响开源生态的决策和标准制定。各种开源基金会、组织掌握了该项技术和生态的发展，会制定和规划相应的发展路线和行业标准，因此，加入到开源组织中，能够充分地结合企业在技术研究和产品发展上的路线，与整个开源领域中的相关企业、组织达成共识，尽早掌握发展的制高点。

开源组织为什么需要企业会员？

开源组织是开源生态里面独特的一种现象，这种情况和工业界的各种行会不太一样。它既沿袭了传统的行会是由企业组成的特色，也有主要由个人成员（非雇员）组成的组织，但是，作为行业性组织，往往还是由企业组成的。

开源组织的成员情况分为三种情况：

• 仅由个人会员组成的开源组织，如自由软件基金会（FSF）、Apache 软件基金会（ASF）等。
• 仅由企业会员组成的开源组织，如云计算基金会（CNCF）。
• 既有企业会员，也有个人会员的开源组织，如 Linux 基金会、OpenStack 基金会等。

不过，即便在拥有个人会员的开源组织当中，其个人会员的影响力也往往低于企业会员。甚至有时候影响力无足轻重，比如说，Linux基金会就曾经将由个人会员所推举独立董事的权利取消，转而由董事会成员推举。

显然，对于很多开源组织来说，影响力更大、能提供更多资金支持的企业会员是其发展中不可或缺的一部分。

基本上，开源组织吸收企业会员的原因有：

• 开源组织本身的运营需要资金支持。开源组织，是以非营利组织的形式出现的，本身的运营并不以盈利为目标，其所需的资金来源于会员会费、民间赞助、国家资金和运营营收等方面。不同的开源组织的资金来源不同，有的主要依赖于赞助，有的则主要依赖于会员会费。
• 开源组织需要吸收相关企业的建议和意见。事实上成功的开源组织无一不是反映了行业内成员的发展诉求，并能协调和规范发展方向，因此，吸收主要企业的参与，能够保证开源生态的可持续发展。
• 开源组织的决策和标准需要企业的推动和落实。开源组织诞生于社区，成长于企业，开源生态并不是自行设计愿景就可以理想化地发展的，因此，开源组织的很多决策和制定的标准，需要落地和切实发挥影响，就离不开企业的支持和拥护。

是会费的多寡决定了不同的话语权？

事实上，作为一个健康发展的开源组织，其正常的运营费用从来不是一个问题。因此，并非是谁交钱多，谁就是领袖。

不是所缴纳的会费决定了会员级别，而是综合了企业对包括代码、标准/规范、人员、资金在内的贡献决定了会员级别。

作为开源组织，其所需要企业会员发挥的作用包括：

• 贡献代码。主要是企业将自己生产的重要代码贡献到开源生态中，从而促进整个生态的发展。
• 贡献标准和规范。企业已经成熟的标准可以提交到开源组织当中，在经过审核、调整之后，取得共识，从而成为开源组织和业界的标准。
• 贡献人员。企业甚至会专职雇佣一些人员，其职责是为开源组织工作，包括提交代码、参与开发/维护、参与开源组织运营事务等工作。
• 赞助资金。为开源组织提供运营和雇员所需要的资金支持。

开源组织收取的费用都作何用途？

国际顶尖的开源组织大多注册在美国，属于非营利机构，在美国属于一种机构注册形式。其认定和税务豁免需要经过税务部门的每年审核（501(c)(3)非营利身份），因此，其财务报表是公开的。

根据之前 ITworld 的一份数据，它查询了 13 家开源基金会的 2010 年财务报告和 5 家的 2009 年报告，显示：

• Linux 基金会在 2010 年收入 961 万美元，支出 908 万美元，净收入 53 万美元，收入最高的是执行董事 James Zemlin 36 万美元；
• 自由软件基金会 2009 年收入89万美元，支出 108 万美元，薪酬最高是执行董事 Peter Brown，约 8 万美元；
• GNOME 基金会 2009 年收入约64万美元，支出 38 万美元；执行董事 Robin L. Peters 收入 13 万美元；
• Apache 软件基金会收入约 54 万美元，支出约 41 万美元；
• Mozilla 基金会收入 193 万美元，支出 326 万美元，Baker 和 Eich 收入 59 万美元。

从这个数据中，我们大概可以了解到这些开源组织的收支情况。也可以看到，其实相对来说，其个人雇员的收入也并不算高。此外，除了雇员薪酬之外，开源组织的其它开销还有办公费用、活动费用，甚至还有诉讼费用等等。

应该如何看待国内企业加入国际开源组织

首先，我觉得应该对国内企业有意识地去参与、赞助开源组织表示支持，这标志着国内企业逐步在国际舞台和行业内发出了自己的声音，甚至可以主导部分发展方向。

其次，我们也看到，目前能够比较广泛地参与到开源组织的活动中，并持续支持开源组织的国内公司还不够多。典型的企业有电信级企业，如中国电信、中国移动（中国联通缺席）、华为、中兴等；互联网企业，尤其是将云业务作为主要发展方向的企业，比如阿里巴巴集团及其旗下的阿里云、DaoCloud、EasyStack 等，但是BAT 中除了阿里巴巴之外的另外两家表现的就不够积极。

而且，国内的企业所关注参与的开源组织还比较少，主要集中在几个大型的开源组织上，相对来说影响力还不够广泛。

当然，作为企业，是否加入开源组织，以及加入哪些，是需要根据企业自身的发展情况来决定参与程度的，毕竟，参与开源组织不仅仅是缴纳会费，更多还要付出人员、技术，承担不仅仅是好处，还有责任。

此外，企业也在参与开源组织方面存在一些短板需要补足。比如说，需要有优秀乃至于领军型的技术人才代表公司参与到开源组织中；也需要将公司发展战略和开源生态做良性的结合，将开源文化和企业文化达成融合；更需要将企业的营利本质和开源的公益性质取得一个平衡。

结语

作为一个参与开源文化，并受惠于开源生态的技术人，我对阿里云以及其它的科技公司能主动参与到开源组织的建设和开源生态的发展中感到欣喜。希望国内更多的企业能够积极关注开源，参与到开源之中来，并针对企业自身的情况制定开源战略。

Linux 内核组织 （ Linux Kernel Organization ） （kernel.org） 是一家建立于 2002 年的加利福尼亚公共福利公司，其目的是公开地免费分发 Linux 内核和其它开源软件。它接受 Linux 基金会的管理，包括技术、资金和人员支持，用以维护 kernel.org 的运营。

Linux 内核组织是 Linux 内核发布的官方场所，在其站点上可以找到 Linux 内核的各个版本，包括最早的 1.0 到最新的 4.x 内核。其所提供的内核获取方式多种多样，包括：

• HTTP https://www.kernel.org/pub/
• GIT https://git.kernel.org/
• RSYNC rsync://rsync.kernel.org/pub/

以及 FTP 方式，然而，现在他们决定停止 FTP 方式的下载了。

最初，早在 1998 年的时候， Linux 内核组织就提供了以 FTP 服务为基础的内核代码获取方式，除了可以直接通过 FTP 进行下载以外，还可以通过 HTTP 协议封装来访问 FTP 资源，甚至，还允许通过 NFS 和 SMB/CIFS 来将他们的 FTP 资源挂载为本地分区。

不过，不久之后，他们发现提供一个公开的 NFS/CIFS 服务器看起来并不是一个好主意，不仅仅是因为这两种服务在慢速网络时表现很糟糕，而且它们本身也存在严重的安全隐患。因此于当年年底时停止了对 NFS 和 SMB/CIFS 的支持。

而现在，基于如下考虑：

• FTP 服务需要在防火墙和负载均衡设备上做额外的配置和调整
• FTP 服务器不支持缓存和加速器，这严重影响了性能
• 大多数的相关软件缺乏维护和更新

因此，在服务了 19 年之后，Linux 内核组织决定彻底终止 FTP 服务器上剩下的 FTP 服务了。Linux 内核组织所有的 FTP 服务都将在今年内关闭，为了减少影响，关闭分为两个阶段：

1. <ftp://ftp.kernel.org/> 服务将于 2017 年 3 月 1 日终止
2. <ftp://mirrors.kernel.org/> 服务将于 2017 年 12 月 1 日终止

不过，如果你有任何疑问，欢迎联系 [email protected] 。