为了缓解人们对谷歌统治的担忧，Istio重组了其指导委员会

虽然有些人可能永远不会忘记最初由谷歌和IBM创建的Istio服务网将不会移交给云本地计算基金会(CNCF)的事实，但该项目在过去一周迈出了一大步，以安抚那些批评该项目处于谷歌多数控制之下的人：Istio引入了一个新的Istio指导委员会。

根据这篇博客文章，新的指导委员会将由13个席位组成，其中有4个“选举产生的社区席位”和9个“按比例分配的捐款席位”，他们说，这一变化“巩固了我们对开放治理的承诺，确保项目周围的社区始终能够指引方向，没有一家公司拥有项目的多数投票控制权。”这最后一点确实是在这里宣布的关键，他们后来更进一步、更明确地澄清，“没有一家供应商，无论他们的贡献有多大，都不能对Istio项目拥有多数投票权。”为此，他们写道，他们已经“对一家公司可以持有的席位数量实施了上限，这样他们既不能一致赢得投票，也不能否决委员会其他成员的决定。”

我还记得，当宣布Istio不会加入CNCF时，所有的反弹。奇怪的是，当像https://t.co/0JeNoDyzmx这样的事情宣布时，很少有人谈论正在发生的好事，因为中立地说，是的，这是一件好事！

至於该等议席如何分配，四个社区议席将由来自四个不同团体的四名代表组成，并会在每年一度的选举中选出。9个捐款席位将被分配给至少3家不同的公司，“按照过去12个月对Istio的捐款比例”，今年的衡量标准是合并拉动请求。Istio团队将其捐赠席位的方法与Kubernetes的方法进行了比较，他们写道，“在Kubernetes，人们的口头禅是‘砍柴、运水’，我们同样希望通过贡献来奖励那些推动项目增长的公司。”

这里有一个关键词-“公司”-被几个评论者选中，包括Kubernetes的联合创建者Joe Beda在云本地计算基金会(Cloud Native Computing Foundation)技术监督委员会关于这个话题的帖子中的评论。贝达写道，“一个值得强调的重大区别是，Istio模式似乎将所有贡献归功于公司，而不是个人。这意味着社区是由供应商定义的，而不是贡献者。“。贝达进一步假定，如果有人离开了一份工作，从而离开了一家公司，他们可能不得不放弃在指导委员会的职位，这与库伯内斯的“社区重于产品或公司”的价值形成了鲜明对比。

亚马逊网络服务马修·威尔逊(Matthew Wilson)也同样对这一措辞提出异议，他在推特上表达了对关注企业实体而不是个人的不满，Kative联合创始人马特·摩尔(Matt Moore)似乎呼应了他的担忧。

我将在另一座山上死去：将#OpenSource贡献(例如，合并的公关数量)归因于公司(不承认个人)，并根据该数字计算公司“赚取”的“席位”数量，这是一种建立社区的糟糕方式。

这就是当一家公司想要“玩弄社区”，但却把员工当作可互换的齿轮时，你得到的结果。

在开源社区中建立信任往往被低估和低估。失去一位我逐渐信任的社区成员总是让我感到难过。

威尔逊进一步指出，最有意义的开源贡献往往是由“忠诚的个人”做出的，他认为开源项目不应该“仅仅为那些付账的公司授予巨大的荣誉，而不是认知性的劳动。”New Stack分析师劳伦斯·赫克特(Lawrence Hecht)在推特上写道，这种关注的含义是“公司将不太可能允许开发人员将工作时间花在处理治理问题上”。

尽管如此，Weaveworks首席执行官Alexis Richardson在给CNCF技术运营委员会的信息中指出，Istio的指导委员会实际上“突出了[指导委员会]模式的一些好处，”包括指导委员会在整个项目中的广泛应用，而不仅仅是回购，它鼓励拥有非编码成员的多样性，以及它的重点是“代表最终用户和社区的总体方向(避免我们在其他情况下看到的开放核心问题)。”

谷歌推出每月一次的开源会议：谷歌宣布从9月1日开始的一系列虚拟活动-谷歌开源现场(Google Open Source Live)。3，活动的重点是“新的开源：领导力、贡献和可持续性”。这些活动将包括现场问答环节以及某种形式的“事后聚会”。课程安排在下一个日历年，Kative Day，Go Day，以及Kubernetes的一天将在这一年结束。

看看Google对Go的使用：对于那些对Go感兴趣的人来说，该公司发布了三个关于它自己使用Go语言的新案例研究，它早在2009年就开始开发这门语言了。这些研究着眼于Google的核心数据团队如何用基于Go的微服务系统取代单一的C++实现，如何构建Chrome Optimation Guide服务器，以及如何将Firebase后端从Node.js迁移到Go。除了新的案例研究外，该公司还简要概述了该语言的其他用途。该公司表示，这一用途始于2011年推出的Go on App Engine，并开始为YouTube与Vitess的数据库流量提供服务。

A Go 1.15概述：既然我们在这里，我们有一个倒数第二个与谷歌相关的部分，该公司提供了对本月早些时候发布的Go 1.15重大改进的简要回顾。要点是1.15带来了“大量的性能改进”，编译器的变化“减少了大约5%的二进制大小，并改进了构建围棋应用程序的速度，使其平均速度提高了20%左右，需要的内存平均减少了30%。”

Jetpack Compose Alpha首次亮相：本周，谷歌发布了Jetpack Compose Alpha，这是谷歌发布的最后一个与谷歌相关的花絮，这是一个用于构建Android应用的UI工具包。Jetpack Compose是一些你的Android开发人员已经熟悉的东西的组合，比如Android Jetpack，它提供了一套库，以及Kotlin编程语言，谷歌最近大力支持Kotlin编程语言，现在说“60%的支持Android的开发人员”都在使用它。除此之外，Jetpack Compose还添加了“用于构建UI的声明性API的简单性”，以及一组规范的示例应用程序。如果你有兴趣尝试一下，有一个写作教程或设置，如果你准备去做，但不要太难写-不推荐完全生产使用，因为团队正在努力实现API的稳定性和完成性能优化。Compose 1.0预计将于2021年发布。

GitHub升级到Ruby2.7：GitHub在7月份全面转向在生产中使用Ruby2.7，现在该公司已经对该过程进行了回顾。根据这篇博客文章，为了运行“不建议使用”的Ruby2.7，他们有超过11000个警告需要修复，团队提供了他们的策略，部分归结为设置了他们的40万行代码应用程序在Ruby 2.6和2.7中都是双引导的，这样他们就可以“进行向后兼容的更改，将这些更改合并到主分支中，并且避免为我们的升级维护长时间运行的分支”。GitHub还设计了一个流程，以降低部署期间的风险，涉及到双构建，基本上是一次做一点，整个推出大约需要两个小时。他们写道：“对于任何想知道这次升级是否值得的公司来说，答案是：100%。”“即使没有性能改进，落后于Ruby升级也会对代码库的稳定性产生巨大的负面影响。”