Bugmastering is not just for open source projects, I believe, though I have less personal experience with this. Traditional software QA has some failings that can be remedied (all 'frequent', none 'always') by applying another layer of review and communication on top of traditional QA<->engineer communication.
|Proprietary QA frequently has blinders on. In many cases, QA is assigned to a small number of subsystems and works tightly on small, specific parts of functionality with specific developers. This division of labor is of course necessary in a large organization, but it isn't sufficient for a healthy QA organization- it makes patterns harder to spot, makes it more difficult to have a qualitative big-picture view of product quality, and it encourages cozy relations between hackers and QA which can fail to push the bug gathering process hard enough.|
|Traditional software QA tends to focus on the automatable, since they have the time and tools to do this, and because everyone tends to dislike manual testing. This is understandable and reasonable, and in most cases quite useful. But obviously it has shortcomings, and someone who deals with a large number of bugs by reading and dealing with them can often see patterns in them that are missed by people who concentrate on specific functional areas and/or specific testing tools. (Expert QA teams can also work around this problem by doing escape analysis after a product is released to see what their automated testing did not catch, but this does not directly help brand new products or brand new features.)|
|Similarly, since traditional QA tends to be firewalled from customer relationships, and because PM (in my very limited experience) can fail to communicate goals very well with QA, it is easy to focus on tests that directly reference specific features, without stressing cross-component integration that isn't well specified.|