Intelligent Enterprise

After starting a third review in a row of a software development environment based on the Eclipse platform (PyDev, Adobe Flex 3, and Nexaweb Enterprise Suite), something a friend said to me a year or two ago rang true: "There will be two major players in development software: Microsoft and its tools and Eclipse and its tools." A cynic might say, "Good for Eclipse, not bad at all for a camel built by a committee," but to make a point, cynics are often unfair and inaccurate.

For the background: The Eclipse Project was launched in late 2001 when IBM donated the source code from its world-class WebSphere Studio (an IDE worth about $40 million) and formed the Eclipse Consortium, which is now the Eclipse Foundation, a non-profit organization that acts as the steward of the Eclipse community. The core of Eclipse is an open source Java-built software development platform (Java Runtime Environment required), but the Eclipse IDE is by no means restricted to Java. Among current supported languages are: C, C++, ActionScript, Python, COBOL, and PHP. Although all Eclipse projects are open-source, parts of it may incorporate proprietary or semi-proprietary products.

The list of software vendors involved with Eclipse, and in many cases basing whole products on the Eclipse platform, reads like a who's who: IBM, BEA, Adobe, Borland, Oracle, Nokia, SAP, Sybase, Zend, Iona, AMD, Intel, Novell, Nexaweb, QNX, Red Hat… and sixty more. Missing name(s)? Need one ask?

For vendors, Eclipse is a nice step ladder; it may not get all the way to the top, but it's a good start. It's free, it's solid and it's familiar. So why re-invent the wheel?

It's still entirely possible to use the Eclipse platform as a base and have so many additions (plug-ins) that it doesn't work or feel like Eclipse any more. So, if a company wants to distinguish itself from the competition, using Eclipse doesn't rule that out. On the other hand, because Eclipse is now "standard," keeping most or much of the original IDE, for example, might help with the learning curve and user support. Vendors who use Eclipse are required to contribute to the Eclipse community, and many do with substantial additions to the ongoing projects.

The many pieces of the Eclipse platform come from many developers (called committers in Eclipsese). For some, the resulting diversity and flexibility is an attractor. For others, the lack of consistency and the almost inevitable discontinuities (internal bugs, complexity leading to a long learning curve) are a detractor. It's not really a binary situation, but this is the flavor of opinion.

I've been poking around for the opinion of Eclipse in IT shops. I wondered in big shops if there is an Eclipse specialist? That would be someone who can work with Eclipse for the benefit of the shop — stuff such as tech support, local modifications and plug-in review. The answer, at least in my highly informal survey, is that most shops use Eclipse with a specific plug-in configuration (by language, vendor, type of programming, whatever) and may have people expert in this, but not in Eclipse in general.

That may account for why so few managers and developers seem to be aware of the spread of Eclipse throughout the organization. Is this a problem? More like missed opportunities, for example, not knowing the range of things available through Eclipse, not coordinating training or support, and not exploring ways to make corporate-specific modifications. Maybe it's time to make your own quick survey.