.NET基金会讨论 .NET 开源事业之路

Posted 2021-11-05 dotNET跨平台

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了.NET基金会讨论 .NET 开源事业之路相关的知识，希望对你有一定的参考价值。

【编者按】从闭源走向开源，.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 基金会之间的界限很模糊，在过去的几年里，我们一直在努力更清晰地区分二者。