The continuing growth of the Eclipse community raises some interesting questions, Can Eclipse offer developers a portable alternative to Windows? A means of delivering desktop applications without having to write to either the Win32 API or .NET? I wonder. But Eclipse and the sprawling Eclipse ecosystem are hardly the only efforts underway to break application developers dependence on Windows platform specific, single vendor controlled interfaces and protocols. The Java phenomenon has resulted in an explosion of portable run time engines and libraries. With the surging importance of Internet protocols, that are now finding their way into every aspect of software and information systems development, there is also an increased awareness of how important Open Standards, Open XML Technologies, and the efforts of Open Source communities are to the future of computing.
But all this got me to wondering. The anti trust case against Microsoft was, after all, an law enforcement action in response to the extreme efforts by Microsoft to stop Netscape and Java from doing the unthinkable - that of displacing the Win32 API, and replacing it with an API developers could write to that was not dependent on Windows. The thought that applications and information system developers would be writing Internet ready applications entirely outside the control of Microsoft, was enough to drive the Redmond giant over the edge.
That was then. Now, in the distant aftermath of the toothless anti trust settlement, the question becomes one of what lengths Microsoft will go to to crush these new threats to the Win32 API franchise. It seems to me that the battleground has moved from that of the browser wars, to that of the desktop, and how that desktop productivity environment inter operates with server side information systems.
Eclipse differs from Sun's Java desktop - NetBeans approach in many ways. The most significant of which seems to be the Eclipse SWT native widget set. Another difference is that Eclipse ships with volumes of rich open source class libraries. There's also the difference between IBM's WorkPlace Desktop, and Sun's Java Desktop. When IBM combines WorkPlace with Eclipse, they will have the single most potent portable application environment known. One of the things i see coming is a showdown between Microsoft's integrated stack of desktop applications, developer tools, and suite of servers, and, IBM's WorkPlace Stack of applications and developer tools (Eclipse) that are integrated with WebSphere, Lotus Notes, and DB2 server side implementations.
Microsoft defines “rich client” as a desktop loaded with a boxed entanglement of interdependencies linking MS Office System to Visual.NET and the many collaborative horns of the Windows XP Server Suites. Is the Eclipse “rich-client” model just a Java run time with rich class libraries and native widget sets nearby? Or is it something that will rouse the open source components in IBM's WorkPlace in ways that will truly provide an alternative to the MS Office System desktop?
The WorkPlace - Eclipse combination can provide an alternative to the Windows desktop, making for an integrated and inter operable environment that truly performs for computational consumers. WorkPlace fulfills the productivity environment part of the equation, able to replace MS Office entirely, but no one knows just how far reaching IBM's plans are.
The one thing about the combination of Eclipse and WorkPlace that is unique is that we see the cornerstone taking shape for a portable application environment.
Instead of the battle royal we've been bracing for, the one between J2EE and .NET frameworks, we can now see clearly that the portable runtime engine wars have evolved into something much larger. The portable application environment. Two key concepts that have long defined the computational box that entraps us all are being diminished here - the importance of the underlying operating system, and, the integrated stack model that drives the frameworks (J2EE and .NET). Combine the emerging Eclipse developer layer with IBM's portable WorkPlace environment, and you have a very robust target developers can reliably write too. It's a target without the platform specific baggage that has long plagued application developers. Yet, it's able to provide the same elements of accelerated development promised by platform specific integrated stack models. And it does so in a way that is consistent with the open interoperability model of open standards, open interfaces, open communications and messaging protocols, open XML technologies, and open class libraries (hello Sun!).
While it may seem that portable run time engines led the way, riding above the distro layer, i think the historic moment came when Netscape's Marc Andressen referred to the many versions (distros) of Windows as “just a bag of API's to write to”, and then went on to prove it could be done. The portable application became the cross platform distribution channel for both Java and, portal based web applications. Netscape's XPFE web application model is still cooking (XPCOM and XUL), but the challenge to any community in providing a portable rich client environment are staggering. This is going to be a cross community effort, or, the effort of a cross community assembler such as demonstrated by IBM's WorkPlace or Sun's Java Desktop. The assemblers have a much better grip on this space than the core communities who are just now getting about the business of coordinating their efforts (the recent meeting between Mozilla and GNOME as an example). But that's not to say the assemblers themselves have problems keeping their proprietary heritage in check. Red Hat is forever under suspicion. Sadly Sun choose to release the Java Desktop bolted to their chosen Linux distro, instead of unleashing it as a portable application environment. The good news is that it doesn't look as though IBM will make the same mistake with WorkPlace. And no doubt Ian Murdock of Progeny fame is watching the portable application environment space too. His Dell model of made to order assembly could move to providing a distro independent application environment that challenges both WorkPlace and the Java Desktop in ways that unleash extraordinary dynamics.
The ongoing activities and synergies between core application communities and frameworks communities are for the most part beneath the radar. But they deserve mention in any discussion about Eclipse. Distribution to the desktop is critical. But so is the way in which the environment is managed and maintained. Microsoft's iron fisted control over interdependencies, protocols, libraries, components, interfaces and methods insures that the integrated stack environment will be managed and maintained. It also insures that all the profitable opportunities belong to Redmond. So MONO is a much safer target to write to than .NET because it is open source, and “open opportunity”. Developers still have access to the Windows XP platform without having to disrupt or re engineer the end users environment, but their not completely hostage to the vagaries of Chairman Bill's permission based interoperability model.
The Python community also looms large. Like MONO, they don't have as yet a desktop distribution method that can compare to Mozilla - one where the open application environment is put down as part of the browser install, managed and maintained by the community rather than rogue developers and hapless end users. This is certain to change once the Chandler project reaches their 1.0 release. Chandler promises to not only deliver (and maintain) the Python environment, wrapped in the interface of a much needed cross platform PiM/Project Management application, but also an underlying Sleepycat XML database resource management system that can be used by other applications and services.
Someday some smart guy is going to bundle OpenOffice.org with NetBeans (and all those wonderfully rich J2SE class libraries), and similarly deliver a rich Java based environment to the desktop that developers can reliably target. The key again being rich client side resources managed and maintained by core communities so that dependencies and version controls avoid the possible anarchy of rogue developers and hapless end users having to carry the responsibilities of maintaining the environment.
Hopefully at JavaONE IBM will fully disclose what they intend to do with WorkPlace and Eclipse. If distributors, developers, and adventurous end users can put down a single rich client application environment that works similarly across many platforms, there might be a chance of reaching the kind of critical mass needed to pry loose the iron grip of Redmond. But so far IBM has yet to do the kind of things necessary to signal the world that they've thrown down the gauntlet and are serious about backing a truly open portable application environment. Things like returning their WorkPlace improvements to the core application communities - like OpenOffice.org. I wonder what they're waiting for? The Eclipse project was a boon to IBM's WebSphere business and services model. Why not wreck havoc on the desktop using the same play book? Time will tell, but hard not to notice that pieces are falling into place. Maybe in ways not planned.
