zoukankan      html  css  js  c++  java
  • 微软为何选择在 Github 上开源 .NET 核心?

    本文来自微软开源.NET 的一篇公告 ,文中阐述了微软为何选择在 Github 开源.NET,以及微软对开源和开源社区方面的认识的变迁。

    对于.NET来说,今天(2014/11/12)是个大日子! 我们很高兴宣布.NET核心将要开源,包括运行时环境和框架类库。

    这是我们为开源努力的自然结果,我们已经开源了主要的编译器(C#,VB、F#),还有ASP.NET:

    我们通过将范围扩展到.NET运行时环境和核心框架,使(微软开源进程)进入下一个阶段。

    什么是 .Net 核心?

    .Net 核心是一个模块化的开发栈。该开发栈包含 .Net 平台的所有特性。这些特性已经被用在 ASPNET Core 5 和 NET Native。下面会详细介绍什么是 .Net 核心以及它和 NET Framework 的关系。

    为什么我们要开源 .Net 核心?

    我们开源 .Net 核心有下面两个原因:

    1. 为跨平台的 .Net 奠定基础

    2. 建立一个强大的生态系统

    下面让我们来关注更多细节。 

    为跨平台 .Net 奠定基础

    作为一个 .Net 开发者,你以后可以在 Linux、 MacOS、 iOs 和 Android 上构建或者运行你的程序,而不仅仅是 Windows。

    这有一个挑战就是,windows已经有一套代码实现,同时 Mono 也有一套代码实现。Mono 社区事实上被强迫重新实现了一次 .Net,因为没有开源的代码实现。当然该代码实现可以通过 Rotor 来让变得可用。但是没有我们的开源授权,让这件事变得不可能。客户已经提出了很多的问题,但是这些问题很难去修复,因为双方都不可以看到对方的代码。这也导致了很多重复的工作,而且实际上这些工作不是针对特定于平台而导致的。immutable collections就是一个很明显的例子。

    建立一个扩平台的技术栈的最好方法,就是通过合作的方式去建立唯一的技术栈。同时最好的合作方式就是去把它开源。

    建立并利用一个强大的生态系统

    我的团队使用NuGet(.NET平台下一个开源项目)实现更敏捷的开发周期已近两年了。 为了让客户提供反馈,我们早期进行了发布,现在我们已取得了巨大的成功。

    如果你仔细思考会发现: 开源本质上是敏捷开发模式。 每一个改动都需要立刻发布,并且(在理论上)可用。 我团队里的很多成员是Twitter和Stack Overflow会员,他们热衷于客户讨论。 不止一次,我希望我能够给客户介绍内部文档,并向他们解释我们的系统是如何实现的。 或者只是简单地介绍一个问题是如何被解决的。

    对于我们来说,开源架构也意味着我们可以实时与客户进行交流。 当然,并不是每一个客户都想我们紧密互动。 但是确实有一些人使得架构变得更好,因为他们提供了早期、稳定的反馈。

    我把这比作驾驶一辆汽车: 频繁的小幅度的调整方向盘比大幅度的调整更有效,且风险更低。

    选择利用 GitHub

    我们决定在 Github 上存放 .Net 核心的代码,因为据 Phil Haack 说在 Githut 上发布代码,可以帮助提高效果:

    这当然是开玩笑。

    作为一个原则,我们不想告诉社区我们在哪里。相反,我们应该去到社区它本身就存在的地方。根据其他的一些项目反馈来看,Github是 .Net 的最主要社区。

    不相信?我原来也怀疑所以我做了个小实验。我将自己的一个开源项目从CodePlex上移到了GitHub上。在CodePlex上两年了我只有一个pull request,而移到GitHub上五天后我的pull request就达到了三个,而且发现了另外两个贡献者。这是三个月前了,总共从那时起我已经获得了16个pull request,许多都有实质性的进展。(顺便说一句:最开始的那一个被加进了很多单元测试,很酷有木有?)尽管这个还不算是严格意义上的案例,但确实能让我们听到更多客户的需求。

    所以为了加入社区,我们决定将 .NET Core 发布在GitHub上,一个月前,在GitHub上已经能看到我们的成果了(our samples available on GitHub)。

    开源的开发经历

    我的团队也开源过,比如MEF项目,但平心而论,那个并没取得多少收获。我们认为基本的原因是缺少社区的参与。当我们只开放了源码后,并没有努力为之建立一个社区。我深深感到,建立一个社区才是开源项目成功的关键所在。而建立一个社区的关键是开发的过程也要开源地进行。

    为不辜负期望,我们同样也会透明我们的开发计划是什么,我们要克服的有那些挑战,以及哪些范围还未完成。我来解释一下这些。

    第一步是要停止code bombs,就像之前MEF中投的那些一样。代码炸弹本质上是不定期的公开更新的源代码,它们是系统项目组内部正在完成的代码。由于各种原因,这样做是有问题的。举个例子,公布的时间延迟,大家很难看到同一份代码,这样就很难进行公开的讨论。另一个大问题是历史版本丢失,自动同步让我们同步一致代码,但感觉像reinventing Git.

    所以为防止代码炸弹,我们建立我们的开发环境在公开的GitHub 仓库,它是一个领先的系统。这意味着所有的代码修改会立即表现出来。但我们不会:

    • Code reviews.  我们希望所有的代码审查过程全公开,通过 GitHub’s pull request model.

    • 设计文档及讨论,我们同样共享设计时的备注、规格以及实现的文档。我们一定会讲清楚我们将用什么格式。至少让你可以记下基本文档,就像 Mad’s C# design notes的一样。另一个想法是,我们给我们的设计讨论会录音,然后共享到 Channel 9。我们一定会讲清楚,我们会以什么样的节奏去,怎么实现它。

    我们初步计划使用GitHub问题清单功能来跟踪bug。 巧妙的是我们也提供了其它途径,如 UserVoice论坛,微软Connect网站和我们内部的团队协作服务器(Team Foundation Server)。 它们的介绍如下:

    • User Voice论坛。 在潜在昂贵项目排名方面,UserVoice有优秀的投票系统。 因此,对于更大特性和根本创新,UserVoice是搜集反馈的最佳选择。

    • 微软Connect网站。 Connect网站主要用户是企业用户和产品支持人员。 我们将有可能继续使用这个网站用于产品支持,但是不推荐你使用(它来提交bug),除非是提交.NET核心的bug。

    • 内部团队协作服务器。 我们不再使用TF Version Control工具来管理.NET核心,但是仍然管理大块的DevDiv模块。 为了能够跨平台的协作工作,我们会继续允许团队通过TFS提交bug。 我们正在考虑如何公开那些bug。 一个方法是创建一个自动镜像系统。

    在UserVoice和Connect网站上,当我们的团队成员在GitHub上提交了相应的问题后,你可以看到一个关闭UserVoice/Connect上问题的流程。

    我们接受贡献

    是的,我们接受贡献!不过,与任何开源项目一样,我们不会盲目的接受所有的贡献。我们所收到的所有pull请求都会按照下面的标准进行评判:

    • 路线图(Roadmap)。所有项目都专注在某些领域。为了保持重心和发展势头,大部分工作向项目路线图看齐是很重要的。

    • 质量(Quality。我们要为输送高质量代码负责。因此,外部人员必须满足与微软员工相同的质量标准。包括正确的设计、架构、足够的测试覆盖率和遵守编码风格。

    我们相信通过为外部开发者提供足够的环境,在开源界的开发将会成功。例如,你可以看到我们的代码审查并且阅读内部是如何设计的相关文档。我们将会公布路线图。

    贡献者最好提早与我们沟通你的想法。这样的话,我们就可以给你提供一些帮助,比如提供文档或者是针对你的方案进行讨论。我们也会把我们希望大家做的工作发布在GitHub的issues列表上,供大家进行选择。

    通常,所有的社区贡献都要通过GitHub的 pull request 模型来完成,也就是说,你首先要fork我们的项目,并在你的分支上进行开发,最后通过pull request将代码提交到主干上。 对代码检视也同样是使用这一模型。

    在我们合入你的贡献之前,你还需要签署一份 Contributor License Agreement (CLA)协定。我们目前正在把这个工作工具化,最后的效果可能和Azure CLA过程类似。

    构造并运行你自己的分支

    要玩玩我们的程序或实验你自己做的更改,你需要构建并运行你自己的库版本。我们想要做的尽可能的简单,所以看这里:

    • 克隆我们得仓库(git clone https://github.com/dotnet/corefx)

    • 调用build.cmd

    只需要Visual Studio 2013用来构建(不用“Dev14”)。将会构建所有得库并运行单元测试。

    过去我们我们做的一个更改是强命名,以防止你草率的删除已存项目的二进制文件。通过提供强命名二进制文件的新方法我们已经解决了这个隐忧,我们把新方法叫做开源签名。你可以在我们的开发者指南中找到更多信息。

    .NET基金会

    .NET核心项目是由.NET基金会来进行管理。他将成为推动.NET核心栈不断向前的关键力量。我们还会与Xamarin/Mono项目的Miguel de Icaza进行紧密的合作,来创建一个共享的代码基线,使其发展为一个跨平台实现的.NET核心栈。

    今天,只有部分代码库可以在GitHub上访问到:

    我们会以下几个领域持续发力:

    • 更多的代码库. 目前开源的部分,可以理解为整个项目的首付款。我们的目标是在2015年开源整个.NET核心栈。

    • 构建和运行在非Windows平台. 我们现在只提供了在Windows上进行构建和运行的能力。我们正计划与Mono社区一起组件一个公开的工作组来完成此项工作。

    • .NET 核心运行时环境 (CoreCLR). 我们正在拟定运行时环境的开源计划。请保持关注。

    总结

    .NET核心栈将在GitHub上完全开放源代码。我们已经对其中的一些库做了一些必须要进行的工程性更改,并在核心框架代码仓库中包含了它们。从现在到生成2015 构建期间,你将看到我们在开放源代码方面所做的工作。欢迎下载源代码!

    请多多使用.NET基金会的论坛,让我们知道你们所想!

  • 相关阅读:
    PowerDesigner通过SQL文件,反向生成模型
    跨域请求设置
    SSO单点登录与登出
    jwt使用
    git概念理解
    Slf4j MDC机制
    ASP.NET Core依赖注入最佳实践,提示&技巧
    EFCore数据库迁移命令整理
    RSA加密的使用
    CocoaPods 安装的第三方删除
  • 原文地址:https://www.cnblogs.com/zjoch/p/5512585.html
Copyright © 2011-2022 走看看