An Open Spirit
But from the moment Miguel initiated the Mono project, I’ve been worried about its future potential. I’ve feared that it would go the way of DCOM on Unix. (DCOM is an Open Group standard – and Microsoft retains ownership of its intellectual property.) A number of vendors implemented DCOM on Unix, but almost no one ever used it, because DCOM is pretty worthless without a bunch of application-level class libraries, such as ODBC, OLE DB, ADO, and ASP to run on top of it. Microsoft never released these specifications to the public, so these technologies have never been available for Unix. Hence DCOM on Unix faded away into irrelevancy.
With DCOM back in our minds again because of its exploitation by the Blaster worm, the reminder of how DCOM is an 'open' technology because it was 'donated' to Open Group as a marketing stunt is a good reminder that the path Microsoft has taken with C#/CLI is not new. Another expression of 'openness' was the availability of NT on chipsets other than Intel, which withered because Microsoft was really only interested in NT on Intel and left the really active maintenance of the code to partners who couldn't keep up, that NT/Intel was the only really viable platform.
What we learn from each of these forays into openness is that it doesn't matter how sound the vehicle being used to express the apparent 'openness' is (ECMA for C#, Open Group for DCOM, partenr community for NT), what ultimately matters is the open spirit of the originator. If their intent and method is essentially open, the process bugs get fixed along the way and more and more becomes open.
In the case of the Java environment, things have gradually opened up to the point where Apache are able to implement the whole of J2EE (in their Geronimo project). The process bugs (there have been plenty over the years and as Anne hints there are still a few to fix) resulted in the most part from the design of the process by humans. Sometimes it took waaay too long to fix them, but the underlying spirit has remained an open spirit that's resulted in increasing openness. The result has been a rich and diverse marketplace with many strong players, and for J2EE there is wide choice at every stage for the developer.
So when Anne proposes
So the way I see it, in order for Mono to succeed, we need to develop a set of open frameworks, engines, utilities, tools, APIs, and class libraries that run on top of it.
I am left asking, why bother? Why not instead support Geronimo? What is the IP encumberance that makes Geronimo unsuitable? The history of the Apache project is that it has acted as a gadfly to Java, causing the (mostly unintended) process bugs to get sorted. I anticipate Geronimo having the same effect, 'outing' the bugs and getting them addressed. Supporting it will strengthen the openness of Java and help ensure a future for choice. My instinct tells me that getting developers working on C#/CLI projects to re-invent the Java wheel will not have the same effect.
[Also posted to Webmink]