Schwartz: How Sun's moons orbit the 'open' debate
Summary
Topics
Sun COO and president Jonathan Schwartz has issued a blog entry that rivals the interrelated multi-plot lines of TV series like Seinfeld and Friends. In one fell swoop, Schwartz gives readers a dose of "interoperable and open ain't the same thing," a defense of Sun's wagon-circling around the Java certification process (to counteract pressure to open source Java), a gratuitous plug for Sun's ongoing investments into Solaris (including mention of an IBM Power-compatible version), a swipe at IBM's AIX, a twist of the knife into the lack of compatibility between Linux distributions from Red Hat and SuSE, and a recommendation to developers to do all their development in Java. Hardly anything that matters in the computer business escapes Schwartz's scathing remarks.
At the top level, Schwartz attempts to persuade his audience to think of proprietary APIs and du jure standard APIs as two very different approaches to the idea of "open." Whereas the former simply allows for vendor-endorsed interoperability, Schwartz argues that the latter goes one step further by greasing the wheels of substitution. The differences are very nuanced.
Proprietary APIs, such as those found in Windows, can also grease the wheels of substitution-but it's a one way street. For example, you should be able to easily replace video cards, applications, or even an entire computer to run Windows. But you can't replace Windows with another OS if you expect to continue to run your existing applications. If OS vendors could clone the Windows APIs without violating Microsoft's intellectual property rights (in other words, if the Windows APIs were an open standard), then, technically, clones of Windows could exist and swapping one for the other would work as long as all the third-party hardware and software developers (collectively known as ISHVs) wrote to those APIs. There have been attempts at knocking off Windows, but none has met with great success.
Schwartz would love to open source Java if he could. But, if the result is the sort of forking in compatibility that's exemplified by the difference between two open source poster children (Red Hat and SuSE Linux), he worries that the results will be an unpredictable target for Java developers, and lack of the "substitution effect."
When it comes to the "substitution effect" -- an approach to IT (see "Standards can put you in control") that puts IT departments (as opposed to vendors) in charge of the cost, performance, security, and stability of their IT -- I'm in complete agreement with Schwartz. The downside of avoiding the substitution effect is exemplified by the control that Microsoft has historically exercised over our budgets. (See "Who gave Microsoft control of your IT costs? You did.") Forgoing the substitution effect strips IT shops of the leverage they deserve to have over their IT suppliers. Why give it away voluntarily?
However, I disagree with Schwartz's implication that Java is an open standard. Schwartz is careful not to come right out and say "Java is an open standard." He knows better than that. Both the press and the licensors of other "open" technologies (open for interoperability, that is) would have a field day. But, given that Sun enforces inter-implementation compatibility (the clone effect) with its test kits and certification processes that in turn produces the substitution effect, Java is perhaps the closest thing to a licensed technology we have that looks, tastes, and smells like an open standard.
Like other de jure open standards, such as those from the World Wide Web Consortium, the multi-vendor process (known in the Java world as the Java Community Process) of arriving at the various Java specifications is also very open-standards-like. Whereas anybody is free to create a product that supports a W3C standard and then claim it supports that standard (a process that Schwartz calls "flag waving"), the same isn't exactly true of Java. Just look at what open source implementations of Java from the Apache Software Foundation, JBoss, and JOnAS have had to go through to "wave the flag." In contrast, neither the Apache Software Foundation nor any other HTTP server developer has to ask anyone if it can wave the W3C HTML standard flag.
That said, I do agree with Schwartz on his final point. Barring a need for simple scripting that could be satisfied by PHP, Perl, or Python, of the development choices that put you in control and that leave as many of your options as open as possible, Java is the way to go.
You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check my blog Between the Lines or my archives.
Talkback - Tell Us What You Think
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Facebook Activity
