Why Everyone Needs a Bugmaster

While open and proprietary projects have a lot of differences, they share enough similarities that some of the motivations for having a bugmaster are shared between them. These include:

By taking the rough edges off of bug tracking and doing lots of dirty work, bugmasters let hackers do what they want to do most- focus on creating great software. For both proprietary and open projects, anything that isn't coding or designing is overhead that detracts from either hacking more or having a life. A great bugmaster delivers an organized, consistent, friendly bug tracking system to hackers, and lets hackers hack, and that is guaranteed to help morale. All this without the detrimental effects of shielding developers from feedback, which is often the failure mode developers and managers fall back into when a bug system is difficult or unpleasant to use.
In my experience, it is rare in any type of large project that people have a true sense for the quality of the whole product (outside of bug counts); a more holistic approach to QA done by someone who has dealt with massive numbers of bugs on the lowest level can help planning and release strategy quite a bit, by providing better and more qualitative information than the graphs and counts that are the raw tools of most QA management. Saying 'bug counts are doing down by XYZ a week' is great, but supplementing it with the understanding of someone who has read hundreds or thousands of bugs can help catch problems early. To put it another way: even the best hackers can get tunnel vision on specific projects or tasks; a bugmaster can help reduce the implications of that by spreading information around aggressively.
Good bugmastering understands a project's priorities and works constantly with hackers/developers to achieve those, reinforcing project direction in a constant, developer-friendly, low-level manner during their participation in every bug. In open projects, even in the case of projects that have an iron-fisted BDFL, that BDFL is unlikely to be able to oversee all aspects of the project. Good bugmasters help open project leaders (BDFL or otherwise) move the project in the direction they want it to go, by prioritizing bugs in line with the BDFL's vision and helping clarify that vision when hackers or bug reporters aren't clear on it. Similarly, in closed projects, while product and project managers define a project's direction, they can't read every bug and are often poor at communicating this vision to hackers. A good bugmaster bridges that gap, using the bug process as an opportunity to move the project in the specified direction, one bug at a time. This bridging of developers and goals also works in reverse- a good bugmaster is likely to be among the first to see that a particular portion of a project's goals are unworkable, nonsensical, or just unlikely to be finished in a desired time period, and can help communicate that to leaders who can figure out where to go from there.