Why does Microsoft choose to open up the. NET core on Github?

This article comes from an announcement from Microsoft Open source. NET, which explains why Microsoft has chosen to open source. NET at Github and the evolution of Microsoft's understanding of open source and open source communities.

For. NET, today (2014/11/12) is a big day! We are pleased to announce that. NET core will be open source, including the runtime environment and the Framework class library.

This is the natural result of our efforts to open source, we have open source for major compilers (C#,VB, F #), and ASP. NET:

• C # and VB ("Roslyn")

• Visual F # Tool Set

• ASP. 5

• Entity Framework

We do this by extending the scope to. NET runtime environment and core framework to move (Microsoft Open Source process) to the next stage.

• . NET Core Framework

What is. Net core?

The. Net core is a modular development stack. The development stack contains all the features of the. Net platform. These features have been used in ASPNET Core 5 and NET Native. Here is a detailed description of what is. NET core and its relationship to the Net Framework.

Why do we want open source. Net core?

Our open source. Net Core has the following two reasons:

1. Laying the groundwork for cross-platform. Net

2. Build a strong ecosystem

Let's take a look at more details below.

Laying the groundwork for cross-platform. Net

As a. Net developer, you can later build or run your programs on Linux, MacOS, IOs, and Android, not just Windows.

The challenge is that Windows has a set of code implementations, and Mono has a set of code implementations. The Mono community was actually forced to re-implement the. Net once, because there is no open source code implementation. Of course the code implementation can be made available through Rotor. But without our open source authorization, it becomes impossible to do so. The customer has raised a lot of questions, but these problems are difficult to fix, because neither side can see each other's code. This also leads to a lot of repetitive work, and in fact the work is not targeted at platform-specific results. Immutable collections is a very obvious example.

The best way to build a platform-based technology stack is to create a unique technology stack in a collaborative way. At the same time the best way to cooperate is to open it up.

build and utilize a strong ecosystem

My team has been using NuGet (the next open source project of the. NET platform) to achieve a more agile development cycle for nearly two years. In order to provide feedback to our customers, we released it early, and now we have achieved great success.

If you think carefully you will find that open source is essentially an agile development model. Every change needs to be released immediately and (in theory) available. Many of my team members are Twitter and stack overflow members who are passionate about customer discussions. More than once, I wish I could introduce my customers to internal documents and explain to them how our systems are implemented. Or simply to explain how a problem is solved.

For us, the open source architecture also means that we can communicate with our customers in real time. Of course, not every customer wants us to have a close interaction. But there are people who make the architecture better because they provide early, stable feedback.

I compare this to driving a car: Frequent small adjustment of the steering wheel is more efficient and less risky than a large adjustment.

Choose to take advantage of GitHub

We decided to store the. Net core code on Github because, according to Phil Haack, publishing code on Githut can help improve the results:

This is of course a joke.

As a principle, we don't want to tell the community where we are. Instead, we should go to the community where it itself exists. According to some other project feedback, GitHub is the most important community of. Net.

Don't believe it? I was skeptical, so I did a little experiment. I moved one of my open source projects from CodePlex to GitHub. Two years on CodePlex, I had only one pull request, and five days after I moved to GitHub, I reached three and found two other contributors. It was three months ago, and since then I have received 16 pull request, many of which have made substantial progress. (By the way: the first one was put in a lot of unit tests, cool and wooden?) Although this is not strictly a case, it does allow us to hear more about the needs of our customers.

So in order to join the community, we decided to release the. NET Core on GitHub, and one months ago we saw our results on GitHub (we samples available on GitHub).

Development experience of Open source

My team is also open source, such as a MEF project, but to be fair, that doesn't make much of a gain. We believe that the basic reason is the lack of community involvement. When we only open the source code, there is no effort to build a community for it. I deeply feel that building a community is the key to the success of open source projects. The key to building a community is that the process of development should be open source as well.

To live up to expectations, we are also transparent about what our development plans are, what challenges we have to overcome, and what areas are not yet complete. Let me explain this.

The first step is to stop code bombs, just like the ones that were previously in the MEF. Code bombs are essentially irregular, publicly updated source code, which is the code that is being completed within the System project group. This is problematic for a variety of reasons. For example, the published time delay, it is difficult to see the same code, so it is difficult to open the discussion. Another big problem is that the historical version is missing, and auto-sync lets us sync the consistent code, but feels like reinventing Git.

So to prevent code bombs, we build our development environment in the public GitHub warehouse, which is a leading system. This means that all code modifications are immediately displayed. But we will not:

• Code reviews. We want all the code review process to be fully public, via GitHub's pull request model.

• Design documents and discussions, we also share design-time notes, specifications, and implementation documentation. We will certainly be clear about what format we will use. At least you can write down the basic document, just like Mad's C # design notes. Another idea is that we record our design seminars and then share them with Channel 9. We will certainly make it clear what rhythm we will go and how we can achieve it.

We initially plan to use the GitHub problem List feature to track bugs. It is ingenious that we also offer other avenues, such as the UserVoice forum, the Microsoft Connect website and our internal team collaboration Server (teams Foundation server). Their introduction is as follows:

• User Voice Forum. UserVoice has an excellent voting system for potentially expensive project rankings. Therefore, for greater features and fundamental innovation, UserVoice is the best choice for collecting feedback.

• Microsoft Connect website. the Connect site's primary users are enterprise users and product support personnel. We will likely continue to use this site for product support, but it is not recommended that you use (it to submit bugs) unless it is submitted. NET core bugs.

• Internal Team collaboration server. we no longer use the TF Version Control tool to manage the. NET core, but still manage large chunks of the DevDiv module. To enable cross-platform collaboration, we continue to allow teams to submit bugs through TFS. We are considering how to make those bugs public. One way is to create an automatic mirroring system.

On the UserVoice and connect website, when our team members submit a corresponding question on GitHub, you can see a process to close the problem on the uservoice/connect.

We accept contributions

Yes, we accept contributions! However, as with any open source project, we do not blindly accept all contributions. All pull requests we receive will be judged according to the following criteria:

• Road Map (roadmap). All projects are focused on certain areas. In order to maintain the focus and development momentum, it is important that most of the work is aligned with the project roadmap.

• Quality ( Quality ). We are responsible for delivering high-quality code. Therefore, external personnel must meet the same quality standards as Microsoft employees. Includes the right design, architecture, adequate test coverage, and adherence to coding styles.

We believe that development in the open source world will be successful by providing an adequate environment for external developers. For example, you can see our code review and read about how the internal design is related to the document. We will announce the road map.

Contributors are best to communicate your ideas to us early. In this way, we can provide you with some help, such as providing documentation or discussing your proposal. We will also post the work we want you to do on GitHub's issues list for everyone to choose from.

In general, all Community contributions are done through GitHub's pull request model, which means that you first fork our project, develop it on your branch, and finally commit the code to the trunk by pulling request. This model is also used for code view.

You will also need to sign a Contributor License agreement (CLA) Agreement before we can enter into your contribution. We are currently working on the tool, and the final effect may be similar to the azure CLA process.

Construct and run your own branch

To play our program or experiment with your own changes, you need to build and run your own library version. We want to do as simple as possible, so look here:

• Clone our repository (git clone Https://github.com/dotnet/corefx)

• Call Build.cmd

Only Visual Studio 2013 is needed to build (not "Dev14"). All repositories will be built and unit tests run.

One of the changes we made in the past is strong naming to prevent you from sloppy deleting binary files of saved items. By providing a new way to strongly name binary files We have solved this worry, we call the new method open source signature. You can find more information in our developer guide.

. NET Foundation

. NET core projects are managed by the. NET Foundation. He will become a push. NET core stack continues to be a key force forward. We'll also work closely with Miguel de Icaza of the Xamarin/mono project to create a shared code baseline that will evolve into a cross-platform implementation. NET core stack.

Today, only part of the code base can be asked on GitHub:

• Immutable collections

• Simd

• Assembly Metadata Reader

• XDocument

• XmlDocument

We will continue to exert ourselves in the following areas:

• more code Libraries . The current open source section can be understood as the first payment for the entire project. Our goal is to open source throughout the 2015. NET core stack.

• build and run on non-Windows platforms . We now only provide the ability to build and run on Windows. We are planning to work with the mono community to set up a public working group to do this.

• The . NET Core Runtime Environment (CoreCLR). We are developing an open source program for the runtime environment. Please stay tuned.

Summarize

. NET core stack will fully open the source code on GitHub. We have made some engineering changes that must be made to some of these libraries and included them in the core framework code warehouse. From now to build 2015 build, you'll see what we've done with open source. Welcome to download the source code!

Please use it a lot. NET Foundation Forum, let us know what you think!

Why does Microsoft choose to open up the. NET core on Github?