开源助力 .NET 走向更广阔的舞台

发表时间: 2021-08-03 18:13

【编者按】从闭源走向开源,.NET 背后都发生了哪些有趣的故事。本文采访了 6 位微软 .NET 团队成员,分享他们在 GitHub 以及建立 .NET 开源项目的经历。


作者 | Richard Lander
译者 | 弯月
出品 | CSDN(ID:CSDNnews)

当第一次考虑在 GitHub 上共享 .NET Core 时,我们觉得开源是一个富有吸引力且令人兴奋的想法。同时,我们很多人都不太了解 GitHub,只知道这是一个很大的平台,至于如何利用这个平台,我们都有很多疑问。“如果第一天就有人在我们的运行时上建立分叉,该怎么办?是不是说我们的项目就完了?”我们知道应该虚心学习开发人员建立的模式,并了解他们对我们的期望。话虽如此,我们还是建立了项目和组织,而且项目的发展速度超出了我们的预期。截止到目前,我们已经度过了数个春秋,而且已经拥有了多个版本,而其他的都已成为历史。这是一段有趣的旅程,我们将与各方工作人员一起分享。

此次,我们将通过谈话的形式,与以下几位 .NET 工程师一起分享他们尝试 GitHub 以及建立 .NET 开源项目的经历。

  • Claire Novotny:.NET 基金会执行董事, .NET 团队的 PM

  • Dan Moseley:.NET 库团队的项目经理

  • Immo Landswerth:.NET 团队的项目经理

  • Kevin Pilch:ASP.NET Core、Entity Framework 和 Winforms 的工程经理

  • Matt Mitchell:.NET 工程师

  • Stephen Toub:.NET 工程师



Q:为什么开源对 .NET 项目如此重要?

Immo:现代开发技术栈需要跨平台。在操作系统和架构不断变化的大环境中,开源是最具可持续性的、构建一个拥有广泛支持的技术栈的方式。我们可以通过开源与消费者实时互动,而这从很多方面改变了我们计划、构建和迭代 .NET 的方式。最后,人们都希望开发技术栈这类的基础技术能够在开源许可下开放。

Claire:开源之后,任何人都可以查看和调试用于构建应用程序的运行时,甚至为之做贡献。以前有些问题对他们来说很重要,但不会被优先考虑,而如今他们可以自行解决这些难题了。开源之后, .NET 项目已不再由微软一家提供

Kevin:我认为开源对 .NET很重要,原因如下:

  • 开源语言和运行时的实现很常见,所以如果不开源的话,倒显得我们格格不入。

  • .NET 涉及的范围很广,尽管我们尽了最大的努力来编写文档,但还不如让人们来亲眼看一看这些实现,甚至动手调试。

  • 我们可以通过开源,与个人和其他公司展开合作,这种合作比在闭源系统上进行的一次性协议更直接。

Stephen:原因有很多,但最让我心动的是任何人都可以找到对他们很重要的东西,并加以改进。在 .NET Core 出现之前,任何改进请求都要与其他请求一起经过整理和分类后,才会到达合适的微软工作人员手中,然后再安排开发人员处理改进要求,可能需要经过几年的时间才能发布出来。如今,如果有人发现希望修复的问题,他们只需提出 PR,然后经过审查、迭代、合并,通过每晚的构建,第二天就可以上线了。这是一个完全不同的世界。

Dan:开源是实现跨平台的最佳方式,尤其在面向 Linux 时,开源是最自然的做法。

Matt:我认为,微软必须通过某种方式表现对开源软件社区的投入,这一点很重要。我们采用了开源软件的开发方式,并将开源作为产品的一部分发布出去。如今,开源软件是整个软件生态系统的重要组成部分。微软的参与和回馈也非常重要。

Dan:由于有更多的人关注我们的工作,因此可以帮助我们在产品发布之前确保产品的正确性。此外,社区的规模意味着其中有许多来自各个领域的专家,其规模远远超过了我们的工程团队,这也可以帮助我们更好地完成工作。



Q:.NET团队直接在 GitHub 上开展工作,是吗?早先有一些代码炸弹(JIT 和 GC)。现在没有了,是吗?

Immo:只有 StephenToub 长期休假就没问题。

Matt:我们几乎全部转移到了GitHub 上。安全补丁的确会先在代码库中构建,但等到代码发布的时候就会合并到开源库中。除此之外,我们的开发、讨论和议题跟踪几乎都在 GitHub 上

Stephen:如今代码炸弹已经很罕见了。有时,有一些额外的已有组件会被移动到 dotnet/* 代码库中,但是这种情况很少见。我能想到的过去一年中出现此类情况是一个名叫 System.Speech 的库。

Kevin:实际上,我认为我有最大的一个代码炸弹,因为向 roslyn 项目提交代码的第一个人是我(当初我们还没有使用机器人来完成此类工作)。如今我们的大部分工作都是直接在 GitHub 上进行的,而且你可以看到这个过程是逐步建立的。但也有可能我们决定发布一些新项目的代码,或者在我们决定是否开源之前先在原型上进行试验。

Dan:我们十分关心公开我们的工作,除了作为一种承诺之外,还能让更多人关注我们的工作。所以一般来说,开发重大的非公开项目有违于微软的惯例。



Q:分享一个有关 .NET Core 1.0 开源项目的故事

Kevin:在 .NET Core1.0 开发期间,我一直在研究 Roslyn,但让我们非常高兴的一件事是,当 Anders 宣布编译器发布到了 CodePlex 上之后,我们与运维人员一起观看服务器上的负载增加状况。幸运的是,负载一直保持不变,但如果我没记错的话,那是他们迄今为止看到过的最高的负载。

Immo:我们创建了一个 .NET 专用账号(dotnet bot),而且这个账号还成了第一批代码的提交者。我们之所以这样做,是为了表明所有这些提交都是已有的代码,而不是由某个人编写的。可以想象,第一批提交包含大量的代码。时至今日,dotnet bot 收到了大量工作邀请函,因为有人透过 GitHub 的统计数据挖掘到了 dotnet bot。

Stephen:多年前,我在从伦敦起飞的飞机上编写了一个数独应用,用于生成游戏和玩游戏。这个应用成为了我尝试新平台的媒介,最初是在 Windows Forms 上编写的。后来,我把它移植到了 WPF。后来在研究并行计算时,我利用这个应用来演示并行计算。等到 Windows 8 发布以后,我将其移植到了 WinRT。后来,我们发布了平板设备,我又一次将其移植了上去。而等到我们在 Linux 上启动 .NET Core 后,这个应用是除了“Hello, world”之外,在 .NET Core 上运行的第一批 Linux 应用之一(移植后的版本提供了文本界面)。

Matt:早先时候,我们的公共 CI 系统采用了 Jenkins。我们不知道应该使用哪种工具。我们采用了一个旧版的 Jenkins 单体版本,而且它的设计并不适合处理我们的规模(数以万计的作业,需要大量的编排)。好在一切还算顺利,但是很难管理稳定的安装版本。最终,我们不得不创建了一个又一个越来越大的虚拟机,而且占据的内存也越来越大(数百 GB),但我们仍然需要有人时刻监视,一旦系统崩溃,就按下重启键。

Dan:社区的参与度和专业知识总是让我感到惊喜。此次开源在很大程度上是一种合作伙伴关系,令人欣慰的是,如此之多的开发人员对 .NET 充满热情,他们贡献的功能和变更如此重要,可以让 .NET 变得越来越好。



Q:.NET开源项目最令人惊讶的是什么?

Immo:多年来我们一直在谈论开源。我非常惊讶的是我们的心态转变速度之快:前一天我们还在担心,结果没过几天就完全变了:“为什么还没完成”。整个团队的文化都发生了变化。从使用 TF VC 的内部 TFS 转变到使用 Git 的 GitHub,并公开开发工作,我们几乎只用了几周的时间。我很震惊,也很自豪能够成为一支适应速度如此之快、几乎没有任何犹豫的团队的一员。

Kevin:虽然在微软从事了七年的开源技术工作,.NET 开源的一切在我眼里都很正常,但我仍然对这份工作感到兴奋。如果回到 2002年,我很难想象这样的事情。

Matt:这个项目的发展速度总是让我感到惊讶,而且如今似乎还在不断加速。以前,我总是能够清楚地记住当前正在进行的一系列工作,各个代码库的状况以及它们之间的关系。然而在过去的一年里,我经常会恍惚:“等等,我们现在就要做吗?”但话说回来,可能只是因为我上了年纪。

Dan:自从 .NET 开源以来,内部团队已经联系了我们很多次,希望我们能够帮助和指导开源他们的项目。而他们又会成为微软其他团队的榜样。令我惊讶的是,人们对我们公开自己的工作非常感兴趣,他们希望能够从我们身上汲取经验。

Immo:我没有预料到的一件事是,在与合作伙伴团队的内部互动中,开源竟然起到了如此大的作用。回想起来,这也不是很意外。微软是一家大公司,拥有各种各样的工程系统、发布周期和业务目标。我们希望团队之外的人员也能够接触我们的代码库,包括微软的不同团队,而在开源的帮助下,这个问题非常容易解决。



Q:.NET开源项目似乎非常受欢迎,而且非常活跃。你觉得是什么原因?

Immo:.NET 以高效著称,尤其是与 C# 结合使用。在开源之前,我听很多人说,有些人坚持认为“微软非常邪恶”,虽然 C# 非常棒,但他们仍然拒绝使用 C#,因为它是闭源的,并且只支持 Windows。开源之后,很多人终于有机会在项目中使用了 C#了,即便他们的工作根本不涉及 Windows。

Kevin:我认为这在一定程度上表明 .NET 已深入客户的日常工作。他们每天都会用到. NET,因此能够让工程师和客户直接接触我们的项目是非常有价值的。团队中还有很多人在思考如何与社区展开合作,以及如何让我们的开源软件更具包容性,更容易接纳别人。在这个问题上,我们都要感谢 Dan 付出的努力。

Matt:多年以来,.NET 的“核心”已得到巩固。如今,我们有机会进一步扩展,并尝试新事物和创新。与早些年相比,我们的工程系统越来越好,而我们的发展速度也越来越快。

Stephen:C# 是一门非常容易上手且发展成熟的语言,.NET 的库非常健壮且庞大,运行时坚如磐石。你可以编写非常高效且可扩展的应用和服务,而且编写这种代码的效率非常高

Claire:在我看来,C#、.NET 和 Visual Studio 一直都是值得信赖的平台。我可以快速投入工作,快速地编写代码,然后开始调试,而无需考虑类路径等复杂的配置,或手动指定垃圾收集器的设置。

Dan:.NET 开发人员的群体非常庞大,而且由于大多数 .NET 平台是用 C# 编写的,因此向这个项目做贡献相对比较容易,而且很容易出成果。通过开源,我们与所有开发人员建立了联系,而不仅仅是 Windows 开发人员,无论你使用何种平台,都可以考虑 .NET。



Q:在你看来,人们对这个项目满意吗?开源是明智之举吗?

Immo:根据我与 .NET 开源社区其他成员的交谈,感觉我们做了许多正确的事情。特别是在刚开始的时候,我们告诉所有人,我们可能会犯错,我们非常期待诚恳的反馈。我认为,这件事奠定了社区参与的基调。尽管如此,我们也明白,取得开源的成功并不是目标,而是过程。还有许多东西值得我们从其他社区学习。

Dan:从 GitHub 社区的调查问卷中我们了解到,大多数情况下人们都很高兴。不同的代码库的结果也不一样,也有许多我们需要改进的地方,我们应当更积极、更加透明地响应,降低贡献代码的难度。我们可以学习一些成功的开源项目。我们已取得了进步,但前面还有很长的路要走。

Matt:我认为核心开发人员对 .NET 开源项目基本满意。至少,我没有看到任何开源的反对意见。从 .NET 组织的文化来看,这种情况非常自然,也是我们的目标。现在的反对意见主要集中在如何提高各个部分的工作效率。怎样才能更好地管理议题?PR 的测试标准是什么?

Kevin:我认为我们一直在尝试改进。总会有人因为他们的问题没有得到解决而不满,但目前来看,在我们的代码库中进行构建、调试并运行测试并非易事。有时候,就问题能否解决、何时解决,我们并没有管理好人们的期望。因此,我认为我们做得还不错,但依然有可以改进的地方。

Dan:举一些我们让 .NET 变得更加包容的例子:我们在Github上公开了 .NET 6 的计划,并在Github 上管理该计划;我们还积极利用 dotnet/designs 代码库,这样社区就可以帮忙分享和改进我们的设计和计划。



Q:项目的维护人员经常讨论超负荷的问题,他们都是在业余时间维护开源项目。但 .NET 开源项目是你们的本职工作,所以你们的感受可能不一样。你们经历的最大难题是什么?

Dan:由于代码库一直都非常活跃,我们不得不放弃事必躬亲的想法,也不能逼迫自己在业余时间随时做出响应。相反,对于喜欢灵活工作的人,这种情况反而很好,例如,无论何时都会有人执行代码审查。

Kevin:对于我来说,关注一切会让人感觉不堪重负。我管理的几个代码库每个月都有几百甚至几千个议题,更不用说 PR 和评论了。就算是全职工作,给予一切方面应有的关注,时间也远远不够。我看到有人通过延长自己的工作时间来解决这个问题,但最终还是会面临精力耗尽的局面。

Stephen:我的时间根本不够,无法完成所有的工作。例如,我很希望能审查 dotnet/runtime 中的大部分PR,但量太大,最后我只能优先处理一部分。

Matt:挑战之一就是避免让自己成为救火队员。由于 .NET 的发展速度非常快,光是回复 PR 审查请求、帮助受阻的开发人员或修改基础设施的错误,就占据了我所有的时间。困难就在于专心解决根本问题,并从战略层面上思考怎样解决一类问题,而不是一整天都为个人服务

Dan:团队中有许多人非常善于保持工作的边界。我们认为这样完全没问题,甚至可以说这是最理想的做法。

提交者人数是固定的,但潜在的贡献者是无限的。因此,我们不可能关注所有的议题和 PR 审查。我们会尽可能关注一切,但同时也会尝试找出一个正确的模型来管理这项工作。我们希望社区能帮我们解决这个问题。

Claire:由于项目是全球性的,贡献者也来自五湖四海,因此新的议题永无止境。工作之外的时间里,我会想尽各种“请勿打扰”的方法,来保持工作和生活的平衡



Q:很显然,该项目的开源已经远远超出了授权的范围,其中社区的因素更多。团队为了提高社区参与度做了哪些努力?

Clarie:我们一直在努力确保团队与社区的友好交流,让每个人都能参与进来。

Dan:有很多例子。我们主导了“社区分类”行动,好几个代码库都由社区成员负责给议题添加标签,或者关闭重复的议题。在代码方面,有时我们会让社区贡献者参加我们的每日会议。去年我们在网络性能问题上也尝试过同样的实践,而且非常成功。只要有可能,只要社区成员愿意实现某个功能,我们非常愿意放手。例如,Web 套接字压缩和 PriorityQueue 就是这样实现的。

Kevin:Dan 等人的调查已经持续了一段时间,我们在尝试从调查中汲取经验。如上所述,我们在努力给议题的状态设置更为清晰的期望,方便大家访问代码库,降低构建的难度,确保社区PR得到更快的审查,等等。

Immo:以前,我们曾尝试过“代码开放”,就是将代码扔给开源社区,而我们躲在门后继续制造代码炸弹。从 .NET Core1.0 开始,我们的工作全部转移到了 GitHub 上。这样人们就可以看到团队的代码审查,也能看到问题的跟踪。我们中的许多人都加入了社交网络,更积极地宣传 .NET 和我们的 GitHub 项目。我们还在 YouTube 上直播了设计讨论会议。现在我们有好几个网站可以与社区分享更多信息,比如issuesof.net、apisof.net、apireview.net和 themesof.net 等。

Matt:在基础设施方面,我们的理念一直是为微软之外的 .NET 贡献者提供与微软开发人员相同的工具和流程,以及同样的 PR 检查工具,并公开检查结果,同样的编程工具,等等。

Dan:补充一句,这样做也为团队中不在办公室办公的成员提供了方便,他们不需要VPN就能工作。



Q:想象一下,你决定跳槽到一个新项目(或工作)。开源会成为你的选择标准之一吗?在你看来,开源有多重要?

Stephen:这个想法太悲观了,我为什么要跳槽?但是,没错,开源非常重要。

Dan:纵观整个职业生涯,我一直在从事闭源项目,直到遇到 .NET。如今的我无法想象在一个非开源或注定会开源的项目上工作。开源的工作更有意思,我们能获得更多的能量,接触到更多的观点,而且还可以认识更多人。而且开源非常高效

Claire:能够参加开源项目,并为开源做出贡献,对我来说非常重要。能够与社区互动、获取新想法的反馈,并公开迭代过程,这一点至关重要

Immo:作为项目经理,我非常重视与客户实时互动的能力,包括让他们直接接触工程团队的工作成果。我很难接受失去这一切。即便将来离开微软也没有关系,因为所有的工作都公开了。

Kevin:我从事开源项目已经七年多了,我从大学开始就想从事开源项目。我很难想象自己加入一个非开源团队。

Matt:我认为,对我来说开源并不是一个硬性要求。但是某些开源的“思维方式”很重要。例如透明度、多样性、完整性、社区、公共标准和辩论,还有开源工具,这些对我来说都很重要。



Q:.NET 的采用率会不会因为开源而增加?

Claire:毋庸置疑。在开源之前,.NET 仅限于 Windows。如今 .NET 开源了,可以在更多地方运行了。

Immo:我相信答案是肯定的,但我认为跨平台支持(包括设备)给 .NET Core 带来了很多变化。很难说这些成功的主要因素是什么,但我认为开源软件是我们成功构建 .NET 的关键

Dan:在开源的帮助下,我们更容易地实现了跨平台,因为我们可以与 Linux 的社区合作。而支持 Linux(以及 Mac)让我们成为了 Linux 开发人员的备选之一。当然,也有一些开发人员单纯因为喜欢开源技术栈。此外,开源还让人们更容易信赖 .NET,因为每个人都可以阅读源代码。

Matt:我觉得应该会。我认为,我们很难将 .NET的采用率与开源直接联系起来,但我认为在某些方面开源增加了项目的可见性,而且还让.NET 在原本不可能的地方(例如红帽)得到了应用。



Q:纵观历史,微软提供的产品主要以闭源为主。长期使用 .NET 的微软客户是否愿意接纳开源?

Kevin:肯定有一些客户不太愿意。在我看来,这个问题主要在于支持。虽然大多数人都知道,微软发布的产品都提供支持,比如 gRPC-dotnet,虽然绝大多数代码是微软编写的,但是实际上该项目由 CNCF 负责,也由他们负责发布。那么,我们提供支持吗?(答案是这个问题刚刚得到了解决,我们提供支持)。但是我们推荐或贡献了代码的第三方库也经常出现这个问题。

Dan:以前许多 .NET 客户构建应用都会使用微软提供的库(以前都是闭源代码),再结合自己编写的代码,他们不太习惯依赖微软之外的库,而这些库通常是开源的。我们希望让他们明白,他们也可以信任来自 .NET 团队之外的库,而开源更容易让他们信任这些库。

Matt:至少在内部,经常有人不太了解开源项目的开发方式,开源项目之间的关系以及开源项目如何才能满足需求(服务、新功能等)。有时,他们有点不太习惯 .NET 之类的微软传统项目中包含微软以外的开发人员编写的代码。但我认为这主要是因为.NET 的发展历史,而不是他们真的不喜欢开源。



Q:介绍一下微软对开源的承诺

Immo:我觉得打从第一天起,我们对此就非常透明。微软整个公司都在向云迁移。许多微软的客户都在使用 .NET,我们认为 .NET 与云计算的结合至关重要。而且我们相信开源是 .NET 向云转变的最佳方式。

Dan:为了回答这个问题,我们可以看一看近年来发生的事情。微软维护的开源项目数量持续增长,包括几个顶流的 Github 代码库。这些都是最有力的证据。



Q:.NET项目 与 .NET 基金会有什么关系?

Claire:人们经常将 .NET 项目与 .NET 基金会混为一谈。该项目的知识产权归 .NET 基金会所有,但 .NET 基金会没有项目控制权。.NET 项目的控制权在微软手中。作为 .NET 基金会的执行董事和 .NET 团队的项目经理,我同时担任两项职务,我清楚什么场合下应该承担起哪项职务。我认为,刚开始的时候 .NET 项目和 .NET 基金会之间的界限很模糊,在过去的几年里,我们一直在努力更清晰地区分二者。


结束语


在 GitHub 上公开办公,彻底改变了团队和产品。虽然我们从事 .NET 的开发已经很多年了,但项目和产品本身仍在不断增长。这是一个振奋人心且令人满意的结果。很明显,开源是开发应用程序平台的最佳方式,而且也更有趣。感谢所有为该项目做出贡献的人。

感谢Stephen、Matt、Kevin、Immo、Dan 和 Claire 与我们分享 .NET 开源项目的情况,以及参与其中的感受。

原文链接:
https://devblogs.microsoft.com/dotnet/conversation-about-the-net-open-source-project/

声明:本文由CSDN翻译,转载请注明来源。