The Java Balloon

I have a DaveNet piece in the pipe. This was part of that piece, but I want to keep that story focused on XML, and this stuff turned out to be off-topic. But I wanted to get it off my plate, so here it is as a web-only essay. Hope you like it! DW

The Java Balloon

The Java balloon is deflating as investors realize that it won't yield new hardware sales for Sun. It was a long shot that Sun could steer Java into favoring their hardware, now it seems clear to the people with the money that it won't happen and they're betting accordingly.

Now the new in thing is native code Java compilers. Produce Windows EXE files with Java? Ooops. There goes write-once-run-anywhere. And it's not just Microsoft doing it. Supercede, Symantec, IBM, Metrowerks and Cygnus all have native code Java compilers in various stages of development.

It turns out that people want native code. It doesn't surprise me. Features, performance and convenience matter a lot more to users than the Java promoters understood, or appeared to understand.

Sun's Java push was predicated on the assumption that people wanted something new (I think they did) and that Java could deliver it (Java could have, if Sun had disconnected).

It's important to close loops. Now the impure accusations hurled at ActiveX will come back to haunt Java. Keep track of what you called right and what you didn't. In this case I called it right, even though I got nasty mail at the time for not drinking the Java Kool Aid. I called McNealy and Ellison on their Network Computer vision back in fall 1996 when the industry was going ga-ga. No need to repeat the story, it's in Que Sera Sera, 10/24/96:

You could draw so many circles thru our industry. We could have a meeting of all white male geeks who make software (I guess that's Comdex). Or we could link together all the software that's made by large corporations (again, Comdex). Or everyone who's not Microsoft. Or every piece of software that's compatible with other pieces of software. Or all software that runs on a specific operating system.

Or we could have a meeting of people who have a track record shipping software that large numbers of users liked, independent of what company they work for, or if they even work for a company. (That's the group I'd like to meet with.)

We try out all the circles. Now, there's no doubt, we're trying out the idea of free source code. It's another fake panacea. It's funny to me that each of the free software worlds has a god, a single person (a white male Unix geek) who decides what goes in the official release, the one that everyone uses.

(It's also funny that O'Reilly, the sponsor of the open source summit co-owns a commercial software company, ActiveState, that sells software with closed source that builds on the open source of Perl. I hope Larry Wall, the lead developer of Perl, got some stock in that company.)

So all these bazzaar-like communities have leaders. What's so different about that? That's the way software has always worked. Someone has to make the tough calls. And the quality and intensity of that person determines the quality of the software. How good are they at listening? Only as good as a single human being can be.

Source code integration

I'd like to get together a meeting of the lead developers of all the major scripting languages and environments to talk about architecture. I see us heading down some major wrong roads. We're going to re-learn some lessons about connections, largely because of the free software thing.

Think architecture, guys and gals. The open source guys preach source code integration. That's the *wrong* way to connect a scripting language to an environment. Microsoft has an architecture, Apple has one too, now abandoned, like so much else in the Mac world.

What about the independent developer community scripting architecture?

Call to action

If you or your company make a scripting language or environment, I don't care if the source is free or if you charge $10 billion per seat, please have a look at this page.

It's software that allows Linux to run inside Windows 95 or NT. What a good idea. If there ever was a doubt of the need for communication between Linux apps and Windows apps that's vendor independent, this development should clear that up once and for all.