IT Directions

This is the second entry in a blog series looking at major open source projects of which every enterprise should be aware. The series will conclude with a discussion of open source adoption issues, providing a quick and simple way to understand when and where to avoid open source.
The subject of this blog entry is the extraordinary software framework known as the Eclipse Platform. Originally developed in-house by IBM, Eclipse was open sourced in 2001 via the creation of a supervisory body known as the Eclipse Foundation, a not-for-profit consortium that now boasts 115 member organizations. IBM still put a lot of money and development time into Eclipse, but for years they have been supported in this effort by some of the largest companies in the world.
So what is Eclipse? In a nutshell, the first software product with the potential to remove Microsoft’s monopoly in desktop computing.
IBM set out in the late 90’s to create a common software framework to underpin all their Java-based middleware products. Further, the framework had to be extensible via plugin modules. They wanted to establish a standard user interface not only for their own product range, but also for any custom applications or supporting third party tools created to go with products in that range.
To say IBM succeeded would be an understatement. The intellectual effort that went into Eclipse was first-class, with direction from such luminaries as Grady Booch, and taking inspiration from the pattern-based approach to software design that is only now becoming standard practice. There are already many hundreds of plugin modules for Eclipse (open source and otherwise), and the framework is becoming the de facto standard software development environment, not only in the Java world but for other languages too - especially as Eclipse runs on most modern operating systems, in each case with a native look-and-feel. The writing is probably on the wall for competing, non-specialized “IDEs” for software development - even those few (like IntelliJ Idea) that have managed to retain a loyal user base will inevitably find it eroded as the massive vendor support behind Eclipse and the growing number of plugins makes it harder and harder to compete.
So why does this threaten Microsoft? Because of something called the Rich Client Platform.
Eclipse was originally developed as a tools framework - you were supposed to use it to create applications for use by IT folk, for example to write software or configure application servers. It took a surprisingly long time to realize that there was no reason to restrict Eclipse in this way. You can use Eclipse to write any kind of application! And doing so makes a lot of sense. Eclipse has a very well-architected plugin model that means you can leverage the framework to get off the ground very quickly with a new application, simply by building it as an Eclipse plugin. And once you have done so, your own application is immediately compatible with all the hundreds of other Eclipse plugins out there. So with release 3, Eclipse acquired a set of standard features (known as the Rich Client Platform) that make it easy to create any kind of standalone application in this way.
Now let’s look back at the history of Microsoft. DOS may have been the company’s original means of establishing dominance, but in the last 10 years it has retained it because of something else: applications. In particular, the ubiquity of the Office suite has meant that organizations standardized on Windows in order that their documents would be compatible with those from other sources. But that is only part of the story. For a long time now, it has been almost inconceivable for a software vendor to release a desktop product that did not run on Windows. Hence, by using Windows you were guaranteed that all the software you might want at some time to use would in fact be available to you.
Companies like Google realize this very well, which is why they snapped up the Web-based word processor Writely only shortly after its launch. The more people that use a Web browser as an application platform, the less the importance of choosing Windows for your desktop operating system as opposed to (say) Linux. But whatever the “Web 2.0″ evangelists may say, the Web browser is never going to be fully-capable, or even durable, as a platform for building applications. The software development model (AJAX) is:

1. Built on sand - Javascript is a scripting language, that was never designed to take the strain of heavyweight software.
2. Badly architected - not only is AJAX a kludge on top of HTTP right from the start, but it tends to lead to poor design, breaking the Model 2 MVC practices that were finally becoming mainstream. This is changing as better practices start to appear for AJAX, but there is no layering implicit in AJAX itself, so there will always be the temptation to write poor code.
3. Server- and browser-dependent - you cannot run an AJAX application without connecting to the server in question using an appropriately capable browser. What about applications that need to run offline and with more choice of device?

AJAX is unlikely ever to seriously challenge Windows as an application platform - but Eclipse may. Unlike AJAX, Eclipse is founded on an enterprise strength language (Java), based on a soundly architected plugin model, and independent of almost any network and device restrictions. As more and more software vendors port legacy products to Eclipse, and release new products in the form of Eclipse plugins, the importance of choosing Windows for your desktop operating system can only erode, a trend which will be accelerated by the recent emergence of Eclipse sub-projects that provide system-level features such as single sign-on (Higgins) and communications (ECF). The tipping point will probably come when someone releases word processing and spreadsheet Eclipse plugins that can (like Writely) use the emerging open standard for document format as well as the document formats for Microsoft Office.
TAKE AWAY
If you are considering development or maintenance of any desktop software application, whether for in-house use or supply to others, look hard at Eclipse before deciding on a framework. It may well be sensible to build the application as, or port it to, a set of Eclipse plugins. Just so that you know I practice what I preach, we are building our own next generation toolset for collaborative work using Eclipse - and have found it to be very productive, especially the embedded facilities for generating both business logic and diagramming code.
In fact, the same consideration should be given even to server-side applications. Eclipse can run “headless” - without an interactive user interface - and by developing your application as Eclipse plugins you gain access to all the rich functionality of the framework and its existing plugins (many of which are open source). For some reason, the Eclipse Foundation to date have not highlighted this capability of Eclipse, but no doubt they will realize in due course what an opportunity they have been missing and cater to it via a “Rich Server Platform” feature.
Finally (and this is where we came in), the rise of Eclipse has serious implications for any enterprise considering future desktop strategy. There may be less obstacles than you thought to replacing your desktop operating systems with (for example) a Linux variant. Look at what is available now in Eclipse, what is coming, and consider again how much money you will really need to spend on Microsoft licenses in the next few years. Such considerations have a direct impact not only on the desktop machines and licenses you purchase, but on your development strategy - the need for .NET capability along with J2EE may be less than you thought, for example.
Tune in again to this blog for a discussion of another major open source project with the potential to change the enterprise computing landscape. In the next entry I will pick up again on the discussion in the last blog series, BPM Futures, and show how open source tools can be used to implement a forward-thinking BPM strategy.