CoreCLR and project Mono relationship after Microsoft open-sourced the .NET

Question

Could someone explain to me what is the current relationship between Mono and the open source/Linux portable .NET stack (CoreCLR, CoreFX, Roslyn, ASP.NET) recently made availabl

Answer 1

I think the answer may evolve over time but I understand Microsoft and the Mono Project will work together, or at least Microsoft will allow Mono to work with their open source .Net stack.

http://www.mono-project.com/docs/about-mono/releases/4.0.0/

While Microsoft is working towards .NET Core: a redistributable and re-imagined version of .NET, the project remains a work in progress. Mono at this point continues to provide an API that tracks the .NET desktop/server version.

This means that most of the code that we have integrated comes from the ReferenceSource drop. In the future, we will deliver a “Mono Core” along the same lines of .NET Core to allow the use of the Mono runtime with the new library distribution system that is being developed with CoreFX.

And Miguel de Icaza (CTO and Co-founder of Xamarin and founder of the Mono project) has commented that:

http://tirania.org/blog/archive/2014/Nov-12.html

.NET is being open sourced under the MIT license. Not only is the code being released under this very permissive license, but Microsoft is providing a patent promise to ensure that .NET will get the adoption it deserves.

And for the two projects in particular:

Mono will be able to use as much a it wants from this project.

...

Microsoft has stated that they do not currently plan on taking patches back or engaging into a full open source community style development of this code base, as the requirements for backwards compatibility on Windows are very high.

Answer 2

From a Mono contributor on reddit:

I think people have the wrong mindset about this whole Mono/CoreCLR situation. Why should one VM becoming open source and being ported to other OSs mean that another VM can't exist? It'd be like saying that there should only be one Python implementation, or one JVM. That is not a good thing. Competition is healthy.

Mono happens to have a lot of features that CoreCLR doesn't: LLVM, full AOT, NaCl, tasklets, cross-VM GC bridge, various profiler modules, etc. Mono's startup time and runtime memory footprint are also optimized for platforms/devices that CoreCLR isn't (at least presently) even targeting. OTOH, CoreCLR has a more mature GC and generally better code generation (hence the slower startup time). The two VMs are good at different things, and there is no reason both cannot exist.

It's not like we insist on keeping our own code either. We're happy to switch to CoreCLR/reference source code when there are clear benefits to doing so (less maintenance, more correct, still portable enough). We've imported tons of reference source code already, and we're also importing certain parts of the CoreCLR VM:
https://github.com/mono/mono/blob/master/mono/metadata/decimal-ms.c
https://github.com/mono/mono/blob/master/mono/metadata/threadpool-ms.c

From a .NET member on HN:

The core framework libraries (CoreFX) - https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently.

Basically there's a lot of code sharing happening between them and I wont be surprised if they converge in future. Now that since MS has acquired Xamarin I dont think they will be terribly interested in maintaining two runtimes.