Eclipse Likely Won’t Suffer the Same Fate as Java

Colleague and frequent SOA Insights Edition contributor Tony Baer at OnStrategies has a nice context analysis of recent Eclipse Foundation news, and he wonders if Eclipse may be extending itself too thinly. He says this would follow the mistakes of the waning role of the Java Community Process (JCP).

I think Tony’s analysis is spot-on, as usual, but would add that mission-creep alone did not lead major vendor contributors (IBM, BEA, Oracle, Borland, HP, etc.) away from Sun Microsystem’s schizophrenic oversight of Java and its development and governance (they named their commercial stack the “Java Enterprise System,” for crissakes!).

No, it was Sun’s inability to allow for sufficiently open and inclusive governance over Java (and some onerous taxes … err, licensing deals) that caused the eclipse of the Java tools and IDE action, which is now leading to an even larger purview for Eclipse at the ultimate expense of Java’s future role.

Bad Bets

Buying NetBeans did not counter or blunt the Eclipse IDE framework dominance trend, another costly acquisition bet for Sun. The current major open source SOA activity, by the way, is under Apache and Eclipse, among others, not Java. The SeeBeyond acquisition did not jettison Sun and Java into the SOA community leadership role, at least not yet. Java’s fate is being sealed.

Granted, when it refused to let go of Java, Sun has slid off a cliff into a hard patch that it is only now bootstrapping itself out of (thanks to x86 hardware and parallelism) when it resisted fully independent standardization of Java.

IBM, among others, had been calling for a neutral standards oversight of Java since 1997. Yet Sun entered, as many companies do, a bunker mentality and sought to monetize what it perceived as a tremendous service that it had provided IT-dom through the emergence and success of Java, as a tool, framework, stack and reference platform environment. Hubris, my friends.

Problem was that Sun was increasingly seeking such monetization by competing with those in the Java development and contributions business, those who had been making large contributions of talent and code to Java’s betterment.

Would Java have become Java without IBM’s contributions and market clout? No way. Moreover, Sun extracted fees for managing Java for the community, and also sought to gain advantageous positions for its commercial products via its Java role (and it still didn’t work!).

The Consequences

The outcomes and missteps only made Sun more livid — that its very competitors were capitalizing on Java more than Sun could, try as it may.

Sun’s leadership had witnessed Java-based application server startups go public or become acquired, making many people rich and creating a robust, competitive Java runtime market — a market that Sun had every opportunity to play in and win, too. Sun made acquisition errors, but it was how they managed those acquisitions as much as the technology profiles of the code that determined their fate in the market.

Then Sun got the open source bug, big time. Everything would go open source, in one form or another. It was license hell, but it had to be done — for the sake of Java purity, by golly.

In other words, if Sun can’t make money at Java (other than via license fees and lawsuit settlements against Microsoft) then no one else would either. That also tended to influence the Java community to further embrace Eclipse, Apache and GPL, and to look to the JCP as in a mere maintenance and updates committee role, not where the next levels of technical innovation (and the next levels of using open source for fun and profit) would emerge.

Sky’s the Limit

Eclipse benefitted wildly. How high it can go is now a matter of fascination. I told the Eclipse leadership last week that they were not giving the success of Eclipse enough credit. I called it “short-shrift,” and they said they were being “modest.” If only Sun had pursued modesty for Java oversight, eh? Perhaps Sun should move its headquarters to Ottawa?

Now, don’t get me wrong, the JCP (increasingly going to newer GPL licenses) still fulfills its role beautifully. It performs a mostly non-commercial oversight function of an essential legacy environment.

Make your fixes, contributions and updates — but take your new code contributions elsewhere. Java plus Eclipse plus Apache plus GPL Linux is what makes today’s savvy enterprises, SaaS (Software-as-a-Service) vendors, service providers and internal development powerhouses (like Google) what they are: Lean, mean, agile and low-cost infrastructure innovation machines.

So, fine, Sun just could not let Java go: A history lesson at the Harvard Business School. Sun perhaps overlooked that huge portions of what made Java successful — with a uniting force around the common enmity of Microsoft — was something that would be eagerly repeated, not a flash in the pan, not a unique lever in the business (like Windows).

Java proved the point that community conduct of complex IT environments was possible, even necessary. What Eclipse has proven is that such a benefit can be fairly easily and extremely rapidly repeated. Even Microsoft took the lesson, albeit in a proprietary fashion, with .NET/CLR/C#.

Java was a great service to humanity, it just wasn’t a business — or a bunker.