It's true that for my money I get the assurance that they won't simply close the bug, but every other aspect is exactly as you describe with open source projects (for example, they ask me to re-confirm the bug still exists in newer versions even though they've made no effort to resolve it). At least you have the option of trying to find and fix the bug yourself: it's work, yes, but then you have a fix even if upstream doesn't incorporate it.

My bug results got dramatically better when I started running live-git for anything I was sufficiently interested in. Running even the latest released version unfortunately doesn't seem to be enough, I suppose because from a dev's perspective once it's released the code is driven from working cache by new projects. Additionally, releases tend to have many candidate commits in the bug-trigger area making bisection far more difficult.

Run the live-git version and it's an /entirely/ different ball game, even compared to betas/rcs (which surprisingly/frustratingly for me often didn't get good bug results either; why bother with a beta/rc if you're going to ignore bugs filed on them?!)! Update that live-git ~weekly so the code is still in the author's memory-cache and there's only a handful of bug-trigger-candidate commits, and resolution chances go up *dramatically* even for non-coder-reporters, even if you can't code and don't have time to bisect. And if you can/do, even better! I'd say 75-90% success (and many of the others are often "features not bugs"...) here, as an admin but not coder so I /can/ bisect and run test code but only sometimes can hack-patch.

The bonus of course, especially for those "features not bugs", is that between the git logs and bisect I can normally find the "interesting" code, and can either revert or modify the culprit commit as my own patch. And once I have the patch Gentoo makes auto-applying it to updates a matter of simply dropping it in the appropriate dir, an important consideration when one is live-git updating weekly!