Doug Schaefer’s “Eclipse vs Emacs, a unfinished battle” blog entry is something I think the committers and the foundation as a whole needs to keep in mind going forward. Particularly the following quote:
Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it’s still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it’s no good.
This is not only for the developer, but also for those writing and using applications built on the RCP framework. The problem I see is that we as developers tend to have nice fast multi-core machines. However, the business community and the people using the products we are building still have single-core or older machines. It’s important when we are working on any platform code to consider what our potential end users are going to have. I’ve worked with Eclipse on a single core 1.2ghz system with 1GB of memory, and it is painful. And this was with eclipse 3.2 and 3.3, I don’t even want to try to run Eclipse 3.4 on the system. It would be great if the 3.5 version of eclipse was the same size memory and code wise, while adding and maintaining existing functionality.
Most of my user community works with large XML Schemas and XML files. When they have to wait 10 seconds or more on a single core system they aren’t happy. Also, if I want to provide ANT runtime ability or Java launching ability in my XML IDE, I have to include JDT. Unfortunately, 90% of the users of the product we built on eclipse don’t need or want a Java editor, they just want the ability to run some ant scripts, as well as work on their XML files. While eclipse has a lazy loading feature, it doesn’t necessarily unload something once it’s been loaded. So accessing a particular class in the JDT to launch an ANT script could cause significat portion of JDT functionality to be loaded as well.
In general as people wrap up 3.4, I hope that peformance will be a big planning item going forward with 3.5
There has been a lot of chatter in various blogs about getting the community more involved, how hard it is to get a contribution added, how can you help influence the features implemented, etc. These are all issues I’ve experienced over the last couple of years as both a community users, a sometimes contributor, and as a part-time “unpaid” committer. Truthfully, there are too many hoops to jump through from a community members stand point. I’ve been on the receiving end of bugs reports going unanswered, patches or suggestions rejected out of hand, and planning that really isn’t very open. However, I’ve also been involved with projects in eclipse where I’ve had the opposite occur as well. EMF and PDE are two projects where I’ve had very good response rates and communication. They really should be commended for how quickly they respond to issues and request for enhancements.
The point that has been made about there aren’t enough bodies to toss at the problem. It’s been my experience over the years that you never solve a software problem by just tossing more bodies at it. Smaller teams seem to work best, but it is all in how they prioritize and organize themselves. While I can respect the need for IP cleanlyness and being conservative on what is accepted into the code base, it is also very discouraging for an outside user who has worked to fix an issue to have it rejected or marked “WON’T FIX” without some sort of explanation of why it won’t be fixed, or why the patch can’t be contributed.
I’m not sure how to fix the prioritization of features and bugs. I don’t think there is a nice clean way to do it that will meet everybody’s needs. However, I think what each project does need to do is eat it what it creates. My day job is working with various XML specifications. I’m also a part-time committer on the XSL Tooling project. I eat what I create in the way of code and features I put into the XSL Tooling project. If something isn’t working, it’s going to affect my ability to do my job. It’s one of the reasons I think JDT is so good, the developers use what they create themselves. If a corporation is paying for a committer to work on source code for eclipse, how likely is it that person actually uses what they create to do their job? I would guess maybe half, but that may be generous.
To me the community feedback and requests from the non-paid users and developers of eclipse is just as important as the companies that are paying programmers to write code for eclipse. If a community user is having problems, and they have sent a reproducable bug report, then I think it deserves higher consideration than a feature request from another source. The problem with waiting to triage a bug or respond to it several years later is that the person that reported it probably gave up on it a long time ago. We as committers need to make addressing these issues a top priority, otherwise, the user community feels like we don’t care.
Unfortunately, I don’t have the answers on how to fix this, but it is an issue that is of concern. I’m glad to see that Eric Rizzo brought the topic up for discussion, and that the community is continuing the discussion. How we address this will be important, as we can build all the great features into e4 we want, but if we continue with the same attention to the community that we have we are going to be repeating the same issues again.