When I was a lad, I tell my kids, life was hard. We had to walk everywhere, for instance. And not only that, we had to carry our own data. On things called floppies. Back then, we had to manually move information from one computer to the next. We did all this work by hand.

When modems came along, we were sure we could do away with the floppies. Of course, the first modems I used transmitted at 300 baud – about the speed of a John Deere tractor in a cornfield. And then there were the protocol incompatibilities. On my first job, for instance, I spent days with a couple of black boxes and cumbersome acoustic couplers trying to get a Compugraphic in one office to wake up the Harris in another. (By the way, these things were real computers, green-screen, line-editing rigs, not the fancy turbo-graphics models of today.)

I never did get the machines to talk. Even dozens of calls to the two companies produced no workable solution. Apparently the Harris – the newer model – had made some “refinements” that the Compugraphic couldn’t understand.

This was my first, but unfortunately not my last, brush with incompatible technologies. I spent all of the ’80s and the early ’90s with a lingering question: Why does the cost of innovation have to be disruption? It seemed every new technology couldn’t just augment the previous paradigm, it had to rip it to shreds and replace it. (Not that I take it personally, you understand, but I still have emotional scars as a result of the transition from LPs to CDs.)

Then, just five years ago this month, I saw the light. Well, actually, I saw a prototype Java Web browser. The screen was singing, literally. Hard to believe, but in December of ’94 the world was still pretty impressed with the ability to represent a static page of information uniformly on any computer. And here was executable content inside a Web browser. It was utilizing the Web protocols, not breaking them. Innovation without disruption.

The technology advancements the Java community has made in the ensuing years closing out this decade are nothing if not phenomenal, culminating with the release this month of Java 2, Enter-prise Edition. We’ve gone from dancing Web pages to harvesting all that legacy business logic and extending it out to the network. So what’s made it work? Well, to be sure, Sun has done its part. So have Oracle, IBM and about 200 licensees of the technology. And a million- plus Java programmers, such as you.

The key really has been one simple rule: innovate compatibly. Make any changes you want, but don’t break anything in the process.

We formalized this rule in what we now call the Community Source License and the Java Community Process.

The Community Source Licensing program means access to the source code by simply clicking on a Web page. As easy as that click is, it comes with a responsibility: innovate, but remain compatible. Take the source code, use it for R&D purposes, modify it if you wish. Once you reach the stage of creating a product, you’re required to pass compatibility testing to ensure that these modifications don’t break anything.

Beyond the licensing model is the Java Community Process, a framework for evolving the Java platform that harnesses the intellectual capital of the entire Java community. Here’s how it works.

Any company, organization or individual who has signed a Java Specification Participation Agreement (JSPA) can submit a request for new or additional functionality to the Java platform. If the request passes the first set of hurdles (a check to ensure that this functionality doesn’t already exist or isn’t underway as a project somewhere), an expert group is formed.

This group is responsible for writing the specification. The leader of this group, usually the individual who submitted the request, is responsible for developing consensus within the group as well as rendering tie-breaking decisions when consensus can’t be reached.

After the spec has been drafted and reviewed by the 240 companies JSPA’s which have signed it is posted for public review and comment. Once those comments are reviewed and necessary changes are made, the draft is posted. Then the hard work begins – to produce a reference implementation and compatibility tests. When finalized, these are also posted.

That’s the Java Community Process in a nutshell. Since the process was introduced, 41 requests have been submitted to augment the platform; 36 have been approved. Innovation without disruption. Which leads me to wonder what stories of hardships you’ll have to share with your kids….