Today is a huge day for .NET! We’re happy to announce that .NET Core will be open source, including the runtime as well as the framework libraries.

This is a natural progression of our open source efforts, which already covers the managed compilers (C#, VB, and F#) as well as ASP.NET:

• C# & Visual Basic (“Roslyn”)
• Visual F# Tools
• ASP.NET 5
• Entity Framework

This takes it to the next level by extending it to the .NET runtime and the core framework.

• .NET Core Framework

What is .NET Core?

.NET Core is a modular development stack that is the foundation of all future .NET platforms It’s already used by ASP.NET 5 and .NET Native. I’ll go into more detail on what NET Core is and how it relates to the NET Framework in a following blog post.

Why do we open source .NET Core?

There are two big reasons why we decided to open source .NET Core:

1. Lay the foundation for a cross platform .NET
2. Build and leverage a stronger ecosystem

Let me go into more detail.

Lay the foundation for a cross platform .NET

As a .NET developer you were able to build & run code on more than just Windows for a while now, including Linux, MacOS, iOs and Android.

The challenge is that the Windows implementation has one code base while Mono has a completely separate code base. The Mono community was essentially forced to re-implement .NET because no open source implementation was available. Sure, the source code was available since Rotor but we didn’t use an OSI approved open source license, which made Rotor a non-starter. Customers have reported various mismatches, which are hard to fix because neither side can look at the code of the other side. This also results in a lot of duplicated work in areas that aren’t actually platform specific. A recent example is immutable collections.

The best way to build a cross-platform stack is to build a single stack, in a collaborative manner. And the best way to do exactly that is by open sourcing it.

Build and leverage a stronger ecosystem

My team has pursued a more agile development cycle via NuGet for almost two years now. We’ve seen great success with releasing early and often in order to allow customers to provide feedback.

And if you think about it: open source is essentially the ultimate agile development style. Every change is immediately public and (in theory) consumable. Many members on my team are on Twitter and Stack Overflow and engage in customer discussions. There was more than one occasion where I wish I would have been able to point a customer to an internal document that explains how our system is implemented. Or simply point to a commit that shows how an issue was fixed.

To us, open sourcing the stack also means we’re able to engage with customers in real time. Of course, not every customer wants interact with us that closely. But the ones who do make the stack better for all of us because they provide us with early & steady feedback.

I think of it as driving a car: frequent small adjustments of the steering wheel are more efficient than a few drastic changes – and also less risky.

Our choice of using GitHub

We decided to host .NET Core on GitHub because according to Phil Haack, publishing code on GitHub will improve the performance:

So @ahejlsberg tweets TypeScript 5x faster compiler is on GitHub. I suspect causation. GitHub makes your code 5x faster. Anders says so.

— Boom Haackalacka (@haacked) August 1, 2014

Just kidding.

As a principle, we don’t want to ask the community to come to where we are. Instead, we want to go where the community already is. Based on feedback that many other projects have received it seems the majority of the .NET community is on GitHub.

Don’t believe it? I was skeptical as well so I conducted a little experiment. I moved one of my personal open source projects from CodePlex to GitHub. During the two years it was on CodePlex I’ve only received a single pull request. Five days after I moved to GitHub I already received three pull requests and found two other contributors. This was three months ago. In total, I’ve received 16 pull requests since then, many of them with substantial feature work. (By the way: one of the first ones was around adding unit testing, how awesome is that?). While this is obviously not a representative sample size, it does very much echo what we heard from our customers.

So in order to be where the community is, we decided to host .NET Core on GitHub. A month ago, we already made our samples available on GitHub.

Development in the open

My team has done open source before, for example MEF, but I think it’s fair to say that this wasn’t exactly fruitful. We think the primary reason for this is the lack of community engagement. While we made the source available, we haven’t invested into building a community around it. We strongly believe that building a community is key for the success of any open source project. And in order to build a community it’s critical that the development happens in the open.

To live up to the expectations we also want to be transparent in how we plan on doing development in the open, what challenges we have to overcome, and which areas aren’t completely solved yet. So let me explain this.

The first step is that we’ll stop doing code bombs, which is what we did previously with MEF. Code bombs are essentially semi regular updates of the public source code from the internal system the team is actually working on. That’s problematic for a couple of reasons. For one thing, the time delay makes it hard to have a public discussion because not all parties see the same source. Another big problem is that the internal history is just lost. Automated syncing helps up to a point but it feels like reinventing Git.

So instead of code bombs, we’ve setup our development environment so that the public GitHub repository is the leading system. This means that all code changes are immediately live. But we don’t stop there:

• Code reviews. We also want to have all code reviews the team is doing to be in the public as well, via GitHub’s pull request model.

• Design documents & discussions. We’ll also share design notes, specs, and implementation specific documentation. We’ll need to figure out exactly what format we’ll be using. At a minimum you can expect Markdown based documents, similar to Mad’s C# design notes. Another idea we had was recording our design meetings and share them on Channel 9. We need to figure out how we can do this on a somewhat regular cadence.

We plan on primarily using GitHub issues for bug tracking. The tricky part is that we also have other sources, specifically User Voice, Connect and our internal TFS. The way we see this work is as follows:

• User Voice. Due to the excellent voting system User Voice is great for prioritizing investments in potentially fairly expensive work items. Thus, for larger features and fundamental innovations User Voice is the best choice.

• Connect. Connect is primarily used by enterprise customers and product support. We’ll most likely continue using it for that channel but wouldn’t recommend it otherwise when filing bugs for .NET Core.

• Internal TFS. While we no longer use TF Version Control for .NET Core, large chunks of DevDiv still do. In order to have cross-group collaboration work, we’ll probably continue allowing teams to file bugs against us in TFS. We’re working on figuring out how we can make those bugs public. One option is to create an automatic mirroring system.

For both User Voice and Connect you can expect seeing a workflow where team members will close User Voice / Connect issues after filing a corresponding GitHub issue.

We accept contributions

Yes, we do accept contributions! But as it is for any open source project, we don’t just blindly accept everything. The pull requests we receive will be judged by the following criteria:

• Roadmap. All projects focus their energy on certain areas. In order to keep the focus and the momentum it’s important that most of the work is aligned with the product’s roadmap.

• Quality. We’ve a responsibility for shipping high quality code. Therefore, external folks have to meet the same quality bar that Microsoft employees have to meet. This includes having the right design, architecture, sufficient test coverage and following the coding style.

We believe by doing the development in the open we provide enough context for external developers to be successful. For example, you’ll be able to observe our code reviews and read documentation about how the internals are designed. We’ll also publish a roadmap.

It’s usually best to avoid late surprises by letting us know early what you’d like to contribute. For example, we can help by providing you with pointers to documentation or by discussing your approach. We also had the idea of marking GitHub issues as up-for-grabs to advertise that we’d like your help on specific work items.

In general, all contributions will be done using GitHub’s pull request model. That is, you’ll fork our project, perform the work in a topic branch and then submit a pull request against our master branch. That’s the same model that we use for code reviews.

Before we can incorporate your work into the project, you’ll need to sign a Contributor License Agreement (CLA). We are currently working on the tooling, but it will probably look similar to the Azure CLA process.

Building and running your own forks

In order to play with our bits or experiment with your own modifications you need to be able to build and run your own version of the libraries. We want to make this as easy as pie, so here it is:

• You clone our repo (git clone https://github.com/dotnet/corefx)
• You invoke build.cmd

The build only requires Visual Studio 2013 (i.e. it doesn’t require “Dev14”). It will build all the libraries and run the unit tests.

One of the challenges we had in the past was around strong naming which prevented you from simply dropping a binary into an existing project. We’ve addressed this concern by providing a new way to strong name binaries, which we call open source signing. You can find more information in our developer’s guide.

.NET Foundation

The .NET Core project is under the stewardship of the .NET Foundation. We believe that to be a critical part in promoting and advancing the .NET Core stack. We’re closely working with Miguel de Icaza from Xamarin/Mono in order to create a shared code base that can become a cross-platform implementation of .NET Core.

Today, only a subset of the libraries are available on GitHub:

• Immutable Collections
• SIMD
• Assembly Metadata Reader
• XDocument
• XmlDocument

These are areas we’re working on:

• More libraries. Consider the subset we have today a down-payment on what is to come. Our goal is to open source the entire .NET Core library stack by Build 2015.

• Building and running on non-Windows platforms. We currently only provide the ability to build and run on Windows. We intend to build a public working group between us and the Mono community once we have enough code out there.

• .NET Core Runtime (CoreCLR). We’re currently figuring out the plan for open sourcing the runtime. Stay tuned!

Summary

The new .NET Core stack will be entirely open sourced on GitHub. We already made the necessary engineering changes for some of the libraries and included them in the core framework repository. Between now and Build 2015 you can watch us as we’re making progress. Pull requests are also welcome!

Please use the forum on .NET Foundation to let us know us know what you think!