I have to say that I'm against this strategy for a number of reasons, 1. It puts the onus on figuring out what to do on the student. And since there's no prom

I have to say that I'm against this strategy for a number of reasons, 1. It puts the onus on figuring out what to do on the student. And since there's no promise of guidance from the project, the student could spend on their time flailing around and accomplishing nothing. 2. Large OSS projects require specialized knowledge. It can take years to develop the knowledge necessary to make meaningful contributions to a project. There shouldn't be an expectation that students have the requisite knowledge to contribute. So the student is probably going to be relegated to minor bug fixes, documentation, or other kind of mindless tasks that no one else wants to pick up. 3. It takes time away from learning fundamentals. I think most students would benefit from building their own project rather than contributing to OSS. For example, building a working web server will teach a student a LOT more than a few commits to Django ever would. Contributing to open source is great for certain students. I love the Google's Summer of Code and the like, where students have an idea of what they want to create, and the project is incentivized to provide a mentor to the student because they get funding. But expanding that model to every student is foolish and hurts less privileged students a lot. A good middle ground would be to have a course use open source code as a foundation for a project, but not require contributions back to the project. I had a computer security course lab that required us to find a specific exploit in an old version of sudo and create a patch for it. The issue was many years old by this point, so giving the patch back to the project was pointless, but we still learned the fundamentals of working on an OSS project; how to document issues, how to create patches, how to create test cases, etc. And since it was a lab, we could ask other students if we got stuck.