About a year ago I got to the stage where I stopped filing bugs for projects where I don't have a direct contact with any developer, because usually it's just a waste of time for me. I've got issues opened with OO.o, ubuntu, firefox, f-spot and others that weren't looked at for years. I didn't even get a response from developers to verify most of them... OO.o is the winner with 4 issues opened and 0 closed since 2005 followed with ubuntu with 16 triaged / confirmed (but no fixes).
Developers - please take example from memcached. If you let someone wait for 3 years, and then ask "so how do I reproduce it" the only answer you're likely to get is "don't know, I'm using some other app since 2005, because you can't be bothered to fix bugs"
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.
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!
1 - make the kernel tell the user exactly what to report in the case of a kernel panic
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 was thinking of writing an Adobe Air app that uses xdump and xtrace to let you view/edit usage of memcached. A friend has a project on github that lets you do this in 1 app on a mac but the Air app would be cross platform.
Thoughts on releasing this as an open source project?
btw, the Mac app is at http://github.com/gerardg/mcinsight - its a fork of another project.
The only reason I'd say you shouldn't release something as an open source project is if you strongly feel that someone is going to hand you a sufficient amount of cash to keep it proprietary (and even then, it's pretty easy to convince them that there's potentially more value in your project as open source).
I have regretted not pushing projects forward as open source in the past. I have never regretting making something open source.