Comments on the SDTimes article

Miguel
de Icaza wrote up a good response to the SDTimes
article in which both of us were quoted, and I thought it might serve to flesh
out the discussion a bit more to chime in with my part in the piece.

First and foremost, Miguel notes:

David quotes Ted Neward (a speaker on the .NET and Java circuits, but not an open
source guy by any stretch of the imagination).

Amen to that—I have never tried to promote myself as an open source guy, and certainly
not somebody that can go toe-to-toe on open-source issues like Miguel can. David contacted
me specifically to comment on some of Miguel's points, and that's what I tried to
do.

Ted tried to refute my point about Java and innovation but seemed to have missed the
point.

Again, I don't think I can argue with that. Your point becomes more clear in your
blog entry, Miguel, and as you'll see in a second, I disagree with only part of the
point, and perhaps it's a semantic discussion that isn't one you (or anybody else)
wants to have, but seems important to note, at least in my mind. :-)

The article attributed this to Ted: "Microsoft has made an open-source CLI
implementation codenamed 'Rotor' freely available, but it has had little or no uptake".

There is a very simple reason for that. Rotor was not open source and it was doomed
to failure the moment it came out. When Microsoft released Rotor in 2002 or 2003 they
had no idea what they were doing and basically botched the whole effort by using a
proprietary license for Rotor.

And there we have it: "Rotor was not open source". This is the entire point
on which the disagreement (or lack thereof) hinges.

Some time ago, on a panel, I mentioned that there are three kinds of common usage
when people use the term "open source". (I'm not arguing the 'proper' definition
here—I'm arguing the common lay usage, which may or may not actually be correct according
to those who define such things.) Those three definitions are:

1. Free. ("I didn't have to pay for it!")
2. Source-available. ("I can build it!")
3. Accepting community contributions, and as a result, forkable. ("I can submit
   patches!" or "I don't like the direction you're taking it, so I'm taking
   the source and forking it and going in a different direction!")

Rotor fit the definitions of the first 2, though #1 usually implies an ability to
use it in a production environment, something the Shared Source license (the license
applying to Rotor at the time of its release) didn't permit in any way shape or form.

And Miguel's exactly right—according to the #3 definition of the above, or the
linked definition he cites, Rotor does not fit that. Period.

Alas, it is to the detriment of our industry that people don't use terms according
to their actual definitions, but a looser, less precise, usage model. Not being an
"open-source guy", I fall into the trap of using the looser definition,
and that's what I was using when I read Miguel's point and made my counterpoint.

As to the rest of Miguel's point, that Microsoft "botched" the release of
Rotor, I'm not sure that's the case—what I think was happening was a difference of
intent versus interpretation of that intent. I don't want to put words in Miguel's
mouth, so forgive me if I'm (again) not reading it right, but contrary to what Miguel
seems to believe, Microsoft never really intended Rotor as an "open source"
implementation in the sense that Mono was.

Instead, Microsoft intended Rotor to be an implementation that universities and research
groups could use to hack on the CLR or build languages for the CLR, in an effort to
promote .NET and its usage among researchers and universities. Based on the discussions
I had with David Stutz during the Shared Source CLI Essentials writing, Microsoft
never really thought that Rotor would be all that interesting as an open-source "platform",
per se—hence the reason that the GC and JIT that appear in Rotor are "simplified"
and "not all that interesting" (David's words, as best I can remember them).
At the time, they felt that these (GC and JIT) would be areas that students and companies
would want to research around those areas, so a production-ready implementation of
either was really not necessary.

In other words, Microsoft saw Rotor as JikesRVM, not as Mono. And definitely not as
OpenJDK.

Which gets us right back to Miguel's point, a spot-on analysis:

Had Microsoft been an open company in 2001 and had embraced diversity we would live
in a different world. The awesome Mono team would probably be bigger, and the existing
team members would have longer vacations.

The Microsoft of 2001 was categorically and absolutely afraid of the open-source community.
In fact, I seem to recall David listing a litany of things he'd had to do to get Rotor
pushed out the door, even with the license it had. Had David not been as high up in
the organization as he was, we probably wouldn't have seen Rotor. And, I believe,
we wouldn't see Microsoft being where they are now...

But for everyone that missed the point, luckily, Microsoft has new management, new
employees that know open source, fresh new ideas, is becoming more open and is working
actively on interoperability with third parties. They even launched the CodePlex Foundation.

... without it, because Rotor made it clear to the powers-that-be that even if they
turn loose the "keys to the kingdom" (as the CLR was thought to be, in some
quarters) out to the world, Microsoft doesn't go bankrupt. A steady yet slowly-emerging
"new Microsoft" is coming, one which is figuring out how to interact with
open source in ways that the "old Microsoft" could never consider. (Remember,
this is not IBM, a company that makes more money on services than on software sales—this
is a firm that makes its money principally from commercial software sales. Anybody
who thinks they've got that part of the open source market figured out should probably
run out and start a company, because that's a hell of a trick.)

And lest it seem like I'm harshing a bit too much on Microsoft, let's take one of
Miguel's points and turn it over for a second:

But my point about the ecosystem goes beyond the JVM, it is about the Java ecosystem
in general vs the .NET ecosystem. Java was able to capitalize on having implementations
on Linux and Unix, which accounts for more than half the web today. The Apache Foundation
is a big hub for Java-based development and it grew organically.

All of which was good for Java.... but not necessarily for Sun,
who as most of you know, just recently got acquired by one of their former competitors.
We can moan and groan and complain about the slow pace Microsoft has been taking to
come to open source, particularly when compared to Sun's approach, but in the end,
one of these companies is still in business and listed on the NYSE, and the other
isn't.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.