Hello,
Now here a lot of people may ask why there are two projects with the same goal ... the thing is that the DotGNU people earlier have tried to merge the two projects together but all they got were verbal volleys from our very favourite Miguel de Icaza. The main problem at the moment is that the Mono guys (read Novell) doesn't want to have Mono under a Free Software license and they also recently changed their library licensing from LGPL to MIT's X11 license to make it more unrestrictive.
The reality is much more complicated than that. Both teams have invested heavily in their own stacks, and neither group is willing to throw away they work that they have produced.
To that mix, you can add the licensing piece, which has two elements:
* Novell licenses the Mono source code for proprietary applications, very much in the same way that Qt, MySQL and Berkeley DB are relicensed, because they allow us to fund the work of Mono while still contributing it to the free software world.
It would be ideal if all software wrote itself and we had many more contributors working for free, but today thanks to this licensing model we are able to fund 25 developers to work full time on Mono.
* The .NET technologies are a source of great debate in the open source world, and adding to the mix the fears that people have over the GPL and the LGPL makes things worse.
The particular problem is that there is room for "interpretation" in the case of the GNU LGPL about what a "derivative works" is in the presence of an OO library.
If you make a subclass of a Mono library and override a method, is it a "derivative work"? Lets say:
class MyApp : Window { ... }
Reasonable people will have different opinions.
Now, the matter is more complex since it is not about a given lawyer opinion. The problem is that every contributor has the right to interpret what "derivative works" means. Each one is entitled to his opinion, and it means that proprietary developers would risk having their source violate the license.
The choices were to invent a new license, or pick something trusted, so we decided to go with the license that gives you the most freedom to maximize adoption and minimize fear.
Mono is about brining new software to the Linux world, and bringing ISVs to Linux is something we consider very important.
They also plan to sell Mono to companies under proprietary licenses if they want to. Talking about technical issues, DotGNU is faster than Mono as Mono is self hsoting (written in C# itself) and Mono also has a very weird approach towards implementing the Windows.Forms thingy ...
The speed issue is incorrect.
The MONO VM is among the fastest VMs out there, we are now close to matching the Microsoft.NET one as we have been working on very advanced optimizations based on SSA: SSAPRE, Arrays Bound Check elimination and in general our JIT has been tuned during two and a half years.
DotGNU today has a tuned interpreter, but a tuned native code generator is better.
You might be referring to the speed of the C# compiler, but here you are comparing apples versus oranges, let me explain why:
* The PNet compiler is not a complete C# 1.0 compiler.
One day, it will get there, but it is not there today.
Speed wise, they do not implement definite assignment, which is a very computationally expensive operation, so it is easy to be fast if you do not flag every error or every warning.
* Mono's C# compiler is not only C# 1.0 compliant, but implements about 70% of the C# 2.0 stuff today, including generics which on its own took a year to develop and tune.
* Mono's C# compiler *can* be made faster, and even match the speed of cscc if you precompile all your assemblies with all optimizations like this:
for i in $prefix/lib/mono/gac/*/*dll; do mono --aot -O=all $a done
Do the same for mcs.exe
they have done it using Wine whereas DotGNU only needs X to run Windows.Forms What Mono seems to me at the moment is that it's just a C# development environment for GNU/Linux and doesn't intend to be 100% compatible with MS .Net ... they are trying to push GTk# instead of Windows.Forms ... who'll use GTk# if Windows.Forms works perfectly ? As
DotGNU's implementation of Windows.Forms is incomplete, and so is Mono's new implementation. You can not run any existing commercial application with either of them. Both will mature, but you wont be able to show me any commercial app running on either today.
We are working on a new implementation of Windows.Forms, that follows the same approach the DotGNU people took. There are four full-time developers working on it so we will soon have something ready for production use.
Now, I do believe that Windows.Forms has many flaws, specially for open source software as it does not work well with translation to different languages nor do the applications "just-work" in different languages like Gtk# applications do.
This is important to support open source programs that work in many languages.
We consider Windows.Forms to be important to bring Windows developers to Linux, but our path to independence is really using a toolkit that came out of the open source world and works well with other open source efforts.
Witness the effort of Gnome India and how well it supports every script available, or how it supports Hebrew and Arabic without changing a line in the software. Windows.Forms just can not cope with this.
far as DotGNU is concerned, GTk# or any free software libs can be easily made to work with DotGNU's Portable .Net. The fact that Gopal V, one of the major contributors to the DotGNU project ported the Portable .Net to the Encore Simputer in 3 hours flat on Linux Bangalore/2004 this time bears testimony of the portability issue.
DotGNU support for Gtk# will definitely mature in the future, and I wish them good luck, but they are nowhere the stability or completeness of Mono.
They can screenshot applications, but they wont be able to run the more complex apps like F-Spot, Beagle, MonoDevelop or even Monodoc.
As for portability, porting an interpreter is very easy. Barely anything more than "configure; make; make install". In fact, you should be able to run Mono on the Encore Simputer as well, since we support the ARM processor in our interpreter. We are now working on a JIT engine for the StrongARM, so that will give you also a nice performance boost.
While I don't intend to demean Mono in any way, I dislike their attitude towards the Freedom aspect in general and the DotGNU project in particular. (Rhys Weatherley and others have relicensed DotGNU code to Mono under their MIT's X11 license but the reverse has not happened till date). The DotGNU project needs our help and it's time we got our facts right and decided whom we should support.
I would not have replied, but "its time we got our facts right" annoys me, because your post is miss-informed and far from having the facts right. What you have heard is a bunch of half-facts.
You are wrong about that.
DotGNU has taken large chunks of Mono code under the MIT X11 and distributes it as part of their runtime (RegularExpressions, XmlSerialization) both which are very complex pieces of code.
They also ship our class libraries for any high-level features, so they tend to be behind Mono.
Good luck, Miguel.