2 ms·

I would hate to see that happen. In a project with a sufficiently good review processes, the investment of time for helping somebody contribute the first patch(

I would hate to see that happen. In a project with a sufficiently good review processes, the investment of time for helping somebody contribute the first patch(es) will far outweigh the benefit, and amortise only for developers who stay with the project for longer. Add extrinsic motivation to contribute patches, like extra credit, and what you will end up doing is abusing experienced open source contributors as teaching assistants instead of an actual contribution to open source. Let's not forget that one of the guys who did open source to further their academic career, only to drop it later, was Robin Seggelmann, the creator of Heartbleed.

robert_tweed 12y ago
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.

robert_tweed 12y ago

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.