Oracle, in the post-Sun acquisition era, can be relied upon to sustain the long-term development and independence of Java -- up to a point. It has to. Its next-generation Fusion applications will be written in Java. With that said, however, Oracle is also capable of foreshortening Java's future in ways it may or may not understand.

Oracle will support open source procedures and goals as long as they are aligned with Oracle's business interests. If they're not, it will do something else, including walk on those previously honored procedures and goals. In the past, I might have contrasted this approach with that of IBM, which adopted an early and principled approach to supporting open source code. It was an early adopter, for example, of the Apache Web Server in its own product line. But I can't say that today. In the long run, I think IBM's approach is not so different from Oracle's. It will support open source as long as it is in its strategic interest to do so. When its interest changes, it does something different.

This leads me to the involuntary conclusion that open source code and large proprietary companies are contrary and incompatible things; no matter how much the one wants to support the other, they are at odds and the one inevitably undermines the other. Let's come back to that.

Let me say right off the bat that Oracle has done many things right with Java. It inherited a divided and stalemated Java Community Process that Sun, preoccupied with survival, couldn't move off of its stall point. I know some Java advocates felt the language had become too unwieldy. And there was a long festering dispute with the Apache Software Foundation over whether its Harmony implementation of the Java spec could be certified as 100% Java.

Sun didn't want to allow such a development, for competitive reasons. Allowing Apache's work to be certified would have generated a new round of Java competitors that Sun would have no means of licensing or controlling. Under the Apache license, they would nevertheless still bear Java's Good Housekeeping seal of approval.

Logical Outcome

Oracle argued on behalf of the Apache position prior to its acquisition of Sun, knowing that a second, independent Java in the marketplace was a guarantee of Sun's good behavior. IBM helped found, funded, and contributed heavily to the Apache Harmony project for the same reason. But once it gained ownership of Java, Oracle changed its mind. What's more, it's now clear it also skillfully coaxed IBM into changing its mind as well. The two are now positioned as co-guardians of the one true Java, embodied in the OpenJDK, held firmly under Oracle's control.

That might seem like a logical outcome, but it was by no means assured. To IBM, Sun had been mercurial enough, with constant tension between the two over a technology they both relied upon. Imagine IBM's discomfort as its own negotiations to acquire Sun failed in the spring of 2009 and Oracle stepped to the fore. If Sun had been a difficult Java partner, Oracle was an unpredictable, 500-pound gorilla with whom a fight might break out at any time.

IBM is a licensed Java user, but that meant at some point, Oracle would be in a position to review its renewal. If IBM was crowding Oracle too hard in a favorite market, say Java middleware where they compete head to head, Oracle could decline to renew its license. With no license, a Java vendor doesn't have access to the thousands of software tests that establish the 100% Java compatibility of its product. IBM could produce reliable Java without access to the tests, but without certification a Java product could be labeled by an aggressive competitor as "unproven" or even "incompatible."