it's difficult to compare a project like memcache to firefox. the memcache bug list page can probably fit on a single screen, whereas firefox probably has hundreds if not thousands of open bugs due to the size of the codebase.
once a list of open bugs gets too big, users won't bother searching for duplicates or can't accurately find them, and new developers won't know where to jump in, so the list just keeps getting bigger.
add to that the fact that many users don't include proper information like how to reproduce the problem, test cases, backtraces, etc. and once developers actually get around to looking at those bugs, they have no interest in tracking down a user whose email will often bounce or isn't running the software anymore, just to reproduce an issue that may have been fixed by some other change months ago.
The lesson I take from that is to work hard to keep your buglist low.
As an example look at OpenBSD. By my count from http://www.openbsd.org/query-pr.html they have 208 open bugs, of which they are actively working on over a third of them. That's for a whole operating system!
2 - rewritten sendbug to remove useless fields and automatically add useful information for developers (dmesg output, acpi dumps, etc.) to make it easier to trace problems to specific hardware
3 - quickly respond to new bugs. if they are valid, poke a developer that will know something about it. assign the bug to someone or at least mark it as verified. if the bug report doesn't have the required info or isn't valid, respond to the user and close it right away. don't let things pile up.
I definitely understand that there's a huge difference in size. But I wouldn't mind people closing bugs with "I don't think it's worth my time" in firefox. It would be bad, but still better than letting the report rot at the bottom of the list when the user is not even sure if the report was ever read by anyone.
Much like e-mail, if you let things fester they will get forgotten. Sometimes, I think projects need to be willing to declare bug bankruptcy and close all non top-priority bugs to start fresh.
once a list of open bugs gets too big, users won't bother searching for duplicates or can't accurately find them, and new developers won't know where to jump in, so the list just keeps getting bigger.
add to that the fact that many users don't include proper information like how to reproduce the problem, test cases, backtraces, etc. and once developers actually get around to looking at those bugs, they have no interest in tracking down a user whose email will often bounce or isn't running the software anymore, just to reproduce an issue that may have been fixed by some other change months ago.