A few quick thoughts...

1.) Goggle's Google Talk is just iChat A/V for Windows. Pretty obvious, but it's interesting to consider. Why can't Microsoft pull this off? Two reasons: They're too big (watch Longhorn's release slip and slip and slip...) and they don't have the same cachรฉ Google and Apple have been able to create. It's no wonder Ballmer has been fuming about Google both internally and externally, though from a few eWeek reports, the external fumes are awfully calm, relatively speaking. In any event, Google is what MS thought Netscape and Sun could be. Will be interesting to see if Google gets squashed as well. Though it seems it'd be awfully difficult, Netscape was quite literally on everyone's boxes not all that long ago. Thanks for Mosaic and an all too open license at the NCSA it's, um, not now.

2.) If Mosaic had too open a license, I'm still beginning to get annoyed by how many GPL libs there are out there. Ran into one for Gmail address book exports recently. Neat idea and I'd love to have that code, even contribute, but I still have this strange notion that one day I'll finish up the mail handler I've started and sell one or two of 'em. Ask Matt how difficult it is to get someone to give up a Ben Franklin or so of income yearly and you'll see where I'm coming from, I'm afraid. Vive la GPL, etc, but please, can't we use more business friendly licenses at times? Libs would get more use and more contributions if they'd open up the possibility of linking with something commercial. Are programmers who desire profit really all that bad, or did Hurd mature without anyone noticing? I'm betting there's a reason we see "GNU Hurd Task List Version 1.22. Last updated 21 March 2000".

[Blog update 9/13 -- That is to say, I'm all for people making open source code and for people who use it to contribute their improvements to that lib back to the project at large. No really, I've talked about it before.]

3.) Will VB6 ever go away? MS could make it happen by breaking the VB6 "virtual machine" dll in Longhorn or afterwards, but why would they? VB6 still works great, there are millions withh expertise, and, well, VB.NET isn't a drop-in replacement. It doesn't seem like it'd be all that difficult to write a VB6 dll that translates VB6 to OS X, in theory. Though tons of apps would still break at points (all those WinAPI calls, for example), it would make Real Basic look like a pretender again. (Not that I've got anything against Real Basic; I'm probably the only person in my office with a REALbasic book on the shelves.)