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.
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.
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.
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.
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.
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.
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.
Eclipse Now Prominently Asking for Donations
I would have thought that large companies that rely on Eclipse such as SAP, Google and IBM would fund the effort for their own sake but apparently not so (or the priorities differ markedly between them).
Ability to share workspace & project settings across a team.
Currently we have to import/export code conventions, and formatting, then manually tweak warnings/errors for java and xml, and flip the encoding to UTF8 manually. Every time we create a new workspace. Then of course somebody gets it wrong.
The intellijsettings.jar which bundles all shared settings is way nicer. The eclipse workspace mechanic plugin is a great idea, but I haven't found any default, nice set of tasks that have been configured. Too much hassle to create loads of tasks on my own.
Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann Mar 09, 2014
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014