> Correct. Without the requirements for TCKs and RIs for
> each JSR the JCP would become a free for all for all kinds
> of weird ideas and would quickly becomes useless or worse,
> a detrimental force to the platform.

When people talk about open-source Java, they often think of Java either as primarily a programming language or as a set of APIs (e.g., the servlet API), or maybe both.

Few developers think of Java as a platform, which actually sets it aside from other languages (C++, Ruby, Perl, etc), and other APIs (Apache API, Libc, etc).

One reason might be that most developers deal with Java as a language or a set of APIs. Few developers are involved in the deployment and maintenance of applications, or in crafting the IT strategy of their organizations. And fewer still are financially impacted by the operational costs of the overall IT department.

If you try to use Linux, for instance, as it is today on a desktop, you easily get a taste of what a "platform" means. For no user in their right mind would first download the kernel and build tools, build the kernel, then download a whole bunch of other source packages, etc., until you have the complete system up and running. Instead, you'd download a distro, pop a CD in the drive, and install Fedora or Mandrake or whatever. Those distros, in fact, are little "platforms," offering a full stack of useful stuff all the way from the kernel to the UI.

I'm a really long-time Linux user (well over 10 years), and I found out the hard way many times that it doesn't pay to deviate from such distros any more. For instance, I downloaded a vanilla kernel into my Fedora Core 4 system, and compiled it, etc., a few months ago. Things worked fine, until I wanted to use Fedora's upgrade capabilities - which now complained that it knew nothing about my kernel, and wanted me to download a standard Fedora kernel instead. I could have spent a couple of hours figuring out how to customize the Fedora updater—or just forget the whole customization thing and use the Fedora defaults.

This is also an issue now with larger Linux "stacks." For instance, Kim Polese's new company, Spike Source, sells entire tested and configured Linux stacks (Apache, PHP, and the whole kitchen sink). I think it makes sense, actually: If I'm the IT manager of a large company, would I rather have my employees fiddle with these things, hoping that all will work out, or would I just buy, say, the SpikeSource platform, and make the compatibility of that platform with other tools someone else's problem? Open-source does not have such compatibility requirements (yet?), but Spike does in their QA department, I imagine.

Of course, developers often are shielded from those decisions, and thus don't appreciate the value of being able to focus on just the code and design of an application, and to not have to worry whether those apps will run in certain environments.

There are many reasons why open-source by itself is not a guarantee of compatibility, nor should it be. More on that an another post.

The companies wanting to use and develop Java decided some time ago that they needed a mechanism to ensure compatibility, and the JCP is the vehicle for that. It's not perfect - but no one, to my knowledge, suggested a better alternative yet.