I’m at the E4 Summit this morning. I’m completely surrounded by Germans (which is a Good Thing™). To my front is Boris Bokowski of the Platform team (who actually lives in Ottawa). To my right is Jochen Krause from RAP. Behind me is Christian Campo from Riena and Michael Scharf from DSDP. The room is filled with dozens of folks who have come from all around the world to discuss the future of the Eclipse platform. Many of the folks here are committers on Eclipse projects, but some are non-committer representatives from the broader community.
McQ is coordinating things (but is happy to give up the position should somebody else want to stand up in front of everybody) and Kevin McGuire has graciously volunteered to take notes (which you should be able to find hanging off the E4 Summit page sometime later today).
Early on, we captured some areas for discussion.
- What is the goal of E4?
- How do we structure the project (human, code)?
- Work areas listed in the E4 Summit page
- Backwards compatibility and deprecation
- Backwards compatibility is a core value
- How do we describe E4?
- What are the competitors for E4? What is the “Killer App”?
- What kinds of applications can we not build with current Eclipse technology?
- Investment
McQ presented his initial thoughts about the development effort. To paraphrase (I’m not a particularly good transcriber):
“This is not a sandbox. I intend for everything we do to graduate. We should be working on things that we expect to become part of our mainstream codebase at some point. There is a range of things we should be working on. Some of those things will make their way back into the 3.x code stream. I believe that we will not be able to do everything we want to do in 4.0 in a backwards-compatible way. I hope that we will do something compelling which will motivate the community to move to 4.0. If we are successful, at some point the 3.x stream will die (though we can expect many years of ongoing maintenance before that happens).”
We also discussed (at a high level) some of the key/killer features that we need to consider for E4:
- Size/Scalability/RCP
- Style/CSS/skinning
- Easy to learn
- API Size
- Web/Internet
- Flexibility
- resources
- Style
- Platforms, components
- Productivity
Other (more or less random) thoughts thrown out:
- The web and .Net are competitors to E4.
- Eclipse 3.x is probably a bigger competitor for E4.
- It’s not only about IDEs.
- We’re never going to neglect the IDE-ness of Eclipse. We’re going to self-host development of E4 using E4.
- Applications built on the Eclipse platform shouldn’t look like Eclipse.
- We need a plan for migration/deprecation of APIs spanning a 2-3 year period
- Eclipse is as much of a platform as .Net.
- Empowering a broader range of users/developers to build mashups using Eclipse would be über cool.
- Eclipse offers a powerful and independent API that helps people work, providing long term viability no matter how the technology evolves. We need to move this forward to exploit newer technologies.
- We have a new class of target to support. Maybe all the plug-ins aren’t even coming from the same machine.
- One of the values that Eclipse brought is the integration with existing platforms. It’s going to be the same thing in the browser space.
- What does the world expect from us five years from now?
- We are so successful that people are now building applications that are an order-of-magnitude larger than they were years ago. People are actually building applications with 3k-10k of bundles.
Time for a coffee break. More later.
