There is a discussion in the Eclipse ide-dev mailing list on how to make Eclipse more competitive. This was prompted by the blog post Why we dropped Eclipse in favour of IntelliJ. Below is a summary of the items discussed.
Better Performance
Developers in general complain about performance. Eclipse Juno (4.2) had performance issues when it was initially released, but this has now been resolved. Still, a faster and leaner Eclipse can only help the Eclipse platform.
Smarter UI
A frequent complaint is the lack of convenience or smartness in the UI. One common example is proposal sorting mechanism that does not cope well with developer expectations. Quickfixes and other content assists can also be enhanced. Any improvements should have reasonable performance, and should be built-in Eclipse, instead of being an add-on or plug-in.
More Developers
Eclipse needs more developers, who can act as contributors, committers and reviewers. Developers can be individuals who want to donate their time and expertise and help the various Eclipse projects. They can also be people who work for big companies, where these companies are willing to sponsor development work. The existing Eclipse team members would need to time to support and give more attention to new contributors, who hopefully will become full-time committers and reviewers.
Working Group
There is consensus about the need for an IDE Working Group (IDEWG). The IDEWG will be an open and transparent working group, and will create of a long-term roadmap for the IDE spanning across multiple projects. There is already a draft proposal on the Eclipse wiki created for initial feedback and discussion. Companies and individual developers who would like to get involved are encouraged to subscribe and participate in the ide-dev mailing list. Funding for the IDEWG is one of the primary goals, so the working group can pay for its own developers. Contributing developer time is also welcome.
The IDEWG is not going to replace any planning/contribution practices already in place in the various Eclipse projects today. The existing team of committers and the project leads would still be the authority that decides what goes in to each project.
Reviews
There's a current backlog in terms of reviewing contributions in Eclipse. There are currently only a few people who are skilled to do reviews, so getting reviews takes time, especially if contributions are not part of the project's roadmap. One suggestion is to make reviewing outside contributions a requirement of a core Eclipse project, just as participation in release train or bug triage is. Another suggestion is for Eclipse teams, in the short term, focus on reviewing/accepting contributions from individuals who are the most likely candidates to become committers, thereby increasing the team's capacity.
Commercialization
To encourage small companies (who need to make revenue) to engage in the community, Eclipse would need to start promoting commercial add-ons. One idea is to have a better way to navigate and announce commercial add-ons on the Eclipse website. There is currently a risk when investing into commercial products on top of Eclipse, because of its free and open-source nature. There is a natural reluctance to buy something, unlike commercial tools like Visual Studio.
If you are a developer who is interested in improving the Eclipse platform, please make yourself known and participate in the Eclipse ide-dev mailing list.