It's been said that code talks. At EclipseCon a couple of weeks ago, it struck me that the only way that Eclipse evolves is through code; whether that's patches, new functionality contributed en masse, or documentation. Sure, there's a bug-tracking system which is used to record the state of applying patches, as well as mailing lists and newsgroups where discussions take place about particular aspects of evolving features, but at the end of the day the only measurable outcome is how much code gets created.
Whilst this may not come as a surprise to most people who deal with software, it actually has a number of important corollaries that are worth noting.
Firstly, it means that enhancement requests are (unless a patch is attached) never likely to be processed. There's way more bugs at bugs.eclipse.org than are ever going to be processed — no software is ever bug free, and Eclipse is no exception to that rule. The larger the amount of work an enhancement request is likely to take – regardless of how useful such an idea is – the less likely that that enhancement request is to be done. (On the other hand, trivial requests such as typos in documentation are much more likely to be done.)
Secondly, it means that being passionate about bugs really has no effect. Speaking as someone who's been passionate about a number of quirks in Eclipse, I can safely say that I've had approximately zero effect. Being passionate about raising the visibility of a problem is a complete waste of time; unless a committer has experienced the problem and wants to fix it, then no amount of passion or talking about it is going to fix the problem. Some obvious examples: update manager is generally regarded as dire; it's dire because no committer uses it, therefore they have no need for fixing it (instead, they just tend to install integration builds periodically). A similar effect is in place for the HTML download links for Eclipse; instead of being good web pages, they're dire; but committers don't use that page, so they don't care. And of course, there's PDE, which mandates that all resources exist at the top level of the project, despite the fact that no-one outside of PDE structures their project that way (but then again, committers only use PDE so ...)
Thirdly, if the issue raised is about non-code items (for example, the way that bugs are tracked/reported or the way the website is laid out) then the chances of the bug being addressed is pretty much zero. Decisions about the process are made by the PMC, and they're usually too busy to address bugs specifically about the process on account of having lots else to do. Other non-code items (for example, discussing UI usability enhancements) are not likely to be dealt with via the bug system, because the focus is on the code.
Fourthly, bugs asking for Eclipse to be different – even if this means for the better – are unlikely to be entertained. Examples include getting rid of the 'configuration' folder (or moving it to a
@user.home location) or being able to supply a PATH-like variable for plugins to be located, are just not going to happen. In these cases, the bugs are usually marked as WONTFIX just because it has no beneficial impact to the Eclipse committers, and therefore no benefit putting it in.
Having said all of that, the volume of bug reports and changes is increasing to around 50/day as we approach the 3.3M6 delivery in the near future, and is likely to be addressed more as the countdown to 3.3 continues. Of course, Eclipse won't ship with 'blocker' or 'major' bugs left untouched; but there will always be those bugs that didn't quite get fixed in time (or needed something extra, such as a public API, after the API freeze) that will be left open for the next release (or maybe hidden with a RESOLVE NEVER).
It's also true that these are overly large generalisations, and mostly based on experiences with the Eclipse project (i.e. JDT, Platform etc.). A lot of the smaller projects (ECF, Mylar etc.) are much more responsive to new ideas and on getting feedback from the community. And as with generalisations, it's not a hard and fast rule. For example, there have been several hundred enhancement requests since the beginning of last year; although over half of those had patches supplied by the original reporter and many of the remainder were just trivial fixes explained in the text of the bug.
But the conclusion of the matter is that if you want your issue to be fixed in Eclipse, it has a significantly higher chance of being addressed if you supply code to be able to make that fix; after all, Eclipse is You. That's not to say having a patch implies that it will be fixed — for example, I implemented kerberised CVS support and attached it as a patch some years ago which never got picked up. But code talks, and if you don't have a patch then regardless of how passionate you are about an item, your bug is silent.