I always love being asked that. Here are my thoughts overall on where we are with mono and some related bits.
1. Be sure the standard bits of mono are safe.
The Community Promise looks pretty good here. I would be very interested to hear any reasonable attack that could be brought to bear against the standard bits of mono by Microsoft.
No concern here.
2. Make sure non-standard and standard bits are clearly separate.
Based on the comments and reading I have done, the mono team is already on top of this, or in some cases already done.
No concern here.
3. Do not get into a situation where the non-standard bits are required.
Team mono obviously wants to see mono as an important and wide-spread platform. That’s great. Is mono without the non-standard bits good enough to do that? Or will it be one of those things where to really get any use out of it, you need those special bits? Microsoft talked about this in internal emails specifically.
Can we get an honest mono proponent to talk about how vital non-standardized features (AppDomain, WinForms, ADO.NET, etc. are for “real” developers)?
For example, say someone wanted GNOME 4.0 built in mono. Can you do everything you need and stay within the standard? If not, start working on Microsoft to get those bits standardized and under the Community Promise.
This could turn into an issue, but I don’t think there is enough concern here to get all up in arms about. I would just keep an eye on future mono projects and see if there is a big use of the non-standard bits.
4. Get those non-standard bits safe.
Novell absolutely needs to be taking the lead on getting Microsoft to apply the Community Promise on other interesting bits of .NET. I know that’s going to be a tough road, but that’s part of the responsibility you took on.
Slight concern here, going back to point 3. Plus, the more stuff you can set free the better, right?
5. Get honest in your promotion of mono.
If people are demanding better protection and assurances, then deliver them. From day one – when I was considering implementing a project using C# – all the mono apologetics struck me as hinky. As time went on, I moved from apathy to activity against mono.
I understand you may feel sick and tired of dealing with criticism, but you have to know that dealing closely with Microsoft you are going to face extraordinary distrust. So, you must provide extraordinary assurances. Fair or not, that’s the reality.
No real concern here, things get nasty because the internet is serious business – gloat for a while and then get on with things. If some new controversy breaks out, handle it better.
6. Get control of C#.
Mono likes to play up that it has a few namespaces that .NET doesn’t, like Mono.Simd. Does it make sense to get those in the standard?
One of the fears people have is that Microsoft could somehow change the standard so that no one could implement it properly. Another is a distaste for using a company-specific language – it just “feels” proprietary.
The more C# / CLI are perceived as being “real” independent standards, and not just rubber stamps for Microsoft, the better mono looks. It also assures those who think mono’s life is tied to Microsoft’s support of C#/CLI. Microsoft has been known to crazy promote a technology and then abandon it, where would that leave mono’s long term prospects?
Slight concern here, but again nothing to get up in arms about.
7. Moonlight
You have to get that garbage safe. The so-called covenant is downright anti-community – you know it, I know it, and the American people know it.
All sorts of concern here, but offset by the fact that I doubt Silverlight has more than 29 users worldwide, and I would guess moonlight has about 7, including Miguel. Also, every other 3rd post on the internet isn’t about how moonlight is awesome rocks and better than any other application ever and needs to be on the desktop of every distro.
Closing up shop?
No, not yet – I’ll be sticking around a bit to see how things develop. I won’t be searching out old arguments or points, because there is no denying that things are changed.
#1 by Miguel de Icaza on July 7th, 2009
Regarding Mono.Simd: ECMA 335 is in session right now, working on the next edition of the standard and Mono.Simd is up for consideration.
The only problem with Mono.Simd is that it has only been tested on Intel, and we do not know how well this design maps to other processors. So we first need to implement it in various other processors to understand how well (or bad) the API maps to them and whether Mono.Simd requires changes.
Mono.Simd has continued to evolve since we originally released it. Since it has not yet fully settled, it is not ideal to become part of the standard. It was part of the upcoming standard, but at the committee we decided that it was best to wait.
We need to get Mono.Simd working on ARM, Power, Larabee and a handful of others before we feel that we have a general purpose solution that will work across processors and before we can recommend that it becomes System.Simd.
We have been working with Microsoft on the ECMA Community Promise and the Moonlight Covenant for some time. There was no point in pre-announcing anything, so I remained silent as I did not think I could add any value by beating a dead horse. Instead I went to talk to Microsoft and outlined the problem and the need for a better patent license. Microsoft was very supportive and receptive and the wheels got in motion to get this approved. But it takes time.
As for Moonlight’s covenant, not only we are on the same page, most importantly, Microsoft is on the same page. But things take time.
#2 by Jason on July 7th, 2009
Miguel,
Well that is good news. For what it’s worth this latest news has earned you guys the benefit of the doubt from me at least.
I’m still not ready to tattoo a monkey on my chest, but I will temper any future criticism in that light.
#3 by Miguel de Icaza on July 7th, 2009
Let me know, we can send the SVG for Mono’s logo directly to your local tatooo parlor.