Friday, May 26, 2006

Callisto Webinar coming soon!

An interesting webinar, showing emergent functionality in Callisto using DTP and BIRT will be presented on June 5th (Friday). You can read more about this webinar, and others for Callisto, on Ian's blog.

The Device Driver Problem

DTP is facing a particular challenge, which I'll call the "device driver problem." Essentially, the problem is this: DTP provides a set of extensible, vendor-neutral frameworks for using data sources (defining driver templates, making connections, getting data and so on). By the very nature of frameworks, they act as enablers rather than tools for end user tasks. But, what happens if we don't have an extension to the frameworks for your particular case?

Let's take a specific example: you use (or are required to use) database O, and are looking for some tools in Eclipse to help in application development. DTP seems like the logical place, and you eagerly download it. But, wait: It doesn't work with database O! What a disappointment! The fact that the DTP frameworks work fine with another database doesn't help you here. Basically, DTP does not work as far as you are concerned. This is the same as when you install an operating system, only to find out that it doesn't have a device driver for your printer, modem, or other vital hardware.

And you are right. Yet the problem is more complicated: Although we want DTP to be used by the widest possible community (both extenders and end users), DTP has neither the staffing level nor experience to create and support all of the data sources that would be required by this wide community. So, the situation is frustrating from both sides: you want DTP to work completely with your data source, and we want to make that happen.

One possible solution is simply to say something like this: Look, this is open source software -- extend it yourself and make it available to others! That could work, but has a number of drawbacks: (1) If you are a new user of DTP, how do you easily find the required extensions for your data source, (2) How do you know particular extensions for data sources work in certain DTP versions, (3) If you are an extender, how can you work closely with the DTP team, aside from relying only on newsgroups and mailing lists?

We at DTP hear this concern and want to address it. But we need to do this in partnership with the community -- we simply don't have the staff and expertise to cover all necessary data sources. And hence, we have proposed the Enablement project as a new subproject of DTP.

Take a look at the Enablement proposal: let us know what you think. And, more importantly, come and get involved to make DTP everything that it should be. I am convinced that together we can make DTP a truly compelling part of the Eclipse ecosystem.

Monday, May 22, 2006

You want to do what with Eclipse?

It's my birthday, and I'm giving myself the present of playing Devil's Advocate about Eclipse.

At eclipse.org we talk a lot about "extensible frameworks and exemplary tools." Frameworks are meant to be built on, and are not end-user tools by definition. Some projects even use this word in their name:

  • EMF: Eclipse Modeling Framework
  • GEF: Graphical Editor Framework

We also use the word "platform" a lot, especially in project names. Examples:

  • DTP: Data Tools Platform
  • WTP: Web Tools Platform
  • TPTP: Test & Performance Tools Platform
  • STP: SOA Tools Platform
  • DSDP: Device Software Development Platform

I'll take the notion of "platform" to mean something like what Michael Cusumano has written: "...an evolving system made of interdependent pieces that can each be innovated upon." ("Platform Leadership," p.2-3).

Yet we also find an emphasis on tools:

  • JDT: Java Development Tools
  • CDT: C/C++ Development Tools
  • BIRT: Business Intelligence and Reporting Tools

Those of us who work on "platform" or "framework" projects, however, often get requests and questions from end users, typically trying to use the example (exemplary) tools for a particular task. Now (and here's the Devil's Advocate): Why would you try to use a platform or framework to do a end user task? It's not a coincidence, I think, that the last three projects above have strong user communities and the earlier examples tend to have much strong extender communities. In the end, it is really is an expression of the committer base and those who "fund" the open source project by enabling committers to work on them. If platforms or frameworks are primary, then that's great for extenders, but not so good for end users.

Is this obvious? Even if so, if this the direction that eclipse.org should be moving? If you don't think so, then what can you do to motivate change?