Sun is worried about compatibility in a world where Java is open source. I can’t say I blame them, and I say this as someone who spends a majority of his time thinking about compatibility in the Linux world, where we’ve managed to hold it together but still have a lot of work to do to match the relative consistency of the Microsoft alternatives (Windows and .NET, among others). After all, a platform is useless if there’s not a single, standard way for developers to target it.
Question is: Does open source inherently lead to compatibility problems? Hardly. How many incompatible versions of, say, Apache are there? Or the Ps of the LAMP stack (Perl, PHP, Python)? Or MySQL? GNOME? KDE? BIND? CUPS? The only reason “Linux” and compatibility often come up in the same breath is because the term is used to describe so many different things. Yes, “Linux” has compatibility issues if you’re comparing Red Hat, SUSE, and Debian, but the actual “Linux” used by each of these “Linuxes” (that is, the Linux kernel) have few if any compatibility issues. It’s more the bits around the edges, like slightly different versions of core components with slightly different ABIs or APIs, not to mention the independently developed subsystems for configuration etc., that lead to the compatibility issues. If anything, the fact that the various Linux distributions share so many of the same open source components makes them far more compatible than the various implementations of UNIX ever were.
Ironically, then, Java looks a whole lot more fragmented on its current trajectory as the various open source efforts (Apache Harmony, GCJ, GNU Classpath, etc.)—which exist only because the de facto standard implementation isn’t open source—mature and are more tightly integrated into the Linux distributions.
So, what lessons does Linux have to offer Sun as it contemplates the future of Java and, more to the point, how to open source it? First of all, far from being a surefire path to turning Java into a veritable tower of babel, open source could actually help promote compatibility in the Java world. For one thing, if Sun’s Java implementation was open source, history shows there would be no need for another implementation. Case in point: Remember the other Harmony project?
Secondly, what’s in a name? Absolutely everything. It’s entirely possible to open source Java without diluting the Java brand and the compatibility guarantees that brand promises. Most famously, this strategy has worked very well for Red Hat—Red Hat’s platform is open source, so you can fork it, but you can’t call the result “Red Hat”, which preserves the compatibility guarantee a successful platform requires.