.Net 核心是一个模块化的开发栈。该开发栈包含 .Net 平台的所有特性。这些特性已经被用在 ASPNET Core 5 和 NET Native。下面会详细介绍什么是 .Net 核心以及它和 NET Framework 的关系。
为跨平台 .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 仓库，它是一个领先的系统。这意味着所有的代码修改会立即表现出来。但我们不会：
我们初步计划使用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请求都会按照下面的标准进行评判：
我们相信通过为外部开发者提供足够的环境，在开源界的开发将会成功。例如，你可以看到我们的代码审查并且阅读内部是如何设计的相关文档。我们将会公布路线图。
贡献者最好提早与我们沟通你的想法。这样的话，我们就可以给你提供一些帮助，比如提供文档或者是针对你的方案进行讨论。我们也会把我们希望大家做的工作发布在GitHub的issues列表上，供大家进行选择。
通常，所有的社区贡献都要通过GitHub的 pull request 模型来完成，也就是说，你首先要fork我们的项目，并在你的分支上进行开发，最后通过pull request将代码提交到主干上。 对代码检视也同样是使用这一模型。
在我们合入你的贡献之前，你还需要签署一份 Contributor License Agreement (CLA)协定。我们目前正在把这个工作工具化，最后的效果可能和Azure CLA过程类似。
构造并运行你自己的分支
要玩玩我们的程序或实验你自己做的更改，你需要构建并运行你自己的库版本。我们想要做的尽可能的简单，所以看这里：
只需要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基金会的论坛，让我们知道你们所想！
