JavaScript, Not Java Script

A few months back, we predicted that at some point, somebody would have to play the heavy with Ajax standards. You had the makings of another Java-style scenario: the rest of the world coalescing around the OpenAjax Alliance, with Microsoft remaining the prime holdout.

Well maybe we were wrong.

On this go round, JavaScript didn’t follow the Java script. Founded in a spate of idealism, OpenAjax has operated on the proposition that you attract more flies with honey. And so yesterday, they announced that Microsoft joined the group.

What made OpenAjax palatable to Microsoft is what they aren’t doing. For instance, while OpenAjax is dealing with IDEs, it’s not creating them. While it’s pursuing interoperability, it says it’s not developing standards.

We’ll say that they’re not developing formal standards. Because, when you’re trying to figure out a way for the couple hundred (and counting) Ajax frameworks and tools out there to some how handshake, well, you’ve got to come up with something that they all understand. We’d call it standards lite.

So, as they figure out how to let different IDEs mix and match Ajax components from different sources, somebody’s got to define a standard means of expressing metadata so Ajax widgets can be identified. And, when you’re mashing up web apps on the fly at run time, you’d better have some sort of traffic cop mechanism to ensure that different Ajax controls don’t grab the same screen real estate at the same time. So that’s where the OpenAjax’s Hub project comes in.

What’s interesting is that OpenAjax has managed to remain almost under the radar, as if they were ducking to avoid getting spotted by the attorneys. The guy heading the group is simply the head of the steering committee. He’s not a CEO, president, or executive director, and he still spends three quarters of his time for his day job. He even hope that once the group has “done” its work, that it will simply vanish.

Perhaps all this informality shouldn’t be surprising because everything about Ajax, from the technology to the marketplace and community, remains pretty informal. Nobody planned for Ajax, and to this day, nobody owns the underlying technologies. You’ve got JavaScript, Dynamic HTML, XML, and HTTP, each of which was intended as basic building blocks of the Internet.

But under the radar, a bunch of developers figured out that you could kluge rich clients out of web browsers with these technologies. Maybe Adobe, IBM, and Microsoft had other plans. But once a cowboy developer gave the programming style a name, and Google put it on the map, vendors had to backtrack themselves to serve a budding community that was turning into a market in spite of them.

In all likelihood, the fact that Ajax caught vendors with their trousers down probably helped lower their defenses. More importantly, with the realization that the true money to be made would come from harnessing the way that these new Ajax-style dynamic web technologies could generate instant, limited shelf-life apps, why bother arguing over widgets?

Eclipse Eclipsed?

The origins of Eclipse are almost comical. Five years ago, a dispute between IBM Corp and the Java Community Process (JCP) over a bunch of measly GUI widgets or controls spawned a major schism that continues to divide the Java tools community to this day.

Obviously that was all but an excuse. IBM chafed under Sun’s dominance of the Java Community Process (JCP) and wanted to create a new center of gravity. It seized on perceptions that the JCP’s mission was growing too diffuse and its processes too bureaucratic.

Exhibit One: The complexity of the original Enterprise Java Beans (EJB) spec reflected a creature that could only have been designed by committee — one that was so busy listening to itself that it lost touch with the developer community it was addressing.

Five years on, Eclipse has become the Java world’s de facto response to Microsoft Visual Studio. As for EJBs, their complexity spawned Spring, Hibernate, and a slew of kinder, gentler open source alternatives, which in turn drove the JCP to simplify its act.

At its annual conference last week, Eclipse patted itself on the back to show how far it’s come. Over the past three years, membership has tripled while projects have quadrupled. More importantly, while we used to associate Eclipse with its IDE, today it is also developing tooling for SOAs (Service-Oriented Architectures), Application Lifecycle Management (ALM), embedded devices, and more recently, dual rich client paths encompassing conventional operating systems plus a new initiative for Ajax.

Eclipse’s scope creep provides evidence, not only that IBM has accomplished its mission of moving the axis of influence away from the JCP, but that the organization might risk finding itself spread too thin just like the JCP.

Oracle’s announcement that it wants to turn TopLink, a 10-year old product that become its implementation of the Java Persistence API (of Java EE 5), over to Eclipse, is proof that the organization is now planting its stake in run time, in addition to development time. Ironically, that point is reinforced by the fact that Oracle is not moving its JDeveloper Java IDE to Eclipse.

Colleague Dana Gardner characterized this as a watershed that Eclipse was eclipsing the JCP. “It seems to me that this is indication of a defection,” he blogged, noting that Oracle originally used Sun’s Glassfish Java appserver open source project as the host for TopLink development. “If Oracle is now a top-tier member of Eclipse (as it has now become), then the role and influence of Java — as a technology set and community — must be fast waning,” he concluded.

So with Eclipse spreading its wings, we thought it logical to ask Ian Skerrett, who heads marketing for Eclipse, as to what exactly is Eclipse’s mission, and where it would draw the line (every organization has draw a boundary someplace). He defined it as the development of a plug-in model and said that the IDE just happened to present the first opportunity for proving the concept. But he drew a blank as to what areas Eclipse would not traipse.

Nonetheless, we’re sensing that Eclipse is starting to hit a few walls.

For instance, with Eclipse member Red Hat’s JBoss announcement last week that it would host the Exadel web and Ajax client development tools on its own site indicates that the open source community does not necessarily want Eclipse to become all things Java (Red Hat’s rationale was over licensing: it uses GPL, rather than the Apache license that’s commonplace at Eclipse).

Or as Daryl Taft reported last week, the same might be true for Ajax, where some Eclipse members are leery about having the group steer IDE development. As we’ve noted previously, the Ajax world is much like a herd of cats and may resist a preemptory move from above. For now, Eclipse is hedging its bets, with executive director Mike Milinkovich himself also serving on the steering committee of the adjoining OpenAjax Alliance.

Eclipse was founded at least in part as response to the JCP’s lack of focus. Yet, if Eclipse continues on the path of being all plug-ins to all people, it risks the same fate.

BI Squeeze

Just about the only thing surprising about Oracle’s acquisition of BI (business intelligence) and performance management vendor Hyperion last week was, what took them so long, and why didn’t IBM buy them first?

First, we’ll deal with Oracle. You know they’re not terribly shy about buying companies. Do the math. With Hyperion being number 30 over the past three years, on average, Oracle has been swallowing up companies on the average of one every five weeks or so. Maybe you might even recall that Hyperion wasn’t Oracle’s first BI acquisition. Way back when (1996 to be exact), it snapped up the IRI Express OLAP database around the same time that Business Objects and Cognos were making their splash.

You’d think that a $3.3 billion deal for a product set that largely complements what Oracle already offers would have been child’s play compared to forking out $11 billion for a hostile run at PeopleSoft.

OK there’s some overlap, in that PeopleSoft and Siebel have their own analytics. In a company that’s agglomerated so many product lines as Oracle, any acquisition is bound to have some overlap someplace.

We thought this was inevitable because BI has little reason to remain a standalone market.

BI emerged about a decade ago, largely as a database and reporting tools market. In fact it was first called “data warehousing.” Today, OLAP is just another face of the database. Besides Oracle, Microsoft has bundled an OLAP option with SQL Server.

Consequently, with the OLAP side of BI having become an extension of the database market, the BI market shifted towards reporting and analytic tools. That was fine when BI was emerging, but the sweet spot of the market wants applications, not tools. Increasingly, the BI folks have been emphasizing performance management applications, which have placed them between a rock and a hard place: the ERP folks on one side, and the data integration middleware platforms on the other.

If your organization is heavily invested in ERP, BI/performance management becomes a natural extension of the core enterprise system. Conversely, if no single application predominates your environment, or if your business is predominately run with homegrown apps, your reliance is on your data integration vendor. Either way, there’s little value add from having another vendor providing the analytics, and therefore, less and less reason for BI to remain a standalone market.

We haven’t forgotten about IBM. For the better part of the past decade, they’ve been bundling Hyperion’s own Essbase as DB2 OLAP Server. So you’re probably asking why didn’t IBM just buy them a decade ago?

OK, you can say that IBM is not in the applications business, except that they already have products like Master Data Management that, not only border on applications, but are very synergistic with BI. And you could say that IBM probably had a pretty cheap, low risk deal reselling Hyperion Essbase. Obviously with Oracle in the picture, that won’t be the case anymore.

Consequently, the one thing that would surprise us is if IBM doesn’t buy Business Objects or Cognos.