Microsoft's Scripting Strategy

Tue, Aug 28, 2001; by Dave Winer.

Microsoft's scripting strategy 

Here are some of my ideas about Microsoft's scripting strategy.

I don't know any of these things as a 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.

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. (Caveat.)

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 web 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.

Caveats 

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.

Comments 

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. (Clearly 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 guiding 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.)

It's 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 (the DOJ made sure of that).

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 document out over a few hours or 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.

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