From time to time we all have fun arguing about whether Eclipse is a platform or a product.

One the one hand, its the Eclipse organization’s mandate to produce reusable infrastructure, which is platform. On the other, when you download all this great free stuff and use it, you can’t help but have an expectation of it being a product. Two fresh off the press posts, one by Malink pointing to recent Europa comments, and other from Chris (zx) wishing for diagram visualization in the SDK, have me pondering this duality.

(As an aside, I was completely amazed that people thought that Europa would constitute a well integrated set of tools, as if simultaneously releasing 17 million lines of code wasn’t hard enough).

From the beginning, the distinction between Eclipse the Java Development Tool and Eclipse the Platform have been blurred. We are slowly starting to unravel these from each other but at the basic level it requires us to change how we think about them. This is the tough part.

For those of us who contribute to building and defining the Eclipse SDK, we are always torn between various goals:

1. The platform as a base technology that every Eclipse based plugin/application/product in the universe will be built on.
2. The IDE (platform + JDT + PDE + Team/CVS) as a best of class tool for the development of Java and Eclipse technology.
3. The IDE as a base technology that many Eclipse based plugins/applications/products will be layered on.

Those goals do not always align. If I were in charge of building a Java development product, and only that, I’d make certain decisions that were the most pragmatic for that goal. Perhaps such as inclusion of diagramming. You’d simply consider effort required vs. increased “sales”.

But goal #1 intrinsically seeks to produce a minimal footprint. Thus its a big deal to consider adding more components such as GEF to the mix. Would I love to see diagramming in the IDE? Heck ya! Do I want to basically make every Eclipse based RCP app and product eat a bigger footprint? No.

The solution lies in making it clear which is platform and which is product. And to me, the best bet we have at it is the Eclipse Packaging Project. Why? Because it provides a vehicle under which each can be distinguished from the other. Folks wants a Java development tool with diagramming? Make a project for it and package it up together, throw in GEF or whatever else you the product designer see fit. Your footprint only matters with respect to the amount of stuff you have manpower to integrate and the maximum download size you think your users will accept. Nothing else. Hey turns out we already have that, sort of.

I say “sort of” because in its infancy those packagings are simply collections of technology thrown into the soup together. What’s required is:

1. People to come forward with a vision, definition, of a packaging wrt. the audience it is seeking to appeal to.
2. A group of people to be the stewarts of (1).
3. Some effort into actual integration so the package value becomes more than the sum of its components.

“Whoah” you say, “that’s putting Eclipse in competition with products the member companies are creating”. On the surface perhaps, but I know that companies like Innoopract and Instantiations provide considerable value-add above that effort which I am describing here.

The point is, we have a place to defined components, and we now have a place to define open source “products”. The more use we make of it, the less confusing it will be for the community, and ourselves.