Tangled in the Threads

Jon Udell, June 28, 2000

Bill Gates Has a Dream

Reactions tend to be negative, but there's a lot to like about .NET

Microsoft's recent announcements were typically schizophrenic. In some ways, the company "gets it"; in other ways, not. The .NET preview at Forum 2000 was handled in a clueful way. A few years ago, when I covered these kinds of events for BYTE, I was expected to schlep out to Redmond -- a day of travel, a day of dog-and-pony, a day of travel. This time I absorbed what I need from the transcripts and webcasts. Having both was incredibly efficient. I could read what Bill and Steve and Paul said a lot faster than I could watch and hear the same material, and I already know what these guys look like. So I used the webcasts mainly to check out the demos. I found these by searching the Web transcripts, then jumping to the corresponding position in the videos. Not quite random access, but still very effective. I think I achieved time compression of at least two-to-one -- plus, of course, the two days I didn't have to spend enduring the friendly skies of United. Thanks, Microsoft!

The C# announcement was, by contrast, handled rather cluelessly. As Jeffrey Shell noted in the programming newsgroup:

I love that further documentation is in the form of .EXEs. I think that announces their portability hopes right there. All my main machines are Macs, and I was curious about C#, but once I hit those links.... ugh. It's like posting proposals for web protocols in gzip'd postscript.

Indeed. Of course, what you've got to admire about Microsoft is that they do listen, learn, and adapt. I checked the C# page again today and lo, the .EXE version of the docs has been augmented with an HTML version.

Negative reactions to .NET

Newsgroup participants were, on the whole, rather negative.

Laurent Szyster:

Obviously C# provides Java's main benefits. Yet, C# will allow old-fashioned C/C++ development (i.e. pointers) and COM objects (instead of Java Beans).

And about portability? Well, guess what ...

James Power:

Historically, this is Microsoft's modus operandi:

  1. The Vision.

  2. The first attempt at implementation. "Sure it is much, much less than promised but it is only the first version."

  3. The second attempt at implementation. "It is here, use it, use it, use it. Maybe it has a few growing pains but we will get them worked out."

  4. Moving on. "We are no longer developing to that old fashioned model. Wait for the new one".

  5. Goto 1.

    6. Note there is never a fully realized version in this process.

Jeffrey Shell:

One the concepts in C# is programming language independence. I thought this was supposed to be solved by ActiveScripting. Or Scripting Host. Or Scripting Shell. Or whatever the latest Microsoft term du jour is.

As far as SOAP goes, apparently IBM is involved now and making it much richer, and much more complex. Basically, turning it into a slower, weaker CORBA. Ugh again.

Someone says that the mantra for the 1990's was "Ship the prototype" and in 2000's it's "Ship the idea!"

I think it's "Ship the idea of reinventing the wheel a fifth time, but this time as XML!"

The industry is becoming a parody of itself. Best evidence: when Salon articles become funnier than Onion articles.

Security concerns about .NET

Significantly, several people voiced the same concerns about the security implications of .NET's everything-is-a-web-service approach:

James Power:

When Microsoft decided to out-macro Wordperfect and introduced VBA as the macro language, there were plenty of people who pointed to a future of "Melissa" and "I Love You" viruses. If the top ten purchasers of Microsoft software, the ones that buy 100,000 copies of Word and Excel, the ones who get the exclusive Alpha and Beta support, had made it clear they wouldn't accept a shipping product with such a gaping security hole in it, Microsoft would have pulled it out. Instead, they rewarded Microsoft by dumping Lotus 1-2-3 and Wordperfect. Microsoft made the right business decision. The IT people (including all the unofficial ones who form the IT backbone of most small companies) made the wrong one.

Jeffrey Shell:

The wheel that's being reinvented will be more prone to security holes, and a lot less well-designed, but you'll be able to do: 

http://sql.myserver.net/select+*+from+foo

from your web browser! Things like Melissa and I Love You are supposed to be easy to disable by just hitting the right switch, but who flips those switches? Apparently not enough people. With this latest round of web services proposed by Microsoft, I bet they'll make it incredibly easy to turn any little thing into a web service, but I bet it will leave some pretty big security holes. That's been their pattern in the past. VBA, I'm sure, can be a wonderful tool, but it can sure as hell mess things up as has been proven recently.

A more positive spin on .NET

Although it's clear that MS is struggling to find ways to leverage and extend the Windows/MSIE lock-in, I find little fault, and much substance, in the newly-announced architecture. We already have first-generation web services; they're powerful; the flip side of powerful is dangerous. CGI security holes have wrought at least as much havoc as have VBA holes, but few would have shunned the first-generation web until "that CGI security hole" got plugged. There's no going back. We're going to have next-generation web services, and we're going to have to learn -- probably the hard way -- how to control them.

To a large extent it is MS that has pioneered the modern conception of reusable binary packages of software. And, more generally, the notion of software development as a two-tiered affair involving components and glue, created respectively by component-builders and component-assemblers. This whole model is now transplanting itself to the Net. MS gets this better than many in the open source community. Significantly it's MS that's been the real force behind SOAP.

For me, one of the most compelling tidbits in the Forum 2000 was the BizTalk demo. In BizTalk, the design canvas is an extension of the Visio diagrammer. And that canvas is divided into two parts. One's a catalog of components, built by programmers. The other's an assembly kit that's used to build business processes around these components. But the user of this kit isn't expected to be a programmer of any kind. He or she is expected to be a business analyst. That's why Visio makes sense here -- business analysts already use Visio to model business processes. Now (in theory) they'll be able to use it to implement those processes as well.

To materialize the "cloud" of network services at the heart of the .NET vision, we've got to break the programmer bottleneck. It's true that in some ways .NET is already here, just by virtue of the fact that we have a pervasive HTTP network, and XML-over-HTTP protocols and tools. Thanks to this existing web infrastructure, it's a whole lot easier than ever before to create network services. Easier for programmers, that is. But as businesses painfully realize, programmers are hard to find and keep. Enabling more (and different kinds of) people to build out that cloud of services is a noble and necessary ambition. There's going to be a huge market for cloud-construction tools. I'm sure Microsoft would love to own the cloud (who wouldn't?) but nobody can, and MS doesn't need to in order to make a lot of money helping people build parts of it.

Of course it's not the cloud that people use directly, it's the client. With control of both the client OS and the browser, MS is clearly in a position to strongly influence the next generation of Internet client software -- which, in turn, will influence what happens in the cloud that MS will share with everybody else.

There's a lot to like about the next-generation .NET client. Its themes -- universal data representation in XML; a single container for heterogenous and rich datatypes that can always be edited as well as viewed; metadata-enriched documents and messages -- express what we all want and need. But we're going to have to climb off this comfortable HTML plateau we've rested on for the last five years. It's time to rework the idea that HTML proved so effective: the document as networked application.

There's no reason why the open source world can't make all the necessary client-side magic happen in terms of open, interoperable standards. But that won't just happen by itself. There needs to be, on the part of the Linux, Java, and Mozilla forces, a clear and consciously-articulated vision and roadmap. To me that's the ultimate open-source challenge: reaching consensus, and turning ideas into marching orders, without a single "chief software architect" such as Gates.

Non-interoperability isn't a luxury MS can any longer afford, when it's clear what it must interoperate with. Defining just what that will be is the OSS challenge. Leave a vaccuum, and MS will fill it -- as indeed any responsible business should try its best to do.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.