源码

首页 » 归档 » 源码 » 从 2,000 到 25,000 工程师,微软开源如何制霸 GitHub?

从 2,000 到 25,000 工程师,微软开源如何制霸 GitHub?

【CSDN 编者按】自微软“豪掷千金”收购 GitHub 以来,其在开源方面的动作也一直不断。在这些背后,离不开微软强大的工程师团队。可以说,微软在开源方面的心血付出不是一般公司可以企及的。那么在微软 GitHub 的工程师从 2 千人逐步扩展到了 2 万 5 千人的过程中,微软在此之上又付出了哪些努力呢?——本文中,微软开源程序办公室的软件开发工程师 Jeff Wilcox 就为我们带来了深度的解读。

image.png

作者 | Jeff Wilcox

译者 | 弯月 责编 | 屠敏

出品 | CSDN(ID:CSDNnews)

以下为译文:

目前在微软,我们有将近2万5千名工程师参与了GitHub上的官方组织来为开源做贡献,其中很多人为GitHub的开源社区做出了卓越的贡献。这个发展速度非常快,2015年我在Azure开源社区说过,我们的工程师人数从20名扩展到了2千名,而时至今日这个数字又增至了10倍。

作为微软开源项目办公室团队(Microsoft's Open Source Programs Office,简称OSPO)的一员,我对这种快速增长感到十分欣喜,我打算记录下我们付出的努力,供其他人参考。

我通过一个开源项目收集数据,查询GitHub的实体数据,并创建了如下自2011年以来微软公开代码仓库的数量图:

640?wx_fmt=png

我们的员工中有一部分人从很久以前就开始为GitHub上的项目做贡献,分享他们的想法和见解。而许多团队成员对于在公开的环境中编程没有太多经验,他们希望OSPO提供文档和指导。

一部分工程师忙于为GitHub上的各种项目做贡献,将他们的时间、代码或整个项目都奉献给了开源。很多人会利用工作时间辛勤地为开源工作,也有一些人会利用下班后的时间,或者只是偶尔尝试。virtual-kubelet(https://github.com/virtual-kubelet/virtual-kubelet)是一个属于云原生计算基金会的项目,上面的贡献者中就有一些熟悉的名字,他们都与我合作过。

多年来,Visual Studio Code团队一直在如火如荼般地快速发展。整个社区中有很多来自世界各地的精英人才,他们每天都会创建新的问题,执行代码审查,并为VSCode贡献代码。

这些团队在寻找新的沟通方式,建立共识和管理模型,并邀请维护人员参与其中。

我将通过这篇文本介绍:

  • 开源项目办公室用于指导开源和GitHub体验的核心原则

  • 我们为扩展GitHub而投入的技术

  • 编程投入

  • 重点学习

  • 展望未来

  • 本文中提到的开源项目的相关资源

我会重点介绍我们在大方向上参与GitHub的战术方针,而不会太多提及特定项目的经验——但我也希望能分享一些具体项目的经验,如Terminal、TypeScript、Accessibility Insights和Windows Calculator等。

我们非常努力地建立正确的体验,让工程师们能拥有一切所需的东西,而不会被OSPO团队阻碍。

毋庸置疑,开源是帮助我们扩大规模的重要因素,我们也在力所能及的地方尽力回馈和奉献:

  • 我们采用了CLA(Contributor License Agreement,贡献者授权协议)辅助,这是一个由SAP发动的开源项目,现在我们也在为该项目做贡献(我们放弃了自家颇有年头的CLA机器人!)

  • 我们采用了由亚马逊构建的开源引擎。

  • 我们的自助GitHub管理工具是开源的。

  • 我们通过Clearly Defined开展合作,这是一个OSI项目,能够爬取所有的开源项目,从而获取各个项目的授权、版权和其他数据,然后开放的方式管理并分享这些数据。

  • 为了转移到更通用的开源服务和系统上(比如容器、Postgres和MongoDB),我们的团队投入了大量精力,目的只是为了方便其他公司利用他们喜欢的技术栈参与合作。

展望未来,为了发展我们的能力,我们还有大量工作要做,包括持续改进我们的成熟度模型,朝着更健康更优秀的项目发展,帮助毕业生进入社区和基金会,并持续快速迭代、实验,以及从这一切中吸取经验。

我非常期待再过几年我们能发展到什么程度,同时开源项目在整个行业中的协作、围绕微软的技术而不断发展的社区,以及微软的工程师们为GitHub的各种项目做出的贡献,这所有的一切极大地鼓舞了我。


我们采用的原则


为了鼓励正确的行为,教授微软员工如何使用GitHub并参与社区,我们就OSPO的工作制定了一系列原则,来规范我们的工具链和工作流程。

例如,我们鼓励各个团队在GitHub上开放地工作、学习工具和语言。

解决问题与简化流程

如果复杂的工作流程不能提供相应的回报或价值,那么还不如去掉这些复杂的工作流程,减少工程师们的工作量。

如果我们需要就工程师们即将开源的项目提问,那么就应该重点考虑我们想要解决的问题,而且必须能够在与项目利益相关者和顾问们一起仔细考虑问题的后果后,解决掉以前问过的问题。

回顾五年以来,我们曾有许多手动的注册系统,工程师需要通过这些系统告诉我们他们使用了哪些开源软件。通常这些系统都是自由填写的文本框,而许多团队只会尽力去分享这些信息。

如今,我们通过检测各种情形下开源的使用情况,干掉了大部分注册流程,仅在必要或需要更多信息的时候,针对特定项目询问一些问题或实施审查流程。

有时我们无法简化流程,但如果我们不断质疑流程和指南,并要求使用这些系统的团队提供反馈和建议,那么就有希望尽可能简化流程。

自助服务

由于团队的规模巨大,因此我们不能成为拦路虎,而且我们信任我们的工程师,并希望鼓励他们从实际经验中学习。我们需要确保用户了解GitHub的团队,了解如何请求加入这些团队。

如果没有自助式服务,让工程师们根据自己的节奏学习并参与我们在GitHub上建立的组织,那么我们就不可能如此迅速地让2万5千人在GitHub上展开合作。

按照传统的习惯,组织的拥有者必须向特定的用户名或邮件地址发送GitHub邀请,而这种方式在我们的规模下根本行不通。不过幸好GitHub有API,还有GitHub的管理面板,我们才能顺利地管理。

我们会尽可能地提供文档、指南以及其他可重用的资源,这样就无需依赖于特定的知识,也不需要依赖手工的流程操作。

委托

我们的办公室提供一些指南和资源,帮助微软的业务按照各自的方式来向开源做贡献,以及使用和发布开源,但我们让各个业务自行做业务上的决定。

诸如是否要通过开源方式来发布之类的决定,我们通过问答的方式进行,而成果可以是自动批准,也可以执行业务批准流程,如此一来各个团队的业务和法务代表就可以做出最后的决定和抉择。

我们还设置了“开源冠军”的角色:这些人可以帮忙宣传开源,并针对如何看待的问题,为其他的团队提供想法和建议。

透明度

开源重视协作,但如今对于拥有一大堆代码仓库的GitHub组织来说,最大的困难之一就在于,确定哪些团队能够接受拉取请求或访问管理设置。

虽然GitHub会给组织内的团队显示许多数据,还能深入特定团队的信息,但只要你不是管理员,就不能查看指定代码仓库的团队信息。

对于我们所有的代码仓库、发布和审核:

  • 我们的首页显示了控制每个代码仓库的团队

  • 所有发布请求和数据都保存在工作项目中,每个员工都可以访问

  • 我们的GitHub管理首页会显示所有GitHub团队,包括“秘密”团队(即隐藏团队)

  • 我们的首页支持跨组织搜索,这样更方便在所有组织中找到名称相似的团队和代码仓库,减少困惑和内部支持的开销

多亏了该系统,我们在上千个代码仓库中寻找公司内的项目中的特定人员时才不那么痛苦。

GitHub的原生体验

工程师应该学习如何使用GitHub的接口,学习拉取请求、代码审核、问题、分叉、组织团队以及合作功能的原理。

我们希望用户尽可能地直接到GitHub上管理他们的团队,配置团队维护者,欢迎新的社区成员作为维护者或贡献者加入团队。

虽然我们有独立的内部接口和工具,但理想情况下这些都可以用来增强原生的体验,我们做了一个浏览器扩展,用户安装该扩展后,就可以更方便地在GitHub上查找员工、资源或内部工具。

对我们来说,工程师能够从GitHub的贡献方式(即分叉和拉取请求模型)中学到技术非常重要,因此我们对于“内部代码”的工作方式也尽量采用相似的体验。


技术投入


我们的工程团队在扩大公司规模、更好地参与开源方面做了大量的技术投入。

我们尽可能地使用开源,发展开源,并将经验和贡献分享给其他公司和个人使用。

我们会在必须的时候在工具上投入精力,但也会关注市场和其他人的工作。我们很希望看到GitHub企业云产品的发展,并希望通过各种新功能和能力简化企业级开源。

采用CLA助手

如今,在CLA管理方面我们运行了一个开源项目的实例——CLA助手,它能够与GitHub集成。有了这个工具,我们就可以在接受贡献时确保做贡献的人签署正确的CLA。

在社区成员签署了CLA后,就能够为所有的代码仓库做贡献,因此减轻了我们的律师的负担。

640?wx_fmt=png

CLA助手是一个由SAP发起的开源项目,其本身的授权是Apache 2.0。

我们为该项目贡献了一些功能,帮助解决规模扩展的问题,还添加了访问速率限制、员工入职和离职时的自动签名等功能。该项目的其他贡献者还添加了许多功能,比如支持新的企业CLA等。

2017年,我们放弃了自家的CLA机器人,采用了这个开源解决方案。我很高兴看到VSCode团队通过GitHub问题(#34239)向社区公布了这个消息。

该系统由GitHub的组织级别的webook提供支持,所以它是“常开”状态,团队不需要担心他们的代码仓库是否启用了CLA,是否可以接受贡献。

数据和洞察

GitHub提供了许多有用的信息,比如流量统计、贡献者信息,以及许多代码仓库级别的详细信息。

但是我们需要在微软的所有开源项目中,对数据进行分割,找出随着时间推移的趋势、大规模地分析投入。于是,我们意识到,我们需要把GitHub开源发布中的所有数据导入到自己的大数据系统中,例如Azure Data Lake和Azure Data Explorer。

新的GitHub企业云提供的功能可以提供组织需要的洞察,我们很高兴通过尝试这些功能来增强现有的数据和洞察。

下面是我们曾经使用过、创建过或合作过的一些项目。

GHTorrent

我们的团队是GHTorrent项目的支援者之一,该项目旨在创建可扩展、可查询的离线镜像数据,这些数据以GitHub REST API的方式提供。该项目的地址为:github.com/gousiosg/github-mirror。

这些数据与GHArchive类似,可以用来研究GitHub上无处不在的协作。

该项目由项目创建者Georgios Gousios和Diomidis Spinellis合作运营,我们为其贡献了云计算资源。

在微软,我们将数据导入Azure Data Lake,然后运行各种查询来研究趋势。

GHCrawler

GHCrawler是一个健壮的GitHub API爬虫,可以遍历一系列GitHub对象,获取并存取其中的内容,最初该项目创建于2016年,在2017年6月的TODO Group tools的黑客马拉松期间迅速发展,同时还与其他公司合作,将数据存储进行抽象,以支持其他技术栈。

这个爬虫教会了我们许多东西,包括如何使用GitHub API,以及如何友好地爬取页面——包括缓存对象、使用e-tags,不要反复获取同一个资源等。

与GHTorrent不同,该爬虫能够借助token遍历微软自己的开源组织,获取有关维护者、配置、私有代码仓库的信息,因此非常有助于解答有关微软内部GitHub增长情况的问题。

我们将GHCrawler的数据导入Azure Data Lake和Azure Data Explorer,并将其用在Power BI控制板和报告中,或者在内部网站上实时显示数据,等等。

本文开头的新代码仓库趋势图就是通过查询Azure Data Explorer中保存的该爬虫的数据而生成的。下面这个查询能返回最近30天微软官方组织上创建的(公开)代码仓库:

640?wx_fmt=png

由于这些数据来自GitHub,但存储在内部,所以团队可以将这些数据用于自己的业务需求,而无需考虑GitHub的API访问速率限制,从而可以专注于如何有效利用该数据来解决业务问题。

许多希望建立新社区的团队都喜欢的资源就是有关拉取请求和问题的数据,以及API访问的数据。由于GitHub只提供以两周为周期的综合数据,因此在大数据工具中存储数据更方便我们了解趋势。

ClearlyDefined

ClearlyDefined是一个OSI(Open Source Initiative,开源动议)项目,它的任务是为FOSS项目提供“清晰的定义”以帮助其成长。缺乏清晰的授权会减少参与,最终导致项目缺乏用户、缺乏贡献者,社区也无法成长。

社区按照自己喜欢的条款选择授权。对于成功的社区协作而言,定义并了解开源项目的授权非常重要。ClearlyDefined通过识别关键数据(例如授权集合、归属方、代码位置等)来明晰授权,如果缺乏数据,还可以参考手工精选的数据。

微软为该项目做出了贡献,并在团队使用的工具中利用该项目提供清晰的授权,以帮助团队更好地理解开源的使用。

到2019年6月为止,ClearlyDefined已有630多万个定义(https://clearlydefined.io/stats)。这些定义是各个开源项目运行licensee、scancode-toolkit、fossology等工具产生的。

repolinter

TODO工作组项目OSPO协作依赖的另一个工具是repolinter。

repolinter可以就给定的源代码仓库给出基本信息,帮助判断该项目是否拥有孵化并构建健康的社区所需的一切,如:

  • 授权文件

  • README文件

  • 行为准则(Code of Conduct),该文件包含一切有关贡献的信息

  • 不包含二进制文件

  • 能被licensee检测出的授权

  • 源文件头部包含授权信息

我们希望能以更可视化的方式分享这些数据,帮助团队判断哪里可以改进,甚至能够在缺少重要组成部分(例如没有行为准则)时自动创建拉取请求。

oss-attribution-builder

我们与亚马逊合作,使用amzn/oss-attribution-builder项目构建开源授权通知文件,帮助团队满足法律要求。

GitHub管理网站

微软员工使用微软的GitHub管理网站来处理以下工作(2015年我写过一篇文章介绍该网站https://jeffwilcox.blog/2015/11/azure-on-github/:)

  • 新员工加入组织时的自助式服务

  • 跨组织搜索人员、代码仓库和团队

  • 负责维护数据的支持性工作

  • 生成摘要和报告

  • 缓存GitHub REST API的响应

  • 处理webhook事件

如图中所示,你可以在同一个地方对所有GitHub组织进行搜索、排序、过滤,从而很方便地查找内容。

640?wx_fmt=png

该网站自身也是开源的,在过去几年内经历了重建和重构,现在变得更为实用,而且其他公司也可以使用该网站进行以下工作:

  • 基于Node的服务和网站,用TypeScript实现

  • 后台存储支持PostgreSQL,还可以通过接口支持其他存储

  • 自带“在本地内存中运行”选项

GitHub上该代码库的地址为:https://github.com/microsoft/opensource-portal。

新建代码库向导

尽管我们的政策很自由、很友好,工程团队可以很容易地决定分享一些代码(比如示例代码),但我们还是希望能在涉及到主要发布时建立一个流程,让业务决策和法务团队能参与其中。

微软选择关闭我们的开源GitHub组织中的“允许成员创建代码仓库”选项,转而采用我们的GitHub管理工具中提供的“新建代码库向导”功能。该网站会收集一些信息,比如代码库的目的、工程师开始工作所需的常见GitHub团队权限,然后用标准的微软开源内容(如行为准则、README、适当的LICENSE文件、代码库的初衷和使用方法)来建立初始代码库。

640?wx_fmt=png

我们在文档和工具(比如之前提到的开源助手浏览器扩展)中下了很大功夫,方便人们找到该功能。该浏览器扩展能够修改我们组织中的“新建代码仓库”按钮,将其直接链接到向导上,这样的体验远远好于GitHub本身的“你没有权限创建新代码仓库”的消息。

该向导会在GitHub上创建公有或私有仓库。

根据政策,我们会要求团队只能把我们的开源GitHub组织用于未来30天内会发布的项目上。

发布审核

新建代码库向导会产生一个自动批准的公有项目,或者触发一个业务和法务审核流程来保证项目符合政策,同时将重要的开源决定通知给项目负责人。

我们有一个内部服务Usage Service,其会在我们的工作跟踪系统(Azure Boards)上创建一个工作项,并指派给适当的法务和业务审核员。然后该工作项会在传递的过程中不断完善,不断讨论,最终审核会达到“最终批准”的状态,团队就可以向全世界发布其项目并构建社区了。

下面的截图显示了Windows Calculator的发布审核工作项,隐去了一些细节和姓名:

640?wx_fmt=png

在最终批准后,系统会给最初的请求者自动发送一封邮件,写明审核过程中各个审核者给出的指导,帮助团队成员理解通知、法律要求或发布所需的工作。

开源助手浏览器扩展

在内部,我们发布了一个浏览器扩展,帮助我们在GitHub上添加一些微软专用的信息和指南。

由于一个人在公司内部的身份不一定跟GitHub用户名一致,所以该扩展在整个GitHub的许多地方都加强了企业功能,比如拉取请求、问题和个人信息等。

640?wx_fmt=png

该扩展能够在GitHub上高亮显示微软员工,如此一来使用该扩展的人就可以更好地关注社区的协作体验,而且也更容易地找出与他们合作的人。

该扩展保留了原生的GitHub体验,同时在许多地方做出了改进,比如禁止直接通过GitHub新建代码仓库等。

该扩展还提供了指向开源政策的链接,以及指向“新建代码仓库向导”的链接。

由于我们禁止了GitHub原生的代码仓库创建功能,并要求工程师完成向导以了解他们的开源发布的意图,我们常常会收到有关如何创建代码仓库的问题,因为GitHub会显示用户不能创建代码仓库的消息。

如今用户可以看到如下画面:

640?wx_fmt=png

在如下截图中,你可以看到一个“加入”按钮,员工可以通过GitHub管理网站的自助服务加入GitHub组织:

640?wx_fmt=png

最后,由于我们希望各个团队使用我们的官方GitHub组织,该组织已经自动配置了CLA系统、合规工具、审计日志,还能在用户加入和离开时自动管理生命周期,因此我们不允许团队创建新的GitHub组织。

我们更新了GitHub“新建组织”的页面,让人们了解我们的政策和其他资源,避免在尝试创建其他组织的路上越走越远。

640?wx_fmt=png

该扩展可以在Firefox、Chrome和最新版基于Chromium的Edge上使用。微软员工可以通过这个链接:aka.ms/1esassistant,了解更多信息并安装扩展。

尽管目前该扩展还没有开源,但如果其他人认为该扩展有帮助性,那么我们也愿意努力尝试。

常规自动化工作

我们实现了很多自动化工作,从更新数据和缓存,到确保GitHub组织的成员身份等各个方面都实现了自动化。

这些工作都是开源的,采用TypeScript实现,是opensource-portal代码仓库的一部分。

移除前员工

我们连接到了HR数据库,可以在员工离职时做出响应。在大公司中,人们会经常改变角色,尝试新的职位,有时也会离职寻找更好的机会。

我们会在员工离职时断开其连接:删除他们的GitHub账号与公司身份之间的关联,然后删除其GitHub组织成员身份。

我们欢迎前员工继续参与并贡献项目,他们可以继续作为维护者工作,但为了清晰起见,我们不允许他们继续作为组织成员工作。

我们也会给他们的经理发送邮件,这样经理能够确信权限和系统访问权方面的必要工作已经完成。

强制“系统团队”

为了实现运营、支持,并符合安全标准,支持CLA系统等机器人,我们在GitHub组织中配置了自动化工作,为每个代码仓库自动创建永久的GitHub团队。

该工作会监视GitHub的事件总线,当代码仓库创建时,在代码仓库中创建“系统团队”。而且,如果代码仓库管理员试图删除系统团队,或者修改系统团队的权限,该工作会自动恢复其权限。

还有一个定期执行的cronjob负责验证系统团队。

防止大规模权限授予

随着GitHub组织中的成员越来越多,团队也会变得越来越大。

在我们的团队中,人们可以轻松地给“所有员工成员”赋予私有代码仓库的读取权限,这样他们就可以在开源之前进行修整。

但我们发现了一个预料之外的副作用:有些人会为图方便简单地赋予了“所有成员”管理员权限,这样成员的入门过程可以大幅简化。

但问题在于管理员权限的权力很大,也就是说组织中数千名成员都可以删除该代码仓库,做出任何修改,覆盖分支保护,等等。

这也会导致数千名成员自动订阅毫无用处的通知信息。

因此,我们有“大规模权限”的自动化工作,监视针对“大量”成员赋予的写权限或管理员权限。一旦发生这种授权,而且团队规模过大,该工作就会自动将权限降级以防止错误,然后给发起权限变更的人发送邮件,告诉他们该行为的风险,并帮助他们理解实际做出了哪些变动。

GitHub用户名变更

GitHub允许用户改变用户名。这一点很棒,许多人最初采用了可爱的名字,或者昵称,但之后开始与别人合作专业开发软件时,通常都会希望改变用户名。

并非所有人都知道用户名可以修改,所以我们会遇到只是为了改名而注销账户的人。

但是,大多数GitHub应用和API都会使用GitHub用户名,而不是数字的用户ID。

为了应对该问题,我们建立了一个cronjob通过ID查找GitHub用户名,然后在内部数据库中刷新这些用户名,从而增加API访问成功的概率,减少改名时的支持成本。

对于关键性的操作,我们的GitHub应用中增加了额外的逻辑,提前应对可能出现的用户改名操作,并智能地在失败时以ID查找用户,或者给运营支持人员发送警告。

每周和每日摘要

我们还有一个cronjob会发送GitHub代码仓库中发生的变化和趣事。通常这些消息只会发送给代码仓库管理员,避免干扰太多人。

640?wx_fmt=png

如下摘要是根据收件人定制的,包含如下内容:

  • 通知代码仓库创建者及其经理新建仓库的行为

  • 当管理员人数过多时发通知,让团队维护者着手清理权限

  • 放弃多年没人使用的代码仓库

  • 当某个代码仓库只剩一个维护者时,建议他们多指定一两个维护者

  • 当某个代码仓库从私有改成公有时发通知


程序方面的投入


比技术工具更重要的是我们在开源程序办公室运行的程序,我们借助这些工具推动过程改进、对功能的了解、推出新功能,并用新的方式强调公开领域进行的工作。

下面是我们做出的一系列OSPO投入,目的是推动公司的开源成熟度。

文档

我们有一个中心文档仓库,任何员工都很容易访问。他们可以在这里阅读关于发布开源或为开源做贡献的指南。我们希望尚不了解众多开源工具和流程的团队可以参考这些资料,并与其他人共享,帮助我们扩大文档的影响范围。

下面是部分材料的提纲。我希望以后我们可以献上一份公开给全世界的文档。


- General Information  - What exactly is Open Source?  - When and why Open Source  - Can I use it?  - Misconceptions  - Bad Practices  - Benefits- Use  - Overview  - Security and vulnerability management  - Copyleft obligations  - Code signing  - Attribution guidelines  - Business review process  - Required notice generation  - Automated registration of use- Contribute  - Contribution overview  - Forking repositories  - Business review, if requiredRelease  - Release overview  - Checklist  - Copyright headers  - Foster your community  - Build and publish your project  - Code signing  - Business review, if requiredData and Insights  - GitHub insights  - Registrations and request insights- GitHub information  - GitHub overview  - Accounts and linking  - Repositories  - Teams  - Organizations  - Transferring and migrating repos  - Service accounts  - Two-factor authentication  - Apps, services and integrations  - Large files, LFS
  - When and why Open Source
  - Can I use it?
  - Misconceptions
  - Bad Practices
  - Benefits
Use
  - Overview
  - Security and vulnerability management
  - Copyleft obligations
  - Code signing
  - Attribution guidelines
  - Business review process
  - Required notice generation
  - Automated registration of use
- Contribute
  - Contribution overview
  - Forking repositories
  - Business review, if required
Release
  - Release overview
  - Checklist
  - Copyright headers
  - Foster your community
  - Build and publish your project
  - Code signing
  - Business review, if required
Data and Insights
  - GitHub insights
  - Registrations and request insights
- GitHub information
  - GitHub overview
  - Accounts and linking
  - Repositories
  - Teams
  - Organizations
  - Transferring and migrating repos
  - Service accounts
  - Two-factor authentication
  - Apps, services and integrations
  - Large files, LFS

每月的新闻邮件

团队每个月都会为公司的相关方(包括所有相关的GitHub用户)准备一份新闻邮件,需要发送给总计大约25,000人。该资源的频率不高,目的主要是在不增加团队负担的前提下提供有用的信息。

640?wx_fmt=png

通常,新闻邮件会包括三到五个主题,以及一些新消息、一些关于开源采用和社区健康度的数据图表,以及下一次开源聚会的日期。

开源聚会

640?wx_fmt=jpeg

我们每个月都会在微软园区举行(或在线举行)一次聚会。聚会一般从交际开始,然后是简易午餐,最后由三3-4名演讲者分享他们近期的开源经验。

聚会能够加强人与人之间的联系,促进交流,还能构建社区。

开源冠军

开源冠军是一些来自公司各个部门的“优秀”人才,他们是微软最优秀的开源人才,他们有人脉、有经验、有数据,有助于推进最佳实践,并就各种情况给出建议。

如今各位冠军主要活跃在特定的讨论组中,但未来他们也能与各自的组织分享信息,在公司范围内与更多的参与者和业务之间建立双向的沟通渠道。

冠军是重要组成部分,他们能帮助我们扩大规模并分享,并在专家和团队之间建立联系。

内部支持

OSPO通过内部支持体验帮助有需要的人,包括内部邮件、团队频道以及其他途径。

最常见的问题就是帮助他人找到他们需要的文档,告诉他们GitHub账号的连接方式,新建代码仓库向导,或者帮助澄清政策问题。

OSPO并不能回答所有问题,有时我们会建议人们联系自己组织的法务来解决问题。

还有一点很重要的是,在发现空白或可以改进的地方后,我们会更新内部文档和工具,如此一来下一拨有同样需求的人就无需再联系我们来寻求问题的答案了。

我们通过委托、自助服务和简化流程的方式来减少支持的成本,并在问题一发不可收拾之前将其解决。通常,一个良好的修改或有针对性的补丁就能解决大部分问题。

高管议会和简报

来自微软的各个业务部门的高管们组成了“OSS执行议会”,他们每个季度至少会聚会一次,讨论文化的发展进程,讨论各个组如何为开源做贡献,或者提供领导的途径,帮助开源冠军,以及我们的开源办公室。从多个角度来看,这个小组是OSPO团队的“董事会”,我们希望解决微软在开源世界里遇到的一切问题。

有了高管议会,我们就能衡量领导的水平,判断应该将我们的精力投入到哪里,应当如何解决复杂问题,怎样制定出能让工程师团队更加方便的流程。

我们还会将高管议会的决定以简报的形式发给业务领导,分享他人的发现,并为所有团队解决困难。


学习


我们学到了很多,随着全公司对开源接受度的提高,我们还会不断学习。我们有许多经验,例如怎样大规模运营开源项目,在工具和访问权限应当给团队多少的自由,以及如何利用这些经验帮助其他团队。

下面我们来介绍几个故事……

GitHub混乱时刻

GitHub很真实:今年初我们遇到了“混乱”事件。微软最大的GitHub组织中有个团队叫做“所有成员”,目的只是为了在新项目开始时,很方便地将私有代码仓库的访问权限赋予所有人。

其想法是,只要将代码仓库的读取访问权赋予“所有成员”,他们就能创建分叉并提交拉取请求,这要比判断哪些团队应该赋予哪些权限要方便得多。这种形式也能鼓励开放的贡献模型。

2017年末,GitHub团队讨论功能发布,而我们的开源团队已经有一段时间没有使用该功能了。

终于,在一月份的一天,出事了……

……有人在“本组织的所有成员”团队讨论中发布了一条消息,这条消息发送给了许多人……然后有人贴出了怎样更改通知设定……然后就一发不可收拾了。

我们从此次事件中吸取的几点经验教训为:

  • 人们了解GitHub讨论功能

  • 我们在GitHub的通知设定中发现了一些次要问题

  • 我们意识到大型团队的缺点

  • 整个过程也很欢乐

微软的老员工会心一笑。“混乱”(Bedlam)是微软的传统课程。但即使使用现代开发工具,我们依然也有类似的经历,这非常有意思……

双因素认证

令人惊讶的是,大量内部支持的问题都在于员工无法访问自己的GitHub账号。

由于我们要求用户使用GitHub双因素认证,而这个双因素认证系统和员工们同时使用的Azure Active Directory多因素认证是不同的,所以人们很容易搞混,或者干脆无法访问GitHub。

万幸的是,GitHub在提醒人们保存双因素认证码,以及推广其他技术(比如使用通用双因素认证设备)方面做得还不错。

每次iPhone出新的型号,我们的支持请求就会暴涨……许多人在手机上使用双因素认证,但会忘记备份认证码,或者在删除手机上的所有数据并升级到新手机上时,备份恢复没有达到预期的效果。

我强烈建议每个人都使用YubiKey,该工具可以方便GitHub的日常使用。

GitHub API:用户改名

大多数GitHub REST v3 API在操作时都采用了GitHub用户名,而不是用户ID。

GitHub允许用户改变用户名,这意味着如果不验证当前用户名,就会导致改过用户名的用户无法使用一部分API。

有一个GitHub API能够接受GitHub用户ID并返回用户当前信息,所以可以经常调用该API(比如在负责处理e-tags和缓存响应的每日定期脚本中进行调用)来确保调用API所用的用户名是正确的。

以微软的规模,我们每周大约能看到25个用户改名。

GitHub API:条件请求

如果缓存了请求的实体,那么可以使用e-tag和If-None-Match请求头来减少发往GitHub的请求数量,因为检查已存在的e-tag对应的实体是否改变的API,在实体未改变的情况下,不会计算在API限制内。

很高兴看到越来越多的函数库(如octokit/rest.js)以多种形式支持这一概念,或者可以在这方面扩展。

人们对GitHub API很友好。

关于团队权限和个人权限

我们强烈建议,微软旗下的各个代码仓库尽可能使用团队权限,而不要赋予个人权限。

GitHub团队功能可以支持多个团队维护者,有助于项目的长期发展,也方便根据需要分配访问权和管理权。

在这一点上我们对用户做了许多培训。如果用户提交一个支持请求,要求访问权限,我们绝不会赋予他们某个代码仓库的个人访问权限(即GitHub上的“合作者”),而是会要求他们在GitHub上创建一个适当的团队,并将权限赋给这个团队。

使用团队权限,拥有维护者的团队,避免个人权限。如此才能保证一切不会失控。

关于权限的透明度

前面说过,我们的GitHub管理网站会显示所有员工的团队权限,包括秘密团队。由于我们的关注点是在GitHub上支持开源,因此这个功能可以帮我们回答许多类似于谁有管理员权限、谁能改变代码仓库设置之类的问题,减少支持的工作量。

如果你是组织的成员,那么你可以在GitHub上看到一个团队拥有哪些代码仓库,拥有哪些权限。但是,你没办法看到某个代码仓库属于哪个团队。

管理网站上的透明数据能够减少GitHub显示“404你找的机器人不在这里”的错误消息。由于遇到组织成员无权访问的代码库时,GitHub会返回404的错误,所以我们收到过许多这类的支持请求,询问团队成员发给他们的URL是否真实存在。

GitHub付费

在我们通过巨资收购GitHub之前,我们在GitHub的组织账号上花了许多钱。我们需要私有代码仓库,供开发者发布开源代码。

在早期,很多人会使用公司的信用卡,或者需要公司报销GitHub费用。多年后,随着GitHub使用规模的增大,我们明确了这部分固定开销:集中支付GitHub组织的费用,减轻团队的工作负担,他们在设置新组织和新系统的时候无需再考虑付费的问题。

GitHub提供的按年付费方式非常实用,所以无需再顾虑按月使用公司信用卡或其他付款方式的问题,我们只需提交一次,然后付款即可。GitHub的销售团队也非常友好。

唯一的小问题在于,有几次我们不得不在年中改变LFS数据套餐……我们的解决方式是,在GitHub的采购订单上留出一些余量,这样GitHub的销售只需按照我们的需要为额外的数据提供账单即可。

在采用账单式付款之前,我们使用公司信用卡时,还需要财务团队审核批准。好在我们有专门的付款经理来管理这些事情,所以我们无需担心权限问题,也不用自己控制这些资源。

感谢友好的GitHub销售团队和支持团队,他们很愿意通过Zoom会议的方式讨论细节,例如怎样为我们的某些组织签署公司服务协议等。

GitHub按年付费的方式非常直观,可以减少一次性的公司信用卡支付的费用。

组织膨胀

微软的许多团队喜欢发布组织结构图,但在加强开源发布话题的问题上,我们希望所有代码库都归属于少数几个主要组织。

这样也可以方便工程师工作:他们在代码仓库上工作时,不需要同时识别组织和团队,他们只需要知道代码仓库的名字,或者团队的详细信息。

我们从2017年初就开始通过政策、工具及其他系统的强制措施,要求人们仅使用微软官方的GitHub组织。

这样做非常重要,能让人们直观地获取访问权,无需再考虑跨组织权限问题,也不用担心找不到东西。我们还知道,项目名和团队名经常发生改变,所以多个组织也无法应对规模扩张。虽然GitHub的改名功能为组织和代码仓库提供了一些灵活性,但我们更希望不要一次性更改太多东西。

五月份GitHub公布的新功能(如企业账号等)似乎对于解决该问题非常有帮助:如果能够将合规和账单功能结合在一起,也许我们就能在合理的地方使用多个组织。

关于你需要制定一个战略来决定你的组织需要在GitHub上建立多少个组织来处理开源。其答案很可能是1。


人的挑战


我们不断从别人那里学到东西!人们非常伟大。

产品 vs 项目

微软在发布产品和服务方面非常干脆:微软安全开发周期(SDL, Microsoft Security Development Lifecycle)帮助团队考虑安全,以及如何构建及发布软件。

作为一个公司,我们的产品也在代码签名、包装、本地化、全球化、服务和可访问性方面有各种要求。

发布开源项目(代码仓库)的要求没有那么多,但团队依然需要做正确的事情。

我们在发布开源代码方面的政策更多的是关于业务目的和审核方面,确保代码仓库的管理信息和LICENSE文件、README文件存在,以及团队可以支持、构建并发展友好的开放式社区。

不过,有时候团队会认为,即使发布开源代码仓库,也需要满足全部要求(比如本地化)才能发布产品。

吸取以上的教训,我们以后会向团队强调项目不等于产品,但通常它们会互为补充,有时候二者也代表同一个东西。

产品和服务与开源代码有很大区别。你可以告诉你的朋友这一点。

分叉指南

在开源世界中,分叉是一件大事。有时候,分叉是社区前进的正确选择,但有时候一些团队会认为分叉是他们为上游做贡献的方式。

例如,如果有人想为CLA助手做贡献 ,一种方式就是分叉至他的个人GitHub账号,然后向上游项目提交一个拉取请求。另一种方式就是在微软官方组织中建立一个项目的分叉,然后提交拉取请求。

尽管第二种方式表示这个项目的贡献来自微软,但这种方式会造成混乱,因为微软只想参与上游项目而不想以任何形式创建分叉。

我们强烈建议团队按照GitHub的方式,在个人账号中创建分叉并提交拉取请求,而不是在官方组织账号上。

我们希望各个团队尽可能为上游项目做贡献,仅把分叉当做最后的解决方案。

分叉是一件大事。上游项目才是贡献的正确目的地。

支持群发(邮件)

微软官方GitHub组织的电子邮件地址为opensource at microsoft,因此我们收到了许多人的邮件,寻求关于问题和产品的帮助。

在GitHub上,如果你在浏览代码仓库时点击页面底部的“联系GitHub”,它会问你是要提交GitHub本身的问题,还是要提交代码仓库的问题。这样可以减少GitHub收到的问题或支持请求。

然后,GitHub会提供代码仓库中SUPPORT文件给出的电子邮件地址,或者直接提供组织默认的电子邮件地址……所以我们收到了许多电子邮件。

我们已经尝试改进垃圾邮件过滤器,并使用模板来回答这些问题,但依然会受到许多邮件。

以后我们需要解决这个问题。

人们希望我们提供更多开源!

作为娱乐,许多长期拥护微软软件的人会经常写信要求我们开源他们喜欢的项目,如……

  • 飞行模拟器

  • Microsoft Money

  • 帝国时代

  • 我们的操作系统

很高兴看到人们希望这些产品开源,但我想许多人可能没有意识到,商业软件通常依赖于许多非开源授权的组件,或者代码需要非常特殊的构建环境,等等。

我很乐意看到分享历史代码,比如原始的winfile.exe,或者古老的MS-DOS 1.25和2.0!希望微软团队能找到合适的时间来分享这些代码。历史软件发布的现实在于,很难建立活跃的协作社区,除非能有清晰的机制来构建并发布现代的软件。

开源一切。


激动人心的GitHub新功能


在题目为“使用GitHub企业版像开源社区一样构建软件”(https://github.blog/2019-05-23-build-like-an-open-source-community-with-github-enterprise/)的文章中,GitHub的Mario Rodriguez指出,有些让GitHub在开源方面取得成功的功能,对于所有组织都有帮助性。

我们开始将更多开源组织移动到GitHub企业云上,我很想看看我们的工程团队如何利用这些新功能。

我们使用的新功能包括:

组织洞察

该功能在企业云账号中还处于Beta版。你可以通过该功能,看到整个组织的所有代码仓库中的高层趋势,比如新问题、关闭的问题,以及其他关键的数据。

640?wx_fmt=png

另一个很好的视图是“成员的时间消耗”,可以统计每个人为组织做出贡献的时间消耗在了哪里。

640?wx_fmt=png

维护者角色

对于像.NET这类拥有大量活动和维护者的团队来说,GitHub上除了历来“读/写/管理”之外的新角色意味着他们可以指定Triage用户(该用户可以管理问题和PR,但不能直接推送代码)或维护用户(问题与PR管理之上的附加设置)。

640?wx_fmt=png

代码转移问题

以前在仓库之间移动代码的问题需要借助第三方、非官方或随机的工具完成,如今GitHub支持代码的转移,我们很高兴看到这个额外的选项对面临跨多个代码仓库问题的社区开放。

审核日志

目前,GitHub为企业云客户提供了测试版的审核日志API。我们可以通过GraphQL,在我们的系统中保留审计日志副本以供审查和分析,而无需像现在这样通过手动或繁琐的方法获取和存储追加数据存储中的webhook信息,和/ 或解析GitHub组织审核日志的JSON和CSV。


期待


我们还有很多工作要做,随着微软继续开源冒险之旅,我们旅程也会越来越有趣。开源计划办公室还要考虑很多事项,包括……

作为一家公司,我们会将继续努力发展开源组织的“成熟模型”,让我们拭目以待未来的发展。

分享指导和指南

如同当初GitHub创建的//opensource.guide上的开源指南一样,我们很乐意分享,并帮助业内其他人了解我们的进展。

关于如何看待开源,制定与开源相关的业务决策,这些都是我们喜欢分享与讨论的有趣话题。

我们可以与全世界分享我们的文档或其中的一个版本。这里要感谢谷歌已经在其网站上分享了他们的开源指南和政策。

寻找贡献的机会

我们在努力寻找让每个人都做贡献的机会,例如在我们的版本中突出强调现有的问题,而且也在努力发现我们的员工何时为微软控制之外的公开项目做出了贡献。

我们希望通过更新opensource.microsoft.com网站,讲述我们的故事,并分享有关我们团队的最新信息。

作为一项短期实验,我们在开源网站的主页上列出了“公开投标”的问题,目的是了解人们是否觉得有趣。

640?wx_fmt=png


开源资源


下面是本文中提到的开源资源的GitHub代码库:

  • cla-assistant/cla-assistant:https://github.com/cla-assistant/cla-assistant

  • amzn/oss-attribution-builder:https://github.com/amzn/oss-attribution-builder

  • clearlydefined/crawler:https://github.com/clearlydefined/crawler

  • todogroup/repolinter:https://github.com/todogroup/repolinter

  • clearlydefined/curated-data:https://github.com/clearlydefined/curated-data

  • microsoft/opensource-portal:https://github.com/Microsoft/opensource-portal

  • microsoft/ghcrawler:https://github.com/microsoft/ghcrawler

  • fossology/fossology:https://github.com/fossology/fossology

  • nexB/scancode-toolkit:https://github.com/nexB/scancode-toolkit

  • licensee/licensee:https://github.com/licensee/licensee

  • octokit/rest.js:https://github.com/octokit/rest.js

(0)

本文由 投稿者 创作,文章地址:https://blog.isoyu.com/archives/cong-2000-dao-25000-gongchengshiweiruankaiyuanruhezhiba-github.html
采用知识共享署名4.0 国际许可协议进行许可。除注明转载/出处外,均为本站原创或翻译,转载前请务必署名。最后编辑时间为:7月 12, 2019 at 05:29 下午

热评文章

发表回复

[必填]

我是人?

提交后请等待三秒以免造成未提交成功和重复