There's certainly an argument for research on this topic. The core theory of open source quality is "many eyes" and in the similar case of Wikipedia, it works v

There's certainly an argument for research on this topic. The core theory of open source quality is "many eyes" and in the similar case of Wikipedia, it works very well: much better than Encyclopaedia Britannica with it's long-term expert curation. Whether or not it works for open source largely depends on the competence of the individuals vs the complexity of the bugs. However, most bugs are caused by trivial errors that just aren't easy to spot and happen to pass the test cases. That's where a high-volume, low quality process like crowd sourcing can be very effective: someone, somewhere will spot those stupid errors, provided you have sufficient eyes on the code. The idea that people should be discouraged from working on FOSS projects unless they plan to commit to one project is against the principles of open source, namely that it is open. In fact, if this were done over the course of a 3-4 year course, it's likely that each student would stay with one project anyway, and very likely they'd continue contributing after graduation. I agree that a "one off" exercise would just lead to an influx of inexperienced coders and "do my homework" questions on mailing lists, but that's not what I had in mind at all. Ultimately, any university implementing such a programme should be thinking about the net benefit to the community and doing things like penalising students for filing duplicate bug reports to mitigate against possible negative consequences.