Microsoft is handing over the Mono project to WineHQ, which came as a bit of a surprise announcement today.
We are happy to announce that the WineHQ organization will be taking over as the stewards of the Mono Project upstream at wine-mono/Mono · GitLab (winehq.org). Source code in existing mono/mono and other repos will remain available, although repos may be archived. Binaries will remain available for up to four years.
Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork. That work is now complete, and we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET which includes work from this fork.
↫ Mono’s website
Wine make use of Mono, so this seems like a natural home for the project. Mono is an open source implementation of Microsoft’s .NET, and is available on a wide variety of platforms, but lately it’s been languishing a bit, with no major release since 2019, and only small patches since then. Microsoft gained stewardship over the Mono project when it acquired Xamarin in 2016.
My understanding is that Mono is an open-source implementation of .NET _Framework_, which was Microsoft’s name for the closed-source variant that existed between 1.0 and 4.x. They dropped the word “Framework” from the name when they moved to an open-source license for .NET v5.x, a move that also obsoleted the need for a separate open-source reimplementation. As such, Mono is only really for running things written in .NET v4.x.
Honestly, it’s surprising the Mono project has gone on this long; I suppose they must have still been finding things to re-implement. Mono is useful for legacy stuff, but nobody should be developing new work in Mono.
That said, it’s a perfect fit for Wine, given Wine’s focus on providing an open-source replacement for Microsoft’s closed-source DLLs and working to improve their compatibility with Windows applications, both old and new.
In a sense, this is Microsoft giving a nod to how re-releases of Windows 9x-era games that aren’t done by rewriting the engine on top of SDL tend to need something like Wine’s OpenGL-based DirectDraw DLLs to fix the 256-color palette breakages introduced around DirectX 8 with the official ones.
Bit of a shame that Microsoft has only released source for DOS 4. I don’t imagine they’d lose much business from open-sourcing DOS 5 through Windows 98 SE.
I think open sourcing anything after, and including, win95 could be a legal and economic minefield, given that Win95 is still somewhat competent as an OS, as it uses the still-relevant Win32
However, the Win16 line has been dead for decades, Win3.1 should definitely be a candidate for open-sourcing. Even if the code was forked and updated to modern standards, the architectural differences between Win3.1 and modern NT would be insurmountable, and i suspect any fork based on Win3.1 would be relegated to older 32-bit systems at the best.
You understand what the Mono Project is perfectly. As far as being surprised that it “has gone on this long”, we should first be honest that the level of development has been pretty anemic for several years. There are two groups of users. First, there are the users who want to run what was written to be Windows-only software on other platforms. In that way, it is driven by the same forces as Wine itself ( and even things like ReactOS ). The second group are those that chose Mono as a cross-platform development framework ( back when that is what it was ) and who are still selling or supporting software that relies on Mono. Many of these software providers will have moved on to .NET 5+ by now but some still rely on Mono. On reason for this is that Mono was ported to a greater number of platforms than Microsoft .NET has been. You also get projects that incorporated Mono at a deeper level ( the Unity game engine comes to mind although I think they have been moving off Mono as well ).
Microsoft essentially bought the Mono Project when they bought all the developers as part of their Xamarin acquisition in 2016. The Mono Project stopped making releases not long after that but Mono development, by the original team, has continued unabated. It has just become part of .NET proper as the runtime that allows .NET to run on mobile platforms like iOS and Android, Technically we can say that Microsoft forked Mono but really they just moved the project to a new repo while leaving the old repo in place. Activity in the old repo dropped to a shadow of its former pace after Microsoft moved dev to their own repo.
Taken from another perspective, Microsoft basically did the same thing to Mono that they did to their own in-house .NET implementation. What Microsoft now calls .NET ( most recent release version 8 ) was first released as .NET Core alongside the original .NET which had reached version 4.x after being around since 2001. Now the “original” version is called .NET Framework and is a fully supported but otherwise totally abandoned Windows component ( stuck at 4.x for many years now ). The last release of Mono was in 2019. .NET Framework essentially ceased development around the same time.
.NET is of course officially cross-platform now but, since .NET 5, a big part of what has enabled that cross-platform nature has been the incorporation of Mono under the hood. Modern .NET has two run-times and one of them is Mono.
So my view is not really that Microsoft is turning Mono over to Wine here. Microsoft changed the definition of .NET and abandoned the version of .NET that Mono was founded to replicate ( .NET Framework ). They then redefined Mono itself within the context of their new .NET version ( .NET Core ). They continue to develop Mono in this second context and they are keeping this version for themselves. It is all fully Open Source of course but they are not relinquishing control or turning over the “real” version of Mono to anybody. What they are turning over to Wine is the original Mono repository and the original definition of Mono as a re-implementation of .NET Framework. If Microsoft does not even want to do anything with their own .NET Framework on Windows anymore, they certainly have no interest in maintaining an Open Source re-implementation of it.
As above, the old Mono repository and the old definition of the Mono Project are focused on re-implementing .NET Framework which is a legacy component of Windows designed to support legacy software. The has nothing to do with modern .NET or indeed modern Mono. It is a pretty good fit for the mandate of the Wine Project though so, in many ways, this move makes a lot of sense for everyone.
I am in no way criticizing or minimizing this move. It makes sense and I think it could actually bring some clarity. My point is just that Mono dev has moved from the original Mono Project to Microsoft and that is not the development that Microsoft is turning over to Wine.
The Mono Project was founded explicitly to create a great Open Source cross-platform application development framework. That is what the original Mono Team wanted ( first at Ximian, then Novell, and finally at Xamarin before being bought by Microsoft ). The original vision for Mono has moved inside .NET itself and, if you are looking for an Open Source cross-platform application development framework in that tradition, you should be looking at .NET proper from Microsoft themselves ( .NET 8 currently ). The only meaningful way to think about the original Mono Project now is as a support layer for legacy Windows compatibility. That makes it a perfect fit for Wine.