RMS Asks Miguel to Explain Himself

phaze3000 writes "RMS, responding to questions from the audience at the World Social Forum in Porto Alegre, Brazil last week, has asked Miguel de Icaza to explain himself to the Free software community about comments made last week that Gnome should be based on .NET in the future. More details at Brazillian site Hotbits and in The Register." I find this amusing.

Comments

Poor Miguel

[Malcontent]

I think people have misunderstood Miguel. What he has done here is to use MS as an R&D dept. MS spent millions researching .NET and built a comprehensive set of tools. GNU (and the rest of us) can benefit from this research, they can take the best ideas from .NET and implement them in MONO. This is a GoodThing.

There could be a problem if MS shifts the spec or extends the spec. At that point if Miguel decides to chase MS he loses. If he decides to "fork" .NET and stick with the standards he wins because .NET will become fragmented.

I think Miguel knows what he is doing. I say give him a chance if history is any indicator he will kick ass.

In essence .NET and C# are full of ideas borrowed from JAVA, DELPHI, DCOM etc. Why not pull an MS here and embrace your enemies. Take their ideas and run with them!

Re:Poor Miguel

[spongman]

Of course they will extend it. I'm sure they're not presumptuous enough to thing that it's 'finished' after the first release.

On the other hand it would be short-sighted of them to make v2 incompatible with v1 for no other reason than it would piss off their loyal developer following immensely. They'll add new features, but I'm pretty sure that old .NET assemblies will still run on the new system. Microsoft has been very careful to continue their binary compatibility up the operating system line (DOS apps ran on win31/win9x, most dos/win31 apps run on NT/2K/XP, etc...) They would lose far more than they could possibly gain by changing this.

Quite right too

[DrSkwid]

Pinning GNOME to .NET sounds like a braindead idea to me anyway. Perpetually playing catch-up and being involved in an arms race with MS. If you have any knowledge of the history of computing then you'll know the sands of .NET will continually shift.

Just look at the lineage :

dde, ole, ole2, com, dcom, dcom + mts, soap, .NET

J++ & Active Directory probably fit in there somewhere too.

Pinning your business model to any of these technological donkeys is an expensive move.

to paraphrase :
The MSDN treadmill moves pretty fast, if you don't look around once in a while, you might just miss out!

Everybody has a duty to question, I'm glad RMS has done it so publicly because if it was me that asked then I doubt we'd see any discussion on /. about it!

SAMBA, Wine, Reality Check

[GroundBounce]

The article points out that it should be OK for the free software community to implement MS API's like SMB (SAMBA) and Windows itself (Wine) because they are already established standards, but it should not be alright to implement .NET because it is only an emerging standard not yet heavily adopted by many.

I disagree with this conclusion. Why wait. If you wait until .NET is popular and widespread before starting a compatable project, then it will already be too late and you will be eternally playing catch-up. Think how much more accepted Linux might have been if it was also able run Windows applications well from the get-go.

Here are the two possibilities:

1 - .NET becomes very popular and widely deployed as Microsoft wishes it to be. In this case Linux and other OSS will benefit from already having a .NET implementation (Mono) in place. No need to spend two or three years to play catch-up while OSS loses market share to MS.

2. - .NET is a bust and never becomes popular or widely deployed. Microsoft loses big time (since they are hanging their future on it), and OSS (mainly just Ximian) loses a gamble by having wasted some development resources. Big deal. And mainly just Ximian would have lost anything, the rest of the OSS community will have lost very little.

These two alternatives seem better than the third possibility, which is that .NET and C# become widely deployed and OSS operating systems are caught with their pants down, not being able to host any .NET related services or applications.

RMS hating or MS hating? Tough choice.

[Dr. Awktagon]

I think a lot of /. folks are letting their RMS disillusionments take control. I personally would definitely NOT like to see the Free software world start using Microsoft-invented, Microsoft-owned, Microsoft-patented technology if it can be helped.

This is like turning Gnome into a Windows app. Sure, .NET sounds cool from a technology point of view but you should know by now that technology doesn't live in a vacuum. As soon as anything based on .NET becomes a threat to Microsoft, they will cripple it, through technological or legal means.

The Free software community should stand firm and develop and use open technologies, and not even pay lip service to .NET.

I agree with the view taken by Nick Peterly (or whatever his name, I can't remember right now) that Miguel has been baited by Microsoft .NET and this will just give Microsoft a way to try and subvert Free software. Maybe that's not what MS was thinking at the outset, and not what Miguel is thinking, but it will be possible and we shouldn't allow MS that kind of power.

I for one will lump anything that uses .NET in with Microsoft products, even if it's "open source". Why take the chance? I'm surprised that so many /. folks are calling .NET "progress" or "a standard". It's just a Microsoft technology.

.NET and Mono: What is standard and what is not

[GrayArea]

Well, I decided that, instead of perpetuating the /. tradition of shooting out of my ass without doing my own research, I'd see for myself which parts of .NET API's were in the ECMA standard, which parts were not, and how much of it Mono is implementing. So, after downloading the ECMA documentation, I compared it to Microsoft's .NET Framework SDK docs and Mono Class Status page. Here is what I found:

1. The ECMA standard includes a total of 249 types (classes, interfaces, etc.) as the standard library. .NET Framework SDK has approximately 3500 classes defined according to Mono Project, and they claim they have implemented or currently implementing 900 of them. Their status page shows 540 classes as work-in-progress, though that might be out of date.
2. There are missing classes, interfaces and even methods and properties from the ECMA standard. For example, out of the 120+ types in the System namespace, only 100 of them makes it into the standard. Of the 100 or so methods in the String class, more than 20 of them are not in the standard, including a few constructors. This doesn't seem to be an exception, most (but not all) of the classes have missing members. The SDK documentation doesn't give any special notice about members or types missing from the ECMA standard. I am assuming Mono is implementing the full Framework SDK versions of these libraries.
3. The ECMA standard libraries define a feature set that is somewhat larger than the C runtime library, the most noticable additions being the network and XML processing libraries. There is a lot of stuff left out, both additional libraries and functionality inside existing libraries (as outlined above).

After this, it is kind of easy to reach to the conclusion that the ECMA standard has major deficiencies, that there is no way (apart from custom tool support) to tell if the code you are writing conforms to that standard and that Microsoft is most likely just paying lip service to the standards process, at least as far as the core .NET API's go. Java and Sun do a much more complete job of defining and sticking to specifications if the ECMA work is any sign.

Personally, I don't plan to touch .NET API's to develop open source software after this. My opinion is that Mono would be much better off if they develop their own cross-platform class libraries instead of using .NET API's. There is nothing preventing them from using CLI VM and multiple language support with their own class libraries. They are already writing everything from scratch, they might as well use their own design rather than playing catch-up to proprietary Microsoft API's.