分类 观点 下的文章

Mark Shuttleworth

Mark Shuttleworth 是 Ubuntu 的创始人

Ubuntu 之前在 4 月份宣布决定放弃 Unity 让包括我在内的所有人都大感意外。

现在，Ubuntu 的创始人 Mark Shuttleworth 分享了关于 Ubuntu 为什么会选择放弃 Unity 的更多细节。

答案可能会出乎意料……

或许不会，因为答案也在情理之中。

为什么 Ubuntu 放弃 Unity？

上周（10 月 20 日）Ubuntu 17.10 已经发布，这是自 2011 年引入 Unity 以来，Ubuntu 第一次没有带 Unity 桌面发布。

当然，主流媒体对 Unity 的未来感到好奇，因此 Mark Shuttleworth 向 eWeek 详细介绍了他决定在 Ubuntu 路线图中抛弃 Unity 的原因。

简而言之就是他把驱逐 Unity 作为节约成本的一部分，旨在使 Canonical 走上 IPO 的道路。

是的，投资者来了。

但是完整采访提供了更多关于这个决定的更多内容，并且披露了放弃曾经悉心培养的桌面对他而言是多么艰难。

“Ubuntu 已经进入主流”

Mark Shuttleworth 和 Sean Michael Kerner 的谈话，首先提醒了我们 Ubuntu 有多么伟大：

“Ubuntu 的美妙之处在于，我们创造了一个对终端用户免费，并围绕其提供商业服务的平台，在这个梦想中，我们可以用各种不同的方式定义未来。

我们确实已经看到，Ubuntu 在很多领域已经进入了主流。”

但是受欢迎并不意味着盈利，Mark 指出：

“我们现在所做的一些事情很明显在商业上是不可能永远持续的，而另外一些事情无疑商业上是可持续发展的，或者已经在商业上可持续。

只要我们还是一个纯粹的私人公司，我们就有完全的自由裁量权来决定是否支持那些商业上不可持续的事情。”

Shuttleworth 说，他和 Canonical 的其他“领导”通过协商一致认为，他们应该让公司走上成为上市公司的道路。

为了吸引潜在的投资者，公司必须把重点放在盈利领域 —— 而 Unity、Ubuntu 电话、Unity 8 以及 融合 convergence 不属于这个部分：

“[这个决定]意味着我们不能让我们的名册中拥有那些根本没有商业前景实际上却非常重大的项目。

这并不意味着我们会考虑改变 Ubuntu 的条款，因为它是我们所做的一切的基础。而且实际上，我们也没有必要。”

“Ubuntu 本身现在完全可持续发展”

钱可能意味着 Unity 的消亡，但会让更广泛的 Ubuntu 项目健康发展。正如 Shuttleworth 解释说的：

“我最为自豪的事情之一就是在过去的 7 年中，Ubuntu 本身变得完全可持续发展。即使明天我被车撞倒，而 Ubuntu 也可以继续发展下去。

这很神奇吧？对吧？这是一个世界级的企业平台，它不仅完全免费，而且是可持续的。

这主要要感谢 Jane Silber。” （LCTT 译注：Canonical 公司的 CEO）

虽然桌面用户都会关注桌面，但比起我们期待的每 6 个月发布的版本，对 Canonical 公司的关注显然要多得多。

失去 Unity 对桌面用户可能是一个沉重打击，但它有助于平衡公司的其他部分：

“除此之外，我们在企业中还有巨大的可能性，比如在真正定义云基础设施是如何构建的方面，云应用程序是如何操作的等等。而且，在物联网中，看看下一波的可能性，那些创新者们正在基于物联网创造的东西。

所有这些都足以让我们在这方面进行 IPO。”

然而，对于 Mark 来说，放弃 Unity 并不容易，

“我们在 Unity 上做了很多工作，我真的很喜欢它。

我认为 Unity 8 工程非常棒，而且如何将这些不同形式的要素结合在一起的深层理念是非常迷人的。”

“但是，如果我们要走上 IPO 的道路，我不能再为将它留在 Canonical 来争论了。

在某个阶段你们应该会看到，我想我们很快就会宣布，没有 Unity， 我们实际上已经几乎打破了我们在商业上所做的所有事情。”

在这之后不久，他说公司可能会进行第一轮用于增长的投资，以此作为转变为正式上市公司前的过渡。

但 Mark 并不想让任何人认为投资者会 “毁了派对”：

“我们还没沦落到需要根据风投的指示来行动的地步。我们清楚地看到了我们的客户喜欢什么，我们已经找到了适用于云和物联网的很好的市场着力点和产品。”

Mark 补充到，Canonical 公司的团队对这个决定 “无疑很兴奋”。

“在情感上，我不想再经历这样的过程。我对 Unity 做了一些误判。我曾天真的认为业界会支持一个独立自由平台的想法。

但我也不后悔做过这件事。很多人会抱怨他们的选择，而不去创造其他选择。

事实证明，这需要一点勇气以及相当多的钱去尝试和创造这些选择。”

OMG! IPO? NO!

在对 Canonical（可能）成为一家上市公司的观念进行争辩之前，我们要记住，RedHat 已经是一家 20 年之久的上市公司了。GNOME 桌面和 Fedora 在没有任何 “赚钱” 措施的干预下也都活得很不错。

Canonical 的 IPO 不太可能对 Ubuntu 产生突然的引人注目的的改变，因为就像 Shuttleworth 自己所说的那样，这是其它所有东西得以成立的基础。

Ubuntu 是已被认可的。这是云上的头号操作系统。它是世界上最受欢迎的 Linux 发行版（除了 Distrowatch 排名）。并且它似乎在物联网上也有巨大的应用前景。

Mark 说 Ubuntu 现在是完全可持续发展的。

随着一个迎接 Ubuntu 17.10 到来的热烈招待会，以及一个新的 LTS 将要发布，事情看起来相当不错……

via: http://www.omgubuntu.co.uk/2017/10/why-did-ubuntu-drop-unity-mark-shuttleworth-explains

作者：JOEY SNEDDON 译者：Snapcrafter，geekpi 校对：wxy

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

又是一年，GitHub 例行发布了 2017 年度的章鱼猫观察报告。以下我们撷取此报告中一些有趣的结果分享给大家。

数百万的开发人员使用 GitHub 来共享代码和构建业务。在这里你可以完成你的工作、打造新的技术、贡献给开源项目等等。历史已经证明，当好奇的人聚集到一起工作，一些美好的事情就会随之而来：工作进行得更快、新的想法涌现，从根本上改变了我们建立软件的方式。

为了庆祝这贡献和辉煌的一年, 让我们回顾一下 2017 年的项目、人员和团队。

十年千万，遍及全球

过去这十年，GitHub 各项数据已经超过了百万级，甚至千万级。在 2017 年，GitHub 社区有 2400 万开发者工作于 6700 万个仓库上，就连这些开发者组成的组织都达到了 150 万个。

而这些开发者遍及全球：亚洲 710 万，北美 590 万，欧洲 530 万，等等。

这一年，忙碌的一年

人们在 2500 万个公开仓库上分享代码。从 2016 年 9 月到现在的一年间：

  • 公开仓库的提交数达到了 1 亿个！
  • 活跃仓库有 2530 万个（“活跃”指该仓库有公开的活动，比如提交、星标、讨论等）

  • 活跃 工单 （ issue ） 有 1250 万个，关闭（解决）了 6880 万个工单，对工单进行了 140 万次讨论

  • 新 PR （ 拉取请求 （ pull request ） ）有 130 万个，

  • 第 1 亿个 PR 被合并，这是一个 OpenShift 的文档更新
  • 对代码进行了 62 万次审查
  • 最流行的表情符是：点赞（720 万）

  • 新加入 670 万开发者，其有 100 万的开发者来自美国，69 万来自中国

    • 这些新加入的开发者发起了 120 万个 PR，410 万人创建了其第一个仓库，
    • 19 万人没有提交任何代码而只是复刻和星标了仓库

  • 创建了 45 万个组织

    • 这其中包括 Python 的开发也迁移到了 GitHub

编程语言，各就其位

通过 PR 所使用的语言，可以发现最流行的语言是——JavaScript！而 Python 取代了 Java 成为了第二名。很高兴 Ruby 和 PHP 分别能取得第四、第五名。其余的名次和去年相差不大。

项目排名，众望所归

从这些活跃的仓库中，我们找出了 10 大 复刻 （ fork ） 数最多的仓库。人工智能方向的 TensorFlow 项目夺得桂冠，前端方向的 BootStrap 是第二。尤雨溪的 vuejs 排名第六，恰恰比排名第七的 Facebook 的 react 的复刻数高一点，很难说这与今年 Facebook 对 react 的许可证问题有没有关系。而 Linus 的 Linux 项目敬陪末座，作为这样庞大的一个项目，已经相当了不起了。

（这里没有包括 MOOC 课程，一个 Coursera 的 R 语言课程有数千的复刻数，以此判断，至少有十万学生开始学习该课程了）

而以贡献者来说，微软的 vscode 项目的贡献者最多，几乎是排在第二名的 react-native 的两倍。这一方面证明了社区对 vscode 的喜爱，另外一方面也证明了微软在开源方面的重注投入。

得到最多代码评议的项目是 Typescript 的一个类型定义库 DefinitelyTyped，第二名才是炙手可热的 Kubernetes。

当然，已经赢得了容器编排系统之战的 Kerbernetes 取得讨论最多的排名一点也不令人意外，它的讨论数量的零头就和第二名 origin 差不多，而这个 OpenShift 下的 Origin 项目，也是一个 Kubernetes 项目——面向开发者的企业版 Kubernetes 发行版。

企业版，大公司多用

GitHub 虽然对个人的公开使用提供免费的服务，当然，如果你想放私有仓库，是要交费的。而 GitHub 对于或大或小的企业来说，更适用的是其企业版。

  • 美国前一百个最大的公司（按收入）有一半在使用 GitHub 企业版
  • 虽然美国是使用 GitHub 企业版最多的国家，但是也有 1/4 的客户来自其它国家
  • 不仅仅是软件和互联网行业在使用 GitHub 企业版（占 22%），金融服务、商业服务也占比较高

感谢你，让我们期待 2018 年的章鱼猫报告！

明确是避免许可歧义的关键所在。

在许可证的过去、当前和未来版本如何适用于软件程序方面，GPL 系列许可证在开源许可证中可谓独树一帜。如果不能完全理解其中独有的许可证特性，开源软件开发人员可能会无意中造成混淆。

GPL 许可证在其许可证的条款和条件中阐明了许可证版本如何适用于该程序。GPL v2（第 9 条）写到：

“每个版本都有一个独特的版本号，如果该程序指定了其适用的许可证的版本号以及‘任何更新的版本’，则可以选择遵循由 自由软件基金会 （ Free Software Foundation ） 发布的该版本或之后任何更新版本的条款和条件。如果该程序未指定许可证的版本号，则可以选择自由软件基金会以前发布的任何版本。”

GPL v3 第 14 条与 GPL v2 中的上述条款非常相似。

多年以来，我看到很多开源项目表示遵循 GPL 许可证，但却没有明确指出版本号，同时也没有将整个 GPL 许可证（例如，v2 或 v3）副本囊括在程序内。取决于您是许可人还是被许可人等因素，这其中造成的含混不清可能对您有益或有害。

许可证的模糊如何产生影响

例如，假设应用程序的许可证声明：“本程序遵循 GPL 许可证”，并且包含整个 GPL v3 许可证的副本。由于该项目没有明确说明适用该许可证的哪个版本号，所以合理的解释是自由软件基金会发布的所有版本 GPL 许可证都适用——v3、v2 甚至 v1！

依据 GPL v3 第 14 条的下述文本可以合乎情理地做出上述理解。

“如果该程序未指定 GNU GPL 的版本号，则可以选择由自由软件基金会发布的任何版本。”

另一方面，将 GPL 特定版本的完整副本（还可能包括许可证标题块中的 GPL 版本号）包含在程序中，可以被解释为在实质上传递了特定版本的许可证。在这个例子中，那就是 GPL v3 版本并且只有 GPL v3 版本，因为 v3 中没有“任何更新的版本”的条款。

如何避免许可歧义

为了避免这种许可歧义，您应该写得非常明确。如果您只想适用 GPL v3，应该明确地声明：“本程序仅遵循 GPL v3”，并提供整个 GPL v3 许可证副本。或者，如果您希望适用 GPL v3 或之后更新的版本，请明确声明：“本程序遵循 GPL v3 或其之后更新的版本”。最后，如果您真的想要适用任何版本的 GPL 许可证，您可以提供 GPL v3 许可证，并表示：“本程序遵循由自由软件基金会发布的任何版本的 GPL 许可证”。

无论您选择哪种授权方式，都应该非常明确，让每个人都能理解您的真正意图。

作者简介：Jeffrey R. Kaufman是全球领先的开源软件解决方案供应商Red Hat公司的开源知识产权律师，还担任托马斯杰斐逊法学院（Thomas Jefferson School of Law）的兼职教授。在任职Red Hat之前，Jeffrey曾担任高通公司（Qualcomm Incorporated）的专利顾问，为首席科学家办公室（Office of the Chief Scientist）提供开源事务咨询。

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

via: https://opensource.com/article/17/11/avoiding-gpl-confusion

作者：Jeffrey Robert Kaufman 译者：薛亮 校对：wxy

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

在大量金钱与围绕 Linux 激烈争夺的公司之间，真正给操作系统带来活力的正是那些开发者。

事实证明上，Linux 社区是可行的，因为它本身无需太过担心社区的正常运作。尽管 Linux 已经在超级计算机、移动设备和云计算等多个领域占据了主导的地位，但 Linux 内核开发人员更多的是关注于代码本身，而不是其所在公司的利益。

这是一个出现在 Dawn Foster 博士研究 Linux 内核协作开发的博士论文中的重要结论。Foster 是在英特尔公司和 木偶实验室 Puppet Labs 的前任社区领导人，他写到，“很多人首先把自己看作是 Linux 内核开发者，其次才是作为一名雇员。”

随着大量的“ 基金洗劫型 foundation washing ”公司开始侵蚀各种开源项目，意图在虚构的社区面具之下隐藏企业特权，但 Linux 依然设法保持了自身的纯粹。问题是这是怎么做到的？

跟随金钱的脚步

毕竟，如果有任何开源项目会进入到企业贪婪的视线中，那它一定是 Linux。早在 2008 年，Linux 生态系统的估值已经达到了最高 250 亿美元。最近 10 年，伴随着数量众多的云服务、移动端，以及大数据基础设施对于 Linux 的依赖，这一数据一定倍增了。甚至在像 Oracle 这样单独一个公司里，Linux 也能提供数十亿美元的价值。

那么就难怪有这样一个通过代码来影响 Linux 发展方向的必争之地。

在 Linux 基金会的最新报道中，让我们看看在过去一年中那些最活跃的 Linux 贡献者，以及他们所在的企业像“海龟”一样高高叠起。

linux companies

这些企业花费大量的资金来雇佣开发者去为自由软件做贡献，并且每个企业都从这些投资中得到了回报。由于存在企业对 Linux 过度影响的潜在可能，导致一些人对引领 Linux 开发的 Linux 基金会表示不满。在像微软这样曾经的开源界宿敌的企业挥舞着钞票进入 Linux 基金会之后，这些批评言论正变得越来越响亮。

但这只是一位虚假的敌人，坦率地说，这是一个以前的敌人。

虽然企业为了利益而给 Linux 基金会投入资金已经是事实，不过这些赞助并不能收买基金会而影响到代码。在这个最伟大的开源社区中，金钱可以帮助招募到开发者，但这些开发者相比关注企业而更专注于代码。就像 Linux 基金会执行董事 Jim Zemlin 所强调的：

“我们的项目中技术角色都是独立于企业的。没有人会在其提交的内容上标记他们的企业身份： 在 Linux 基金会的项目当中有关代码的讨论是最大声的。在我们的项目中，开发者可以从一个公司跳槽到另一个公司而不会改变他们在项目中所扮演的角色。之后企业或政府采用了这些代码而创造的价值，反过来又投资到项目上。这样的良性循环有益于所有人，并且也是我们的项目目标。”

任何读过 Linus Torvalds 的 的邮件列表评论的人都不可能认为他是个代表着这个或那个公司的人。这对于其他的杰出贡献者来说也是一样的。虽然他们几乎都是被大公司所雇佣，但是一般情况下，这些公司为这些开发者支付薪水让他们去做想做的开发，而且事实上，他们正在做他们想做的。

毕竟，很少有公司会有足够的耐心或承受风险来为资助一群新手 Linux 内核开发者，并等上几年，等他们中出现几个人可以贡献出质量足以打动内核团队的代码。所以他们选择雇佣已有的、值得信赖的开发者。正如 2016 Linux 基金会报告所写的，“无薪开发者的数量正在持续地缓慢下降，同时 Linux 内核开发被证明是一种雇主们所需要的日益有价值的技能，这确保了有经验的内核开发者不会长期停留在无薪阶段。”

然而，这样的信任是代码所带来的，并不是通过企业的金钱。因此没有一个 Linux 内核开发者会为眼前的金钱而丢掉他们已经积攒的信任，当出现新的利益冲突时妥协代码质量就很快失去信任。因此不存在这种问题。

不是康巴亚，就是权利的游戏，非此即彼

最终，Linux 内核开发就是一种身份认同， Foster 的研究是这样认为的。

为 Google 工作也许很棒，而且也许带有一个体面的头衔以及免费的干洗。然而，作为一个关键的 Linux 内核子系统的维护人员，很难得到任意数量的公司承诺高薪酬的雇佣机会。

Foster 这样写到，“他们甚至享受当前的工作并且觉得他们的雇主不错，许多（Linux 内核开发者）倾向于寻找一些临时的工作关系，那样他们作为内核开发者的身份更被视作固定工作，而且更加重要。”

由于作为一名 Linux 开发者的身份优先，企业职员的身份次之，Linux 内核开发者甚至可以轻松地与其雇主的竞争对手合作。之所以这样，是因为雇主们最终只能有限制地控制开发者的工作，原因如上所述。Foster 深入研究了这一问题：

“尽管企业对其雇员所贡献的领域产生了一些影响，在他们如何去完成工作这点上，雇员还是很自由的。许多人在日常工作中几乎没有接受任何指令，来自雇主的高度信任对工作是非常有帮助的。然而，他们偶尔会被要求做一些特定的零碎工作或者是在一个对公司重要的特定领域投入兴趣。

许多内核开发者也与他们的竞争者展开日常的基础协作，在这里他们仅作为个人相互交流，而不需要关心雇主之间的竞争。这是我在 Intel 工作时经常见到的一幕，因为我们内核开发者几乎都是与我们主要的竞争对手一同工作的。”

那些公司可能会在运行 Linux 的芯片上、或 Linux 发行版，亦或者是被其他健壮的操作系统支持的软件上产生竞争，但开发者们主要专注于一件事情：使 Linux 越来越好。同样，这是因为他们的身份与 Linux 维系在一起，而不是编码时所在防火墙（指公司）。

Foster 通过 USB 子系统的邮件列表（在 2013 年到 2015 年之间）说明了这种相互作用，用深色线条描绘了公司之间更多的电子邮件交互：

linux kernel

在价格讨论中一些公司明显的来往可能会引起反垄断机构的注意，但在 Linux 大陆中，这只是简单的商业行为。结果导致为所有各方在自由市场相互竞争中得到一个更好的操作系统。

寻找合适的平衡

这样的“合作”，如 Novell 公司的创始人 Ray Noorda 所说的那样，存在于最佳的开源社区里，但只有在真正的社区里才存在。这很难做到，举个例子，对一个由单一供应商所主导的项目来说，实现正确的合作关系很困难。由 Google 发起的 Kubernetes 表明这是可能的，但其它像是 Docker 这样的项目却在为同样的目标而挣扎，很大一部分原因是他们一直不愿放弃对自己项目的技术领导。

也许 Kubernetes 能够工作的很好是因为 Google 并不觉得必须占据重要地位，而且事实上，它希望其他公司担负起开发领导的职责。凭借出色的代码解决了一个重要的行业需求，像 Kubernetes 这样的项目就能获得成功，只要 Google 既能帮助它，又为它开辟出一条道路，这就鼓励了 Red Hat 及其它公司做出杰出的贡献。

不过，Kubernetes 是个例外，就像 Linux 曾经那样。成功是因为企业的贪婪，有许多要考虑的，并且要在之间获取平衡。如果一个项目仅仅被公司自己的利益所控制，常常会在公司的技术管理上体现出来，而且再怎么开源许可也无法对企业产生影响。

简而言之，Linux 的成功运作是因为众多企业都想要控制它但却难以做到，由于其在工业中的重要性，使得开发者和构建人员更愿意作为一名 Linux 开发者 而不是 Red Hat （或 Intel 亦或 Oracle … ）工程师。

via: https://www.datamation.com/open-source/why-linux-works.html

作者：Matt Asay 译者：softpaopao 校对：wxy

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

在这篇分析报告中，我们将使用 2017 年度截止至当前时间（2017 年 10 月）为止，GitHub 上所有公开的推送事件的数据。对于每个 GitHub 用户，我们将尽可能地猜测其所属的公司。此外，我们仅查看那些今年得到了至少 20 个星标的仓库。

以下是我的报告结果，你也可以在我的交互式 Data Studio 报告上进一步加工。

顶级云服务商的比较

2017 年它们在 GitHub 上的表现：

  • 微软看起来约有 1300 名员工积极地推送代码到 GitHub 上的 825 个顶级仓库。
  • 谷歌显示出约有 900 名员工在 GitHub 上活跃，他们推送代码到大约 1100 个顶级仓库。
  • 亚马逊似乎只有 134 名员工活跃在 GitHub 上，他们推送代码到仅仅 158 个顶级项目上。
  • 不是所有的项目都一样：在超过 25% 的仓库上谷歌员工要比微软员工贡献的多，而那些仓库得到了更多的星标（53 万对比 26 万）。亚马逊的仓库 2017 年合计才得到了 2.7 万个星标。

红帽、IBM、Pivotal、英特尔和 Facebook

如果说亚马逊看起来被微软和谷歌远远抛在了身后，那么这之间还有哪些公司呢？根据这个排名来看，红帽、Pivotal 和英特尔在 GitHub 上做出了巨大贡献：

注意，下表中合并了所有的 IBM 地区域名（各个地区会展示在其后的表格中）。

Facebook 和 IBM（美）在 GitHub 上的活跃用户数同亚马逊差不多，但是它们所贡献的项目得到了更多的星标（特别是 Facebook）：

接下来是阿里巴巴、Uber 和 Wix：

以及 GitHub 自己、Apache 和腾讯：

百度、苹果和 Mozilla：

（LCTT 译注：很高兴看到国内的顶级互联网公司阿里巴巴、腾讯和百度在这里排名前列！）

甲骨文、斯坦福大学、麻省理工、Shopify、MongoDb、伯克利大学、VmWare、Netflix、Salesforce 和 Gsa.gov：

LinkedIn、Broad Institute、Palantir、雅虎、MapBox、Unity3d、Automattic（WordPress 的开发商）、Sandia、Travis-ci 和 Spotify：

Chromium、UMich、Zalando、Esri、IBM (英)、SAP、EPAM、Telerik、UK Cabinet Office 和 Stripe：

Cern、Odoo、Kitware、Suse、Yandex、IBM (加)、Adobe、AirBnB、Chef 和 The Guardian：

Arm、Macports、Docker、Nuxeo、NVidia、Yelp、Elastic、NYU、WSO2、Mesosphere 和 Inria：

Puppet、斯坦福（计算机科学）、DatadogHQ、Epfl、NTT Data 和 Lawrence Livermore Lab：

我的分析方法

我是怎样将 GitHub 用户关联到其公司的

在 GitHub 上判定每个用户所属的公司并不容易，但是我们可以使用其推送事件的提交消息中展示的邮件地址域名来判断。

  • 同样的邮件地址可以出现在几个用户身上，所以我仅考虑那些对此期间获得了超过 20 个星标的项目进行推送的用户。
  • 我仅统计了在此期间推送超过 3 次的 GitHub 用户。
  • 用户推送代码到 GitHub 上可以在其推送中显示许多不同的邮件地址，这部分是由 GIt 工作机制决定的。为了判定每个用户的组织，我会查找那些在推送中出现更频繁的邮件地址。
  • 不是每个用户都在 GitHub 上使用其组织的邮件。有许多人使用 gmail.com、users.noreply.github.com 和其它邮件托管商的邮件地址。有时候这是为了保持匿名和保护其公司邮箱，但是如果我不能定位其公司域名，这些用户我就不会统计。抱歉。
  • 有时候员工会更换所任职的公司。我会将他们分配给其推送最多的公司。

我的查询语句

#standardSQL
WITH
period AS (
  SELECT *
  FROM `githubarchive.month.2017*` a
),
repo_stars AS (
  SELECT repo.id, COUNT(DISTINCT actor.login) stars, APPROX_TOP_COUNT(repo.name, 1)[OFFSET(0)].value repo_name 
  FROM period
  WHERE type='WatchEvent'
  GROUP BY 1
  HAVING stars>20
), 
pushers_guess_emails_and_top_projects AS (
  SELECT *
    # , REGEXP_EXTRACT(email, r'@(.*)') domain
    , REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain
  FROM (
    SELECT actor.id
      , APPROX_TOP_COUNT(actor.login,1)[OFFSET(0)].value login
      , APPROX_TOP_COUNT(JSON_EXTRACT_SCALAR(payload, '$.commits[0].author.email'),1)[OFFSET(0)].value email
      , COUNT(*) c
      , ARRAY_AGG(DISTINCT TO_JSON_STRING(STRUCT(b.repo_name,stars))) repos
    FROM period a
    JOIN repo_stars b
    ON a.repo.id=b.id
    WHERE type='PushEvent'
    GROUP BY  1
    HAVING c>3
  )
)
SELECT * FROM (
  SELECT domain
    , githubers
    , (SELECT COUNT(DISTINCT repo) FROM UNNEST(repos) repo) repos_contributed_to
    , ARRAY(
        SELECT AS STRUCT JSON_EXTRACT_SCALAR(repo, '$.repo_name') repo_name
        , CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64) stars
        , COUNT(*) githubers_from_domain FROM UNNEST(repos) repo 
        GROUP BY 1, 2 
        HAVING githubers_from_domain>1 
        ORDER BY stars DESC LIMIT 3
      ) top
    , (SELECT SUM(CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64)) FROM (SELECT DISTINCT repo FROM UNNEST(repos) repo)) sum_stars_projects_contributed_to
  FROM (
    SELECT domain, COUNT(*) githubers, ARRAY_CONCAT_AGG(ARRAY(SELECT * FROM UNNEST(repos) repo)) repos
    FROM pushers_guess_emails_and_top_projects
    #WHERE domain IN UNNEST(SPLIT('google.com|microsoft.com|amazon.com', '|'))
    WHERE domain NOT IN UNNEST(SPLIT('gmail.com|users.noreply.github.com|qq.com|hotmail.com|163.com|me.com|googlemail.com|outlook.com|yahoo.com|web.de|iki.fi|foxmail.com|yandex.ru', '|')) # email hosters
    GROUP BY 1
    HAVING githubers > 30
  )
  WHERE (SELECT MAX(githubers_from_domain) FROM (SELECT repo, COUNT(*) githubers_from_domain FROM UNNEST(repos) repo  GROUP BY repo))>4 # second filter email hosters
)
ORDER BY githubers DESC

FAQ

有的公司有 1500 个仓库，为什么只统计了 200 个？有的仓库有 7000 个星标，为什么只显示 1500 个？

我进行了过滤。我只统计了 2017 年的星标。举个例子说，Apache 在 GitHub 上有超过 1500 个仓库，但是今年只有 205 个项目得到了超过 20 个星标。

这表明了开源的发展形势么？

注意，这个对 GitHub 的分析没有包括像 Android、Chromium、GNU、Mozilla 等顶级社区，也没有包括 Apache 基金会或 Eclipse 基金会，还有一些其它项目选择在 GitHub 之外开展起活动。

这对于我的组织不公平

我只能统计我所看到的数据。欢迎对我的统计的前提提出意见，以及对我的统计方法给出改进方法。如果有能用的查询语句就更好了。

举个例子，要看看当我合并了 IBM 的各个地区域名到其顶级域时排名发生了什么变化，可以用一条 SQL 语句解决：

SELECT *, REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain

当合并了其地区域名后， IBM 的相对位置明显上升了。

回音

接下来

我以前犯过错误，而且以后也可能再次出错。请查看所有的原始数据，并质疑我的前提假设——看看你能得到什么结论是很有趣的。

感谢 Ilya Grigorik 保留的 GitHub Archive 提供了这么多年的 GitHub 数据！

想要看更多的文章？看看我的 Medium、在 twitter 上关注我 并订阅 reddit.com/r/bigquery。试试 BigQuery，每个月可以免费分析 1 TB 的数据。

via: https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

作者：Felipe Hoffa 译者：wxy 校对：wxy

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

Google 开发的这个容器管理系统很快成为开源历史上最成功的案例之一。

Kubernetes 是一个在过去几年中快速蹿升起来的开源的容器管理系统。它被众多行业中最大的企业用于关键任务，已成为开源方面最成功的案例之一。这是怎么发生的？该如何解释 Kubernetes 的广泛应用呢？

Kubernetes 的背景：起源于 Google 的 Borg 系统

随着计算世界变得更加分布式、更加基于网络、以及更多的云计算，我们看到了大型的 独石 monolithic 应用慢慢地转化为多个敏捷微服务。这些微服务能让用户单独缩放应用程序的关键功能，以处理数百万客户。除此之外，我们还看到像 Docker 这样的容器等技术出现在企业中，为用户快速构建这些微服务创造了一致的、可移植的、便捷的方式。

随着 Docker 继续蓬勃发展，管理这些微服务器和容器成为最重要的要求。这时已经运行基于容器的基础设施已经多年的 Google 大胆地决定开源一个名为 Borg 的项目。Borg 系统是运行诸如 Google 搜索和 Gmail 这样的 Google 服务的关键。谷歌决定开源其基础设施为世界上任何一家公司创造了一种像顶尖公司一样运行其基础架构的方式。

最大的开源社区之一

在开源之后，Kubernetes 发现自己在与其他容器管理系统竞争，即 Docker Swarm 和 Apache Mesos。Kubernetes 近几个月来超过这些其他系统的原因之一得益于社区和系统背后的支持：它是最大的开源社区之一（GitHub 上超过 27,000 多个星标），有来自上千个组织（1,409 个贡献者）的贡献，并且被集中在一个大型、中立的开源基金会里，即原生云计算基金会（CNCF）。

CNCF 也是更大的 Linux 基金会的一部分，拥有一些顶级企业成员，其中包括微软、谷歌和亚马逊。此外，CNCF 的企业成员队伍持续增长，SAP 和 Oracle 在过去几个月内加入白金会员。这些加入 CNCF 的公司，其中 Kubernetes 项目是前沿和中心的，这证明了有多少企业投注于社区来实现云计算战略的一部分。

Kubernetes 外围的企业社区也在激增，供应商提供了带有更多的安全性、可管理性和支持的企业版。Red Hat、CoreOS 和 Platform 9 是少数几个使企业级 Kubernetes 成为战略前进的关键因素，并投入巨资以确保开源项目继续得到维护的公司。

混合云带来的好处

企业以这样一个飞速的方式采用 Kubernetes 的另一个原因是 Kubernetes 可以在任何云端工作。大多数企业在现有的内部数据中心和公共云之间共享资产，对混合云技术的需求至关重要。

Kubernetes 可以部署在公司先前存在的数据中心内、任意一个公共云环境、甚至可以作为服务运行。由于 Kubernetes 抽象了底层基础架构层，开发人员可以专注于构建应用程序，然后将它们部署到任何这些环境中。这有助于加速公司的 Kubernetes 采用，因为它可以在内部运行 Kubernetes，同时继续构建云战略。

现实世界的案例

Kubernetes 继续增长的另一个原因是，大型公司正在利用这项技术来解决业界最大的挑战。Capital One、Pearson Education 和 Ancestry.com 只是少数几家公布了 Kubernetes 使用案例的公司。

Pokemon Go 是最流行的宣传 Kubernetes 能力的使用案例。在它发布之前，人们都觉得在线多人游戏会相当的得到追捧。但当它一旦发布，就像火箭一样起飞，达到了预期流量的 50 倍。通过使用 Kubernetes 作为 Google Cloud 之上的基础设施层，Pokemon Go 可以大规模扩展以满足意想不到的需求。

最初作为来自 Google 的开源项目，背后有 Google 15 年的服务经验和来自 Borg 的继承- Kubernetes 现在是有许多企业成员的大型基金会（CNCF）的一部分。它继续受到欢迎，并被广泛应用于金融、大型多人在线游戏（如 Pokemon Go）以及教育公司和传统企业 IT 的关键任务中。考虑到所有，所有的迹象表明，Kubernetes 将继续更加流行，并仍然是开源中最大的成功案例之一。

作者简介：

Anurag Gupta - Anurag Gupta 是推动统一日志层 Fluentd Enterprise 发展的 Treasure Data 的产品经理。 Anurag 致力于大型数据技术，包括 Azure Log Analytics 和如 Microsoft System Center 的企业 IT 服务。

via: https://opensource.com/article/17/10/why-kubernetes-so-popular

作者：Anurag Gupta 译者：geekpi 校对：wxy

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

  1. 1
  2. ...
  3. 140
  4. 141
  5. 142
  6. 143
  7. 144
  8. 145
  9. 146
  10. ...
  11. 242