We have announced that our upcoming Mono release (2.8) will default to 4.0:
For the first time in Mono's history our C# compiler and its supporting engine and core libraries were done before Microsoft released the product, we were usually one to two years behind. This time we are some five months ahead of time:
There are still a handful of loose ends here and there, but luckily, nothing major.
.NET was released in July of 2000.
And Google uses a mix of languages and tools: different features require different tools and all that. Had there been no legal problems, it would have been a no-brainer to use
It did not have to be Mono, it could have been a third party
Rather, submit patches to replace System.Data with Sqlite-net and you have protection from Microsoft patents on
You are mixing two different things.
Microsoft claims that they have patents had a chilling effect on Mono adoption.
That does not mean that I do not stand 100% by our position in the Mono project regarding patents. To begin with, we think it is a bullshit argument, since everything you use is infringing on someone else's patents (Microsoft included).
Microsoft like any other corporation will do a cost/benefit analysis of suing someone over patents. So far the kernel has been a juicier target than Mono has.
I provided some context to the SD times article on my blog today:
Perhaps you need to read the GPL FAQ:
As the other poster said, the fact that we do not have 1:1 parity has never been a problem.
Some other technologies that are subsets and are wildly successful:
* Android's Java is not a 1:1 mapping to Java either, and that has not prevented it from being successful.
* iPhoneOS is not MacOS 1:1, and yet, it is incredibly successful.
* Chrome the browser, does not have every feature of Firefox, that did not stop it either.
* JBoss is a subset of the full J2EE stack, and for years it has been wildly successful.
* Linux for years was not even POSIX compliant, and yet, many of us jumped on it, and it became wildly successful.
In Mono we implement what makes sense, and what people are actually using in day to day applications, we do this using metrics that we obtain from our Mono Migration Analysis that helps us identify which APIs are used, by how many applications and we have collected this data from some 10,000 applications:
Call this the data-driven prioritization of development.
Mono was born as a technology to bring the best that
(a) Organica growth: as the Mono community grew, we identify missing features, we envisioned better ways of doing something and created tools, APIs, languages and extensions that mattered to us. In this category you can find things like Gtk#, Taglib#, Cairo#, Cecil, Mono.Options, Mono.Security, Mono.Data, Mono.Math, Mono.Management, Mono's C# REPL, Mono's SIMD extensions, Mono's large array support. Mono's dynamic JIT extensions, Mono's static compiler and much more.
For instance, today, more than 350 applications on the AppStore and 10 of the top 100 apps in there are built using Mono.
(b) Better compatibility with
Is it correct that we do not have a full implementation of
(i) Some APIs are Windows specific, and makes no sense to bring to Linux, in particular things like System.Management which is a thin wrapper around WMI. Our advise: replace that code with Linux and MacOS specific code and use one or the other at runtime.
(ii) Some APIs are too larger for us to take with our current community. This includes things like WPF and Workflow. If someone steps up, we will embrace them, but until that happens, we are focused on improving the other areas that have more users and that we have more requests to implement. Additionally, the WPF "lite" is a killer stack (also known as Silverlight).
(iii) Focus, we do not want to spread ourselves too thin.
Moonlight is behind Silverlight, but I am not driven by despair, I am driven by the world of possibility. If I were driven by despair, I would not have written a single line of code.
If Silverlight never succeeds, then who cares how behind Moonlight is. But if Silverlight succeeds, and Linux users want to access that content, but the feature is either broken, not implemented or missing in Moonlight, those users will be in a position to contribute the code, and everyone wins.
Very happy to hear that!
I can only hope we will continue to improve Mono and MonoDevelop.
We removed the GPL code in MonoDevelop for a couple of reasons:
(a) to allow it to become a platform that third-party plugin and add-in developers can target.
(b) to allow us to consume open source code that would otherwise conflict with the GPL (MS-PL licensed code, Apache licensed code, and original BSD licensed code).
Notice that (a) is the norm for Eclipse and Visual Studio, and that the ecosystem of third party plugins relies on this, both Eclipse and Visual Studio would be severely limited if they limited the plugins to be all GPL licensed. As I explained on the blog post, there are current users that need to run their non-GPL code inside the IDE.
We want more third party developers to target MonoDevelop, and we want these third parties to consider MonoDevelop a platform that they can target without forcing a license on them. Similar to how the Linux operating system can run code licensed under any license.
The second reason is just a practical one. In the