Mixing Eclipse projects -- getting to where you want to be

Foo Yung Chang commented on my earlier "Fractured Eclipse?" post with a perspective that I hadn't previously considered: "These users don't read newsgroups and post to Bugzilla; they just want to build their database-driven webapp without learning how to operate a nuclear reactor. These tasks reside at the intersection of WTP (75%), DTP (25%) and TPTP (25%)."

I think this calls out the need for cross-project use cases delineating the types of things that users want to do, and the part of eclipse.org projects they need to accomplish these tasks. Callisto is a first step in this area, simply trying to get everyone on the same page, platform-wise, and to see what happens from that. What sorts of cross-project uses cases are out there? Which ones should eclipse.org address, and which ones should be handled by the extender community?

What motivates an eclipse?

Mike Milinkovich has an interesting response to my earlier "Fractured Eclipse" entry. He points out that the Eclipse Bylaws emphasize frameworks, and this is clear from the section that he quotes. He also notes that exemplary tools are crucial as well, as called out in the Eclipse Development Process Quality section. I think it is telling that two sources are used here. I don't disagree with Mike's comments at all, but I think the juxtaposition of these two sources is a very nice example of the multiple voices present in the Eclipse stakeholder community. Roughly, we have the extender and user groups. The extenders are more interested in the frameworks typically, and in fact might not want to see strong exemplary tools, since that is one area in which they'd like to make money. Users want to use Eclipse to perform some other task, such as developing enterprise or RCP applications. One looks inward to Eclipse and builds on it, and the other looks outward from Eclipse and builds with it. IMHO both are valid positions, but the framework centric one has tended to dominate more (notice that the framework comments come from the bylaws, whereas the tooling comments come from the development process guidelines).

So, as the Development Process Quality section says, "Neither frameworks without users nor tools without frameworks are interesting points along the software development spectrum," and this is certainly true. The challenge is to recognize the multiple stakeholder voices in the Eclipse community and strike a balance. How are we, as members of the Eclipse community, doing at this?

Fractured Eclipse?

So, there's been a lot of discussion today about the level of integration among projects at eclipse.org. As the PMC chair for a top-level project at eclipse.org, I've certainly been aware of these sorts of issues, and have heard a number of discussions about them in various forums, ranging from the more formal (architecture council) to the casual (chance gatherings at conferences, user groups, etc.). I have to confess that I'm of two minds here.

On one side, the early history of Eclipse set a very high bar (too high?) with the JDT and PDE integration with the platform. Both of these technologies, especially JDT, are the result of concentrated, expert work by a strong committer base over a relatively long time (don't let the tip of the eclipse.org iceberg fool you here). Few, if any, other projects at eclipse.org have the benefit of this depth and length of experience (BIRT is perhaps close to being an exception here). Yes, there are a lot of really cool things going on at eclipse.org, but clearly, as the blogs and discussion mentioned above point out, there are a number of fractures too. I think the real question is: Which groups, and in which priority order, is eclipse.org trying to serve?

On the one hand there are ISV having the experience, staff, and willingness to pick up the pieces, and work the rough edges so they fit together nicely. Maybe add some additional pieces along the way. Nice way to build a product, leveraging open source, and there are a number of companies doing so in a big way.

On the other hand, there's the end users and companies wanting to take eclipse.org code as-is (or essentially as-is) and just use it. While groups in the first category can afford to work away the rough edges, groups in this category tend to cut themselves. And this is a very valid concern. I'd really like to see DTP be as full featured and easy to use for its domain as, for example, JDT is for Java.

The question you have to answer, and the position you have to get commitment to, is, however, what do the main players at eclipse.org want to spend their money on? I'm afraid that, if we start trying to solve the "user" problem before this foundational agreement is reached, then any efforts will be half-baked and only further serve to annoy exactly those we were supposed to be helping.

A visit to LinuxWorld

Had a chance this week to help staff the eclipse.org booth at LinuxWorld. Yes, this was the first day, and the one with the now famous flaming booth. I'm ashamed to say this was my first LinuxWorld. While I use Linux on my personal machines, my open source involvement has been around Java and eclipse.org so far. It was really interesting to see the diversity of projects people are working on in Linux, and I was pleasantly surprised that so many Linux users also really like Eclipse (not just for CDT too).

Sustainable software development?

I've been reading Sustainable Software Development by Kevin Tate. I've found it to be extremely interesting and right on target. I'm a little surprised that there hasn't been more discussion about this book in the community, given that unsustainable development is so common and debilitating.