Microsoft's Scripting Strategy
Friday, August 31, 2001 by Dave Winer.
Out of left field 
Good morning.
First I want to thank the readers of DaveNet for indulging my fantasies in the last piece about Gender Balance in High Tech. It was great to get those ideas out, and even better that for the most part my point of view was tolerated, even though I am a man and am supposed to be politically correct and only say things that are pre-approved by the feminist culture I'm part of. That of course, was the point. It hardly matters that I was making generalizations about gender, that just happens to be what my mind revolves around, something I have in common with most adult women and men (another generalization of course).
In baseball left field is considered a very strange place for things to come from. But in technology, all that remains is left field. Home plate is in tatters. The Dow dropped below 10,000 yesterday. The Dotcom Mania is totally unravelled and now we're heading below that. If we're going to get back on to Moore's curve for growth in technology it's going to take some radical thinking to do so. One of the theories for how to do this is to look carefully at barriers that we can eliminate, and one of those barriers are superficial assumptions about the roles of the genders. We've focused so much on limits imposed on women, and ignored that we also put serious limits on men. This came out clearly in many of the offlist discussions from the last piece.
Now back to ones and zeroes, and boys killing boys, the usual themes of technology.
Connecting dots
A few days ago a discussion started on Wes Felter's discussion group about the architecture of scripting in Microsoft .NET. There was a post by Adam Vandenberg that really connected the dots for me, and I wrote the first half of a white paper on Microsoft's Scripting Strategy.
As I wrote it, its brilliance was revealed. It's really quite clever, and very much from the Microsoft playbook. A total Embrace and Extend strategy, applied to all the scripting languages and runtimes in popular use. The recipe is to iteratively suck in all the developers they possibly can, and to leave those who don't get sucked in at a disadvantage in the market. Repeat till done.
Now I have much more invested in the independence of developers, so I wanted to do what I can to provide them with my theory of how Microsoft's pieces fit together, now, before they're all deployed, while there's still time to mount a complementary strategy, a zig to Microsoft's zag, so that both approaches will be present in the scripting world of 2005.
As far as I'm concerned, there's no problem with Microsoft doing what Microsoft does as long as the rest of us act in our own self-interest. The situation I'd like to avoid is a one party system, like the one we have in Web browsers today, and in desktop operating systems.
One of Microsoft's valid arguments in the antitrust proceedings has been the inability of their competition to get their act together. I'm doing my part to try to help all of us work in our own interests. (And at the same time, of course, in my interest.)
Microsoft's scripting strategy
So here are some of my ideas about Microsoft's scripting strategy.
I don't know any of these things as fact, it's just how I think they're playing it.
I'm borrowing from the playbooks of IBM, Apple, Novell, and of course Microsoft.
A hat-tip to all devious thinkers everywhere!
Assumptions
The most popular languages: JavaScript, Java, Visual Basic, Perl, Python.
The most popular runtimes: MSIE, Apache, Java, IIS, Netscape, Visual Basic.
Strategy
One runtime: Microsoft Common Language Runtime or CLR, on Windows only. (See Caveat, below.)
Every popular language runs in the CLR, however the runtimes are different. You can't take code written to run in the Python environment and run it in Microsoft's, and vice versa.
Bifurcate each community, those who run their code in the specialized runtimes, and those who run their code in the common runtime.
Iterate, in each release of the Microsoft runtime offer more features to incentivize developers to move to the common runtime.
Repeat the word "common" in every possible context as often as possible. It's not the only one, it's the common one.
At the same time, offer incentives to corporations to standardize on the common runtime. Lower cost of code integration. Choice of syntax. Broader base of developers to hire. Free or low-cost training. Trade real estate on various Microsoft Internet services.
Sorry no migration of existing code. It's a one-way street. The developers come in, but they can't bring their code with them. (It won't run, the libraries are different, the languages had to change to make the transition. It conserves developer training, but not code. The PHB's won't understand the issue, they'll think the programmers are being difficult.)
Give it a few years, a few iterations. Then.. Once prominence is achieved for the runtime, decrease support for the various languages in favor of C#. Optimizations are done in C#. Easy transition from your favorite syntax to the common one.
Block diagram
A block diagram that summarizes the two views of the scripting world of 2005.
http://www.scripting.com/images/scriptingWorld2005smaller.gif
In one view, we're all inside Microsoft's box, sharing a common set of libraries and object hierarchies. In the other view, we use our favorite tools and runtimes, our communities stay independent. The glue that connects us is XML-RPC and SOAP.
Caveat
Wes Felter asks: "What about the CLR on BSD? Is that a smokescreen?"
Without a doubt. Microsoft doesn't make any money off each BSD install. It does nothing to enhance the position of Windows or Office. Unlike Apple, BSD doesn't own any patents that could shut down any Microsoft projects.
Discussion
Microsoft has said clearly that they cannot work with the GPL. I'm not sure which if any languages this excludes, or if language syntax can be covered by such a license agreement. (Almost certainly not.) Microsoft had success with Fortran, Cobol, Pascal, CP/M, etc in the 80s. Remember that Gates was really hands-on in this period and he once again is driving the software strategy. Assume they're serious about all syntaxes running in their runtime, and assume that runtime-level compatibility is meaningless to them, there's an embrace and extend happening for each developer community.
In 2005 developers will face a choice like the one in 1981. Which OS should you develop for. The original PC had three operating systems -- CP/M-86, UCSD P-system or PC-DOS. It's nice to have a choice, but we all know which is the favored one. Microsoft loves languages, but they also love to save money. If you only have to develop and maintain one codebase, you can use the internal developer-hours for projects that make money. (Developer tools and runtimes are almost purely strategic activities, generating a relatively small amount of money.) As PC-DOS was the consensus choice in 1981, in the Microsoft scripting world of 2001, C# is the default, we all know it, factor that into your thinking, it's a certainty.
It's now clear why MS was willing to release the source for the runtime. None of its competition is well-enough organized to create an alternative to Microsoft's centralized runtime to make a difference. Based on the experience with Netscape, even if an alternative could be organized on a corporate level, it's a safe bet that the engineering could never sustain two or three year competition with MS engineering. Further, they'll have all other kinds of lock-in at the service level. To create a competitive runtime you have to be able to bundle with all the OEMs to make it effective. In other words, who cares about the source code. And if all that fails, they always have great lawyers and patents.
What does everyone else do?
Now we get to the interesting stuff.
What if you don't work at Microsoft, and today in 2001 are happy working in Python, Apache, Perl, Java or whatever, exactly as it is. You like the community, you get along with its leaders, you're making good money, life is good, and you don't want to become a Microsoft developer. What do you do?
Sorry no answers now. ;->
I want to flesh this thinking out over a few days, and then listen, and see if there aren't ideas out there for short quick things we could do to enhance integration between the various runtimes, without forcing all code to run in Microsoft's runtime. It's not up to me whether or not independent developers get a strategy in place to exist in the world Microsoft envisions, it's up to the members of the various communities that now exist independently, to preserve their independence. Some have wished that a czar would appear to tell them what to do, but that is a contradiction, with another czar we no longer have independence. For the nth time, all it takes is a will to work together for the benefit of all. That's the revolution we're all waiting for. Anyone can be a hero of this revolution, and in order for it to mean anything, it must remain that way.
Anyway, in the past when I rush to make a recommendation, it often doesn't go anywhere, so let's pause and give it some thought.
Dave Winer
PS: PHB stands for Pointy Haired Boss, one of the characters in Dilbert comics.
PPS: BSD stands for Berkeley Software Distribution. The term has come to stand for a style of open source license, that unlike the GPL (see below) places few constraints on how code can be used. It is also used to refer to a specific version of Unix called BSD, or FreeBSD.
PPPS: GPL stands for General Public License, a license favored by the "free" software movement, led by Richard Stallman. The GPL says basically that any enhancements to software must also be made public. This is of course a simplification, and subject to endless debate.