Aehso’s Output

A while back I wrote that perhaps more needs to be done to coordinate the efforts of the various top level projects and the conversation seems to be evolving. Some of the subsequent discussion raised an interesting question - what is the relative importance of producing exemplary tools versus extensible frameworks? The difficulty, it seems, is in striking a balance in developing both.

A quick search (in the Eclipse Bylaws and Development Process) produces the definition of exemplary tools. It is worth reproducing here:

Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself.

To verify and illustrate the appropriate use of frameworks.

Ed thinks the tools are the basis of the Eclipse phenomenon and I fully agree that JDT was the primary driver for the phenomenal rate of adoption of the Eclipse platform. JDT served as the exemplary tool for Platform and subsequently, under the guises of Eclipse.org, it is evolving as both a best of breed tool in its own right and also as a domain specific framework for reuse by other Java centric projects. The JDT exemplary tools alone are not enough to facilitate the requirements of these downstream ‘consumer’ projects.

(It is also worth remembering that the bulk of the Platform and JDT/Team was created by one organization - IBM’s OTI Labs.  Eclipse.org is a very different organization - an open meritocracy, backed by many commercial interests running many top level projects that are tackling more varied and diverse problem domains.)

Then there are the two other types of consumers that Eclipse.org also services:

• Adapters. These comanies consume projects developed under the auspices of Eclipse.org and
  build derived tools outside of the Eclipse.org umbrella. Adapters consume extension points and also some exemplary tools (e.g. the WSDL editor in WTP). But for the most part adapters are building on Eclipse because of the powerfully integrated frameworks it supplies.
• Users. Those millions of downloads don’t come from nowhere! Users are interested only in taking the output of one or more Eclipse.org projects (or derived products) and consuming them as-is. For example a user might choose to use WTP instead of a commercial Eclipse based IDE like Rational Application Developer or one might choose to use TPTP instead of Rational Functional Tester. These users are mostly interested in free tools - derived commercial tools usually provide more function but at a price.

The danger, in terms of under-investment in framework integration, is faced by the downstream projects, adapters and users. As they consume more top level Eclipse.org projects into a single product they might find themselves inheriting frameworks and/or tools that either do not integrate at all or worse duplicate core functionality. In this case, all the exemplary tooling in the world won’t compensate for the inability to get disparate frameworks from different projects to play well together.

So we can hope this will never happen but with the Eclipse.org project count expanding the risks are escalating and as Murphy’s Law states, “If anything can go wrong, it will”. A neutral Eclipse.org mediation facility may be the only way to ensure that top level projects - that are managed by different concerns that compete on a commercial level - produce frameworks that meet the high standard set by the original Platform/JDT contributions and integrate in a consistent fashion into a larger Eclipse “Platform” (hmm, is there a better term for that?)

aehso eclipse, process