Open Source + Independent Studies

You have an open source project. You discover something that it would be really awesome to have added to your project, but you can't justify bumping it up the priority queue. It clearly has a bit of core CS theory in it, a bit of old-skool hacking, and the end product will add some real value to your project (and possibly the lives of thousands of people). How do you get a college student to take this on as an independent study project?

Mel Chua pointed to a possible project regarding the number of active Fedora installs. Her intuition was to say "huh, this is something I could work on, write a paper about, and turn in for school, if I were still in school." She's exactly right—it would make a wonderful independent study project.

Here is one roadmap for involving a student in your project under the aegis of an "independent study" or independent research/hacking experience. While it is true that they could "just contribute to your project for the greater good of humanity," the reality is that college students need credits to graduate, and getting credit towards graduation is one of the primary currencies of 4-year undergraduate instutitions. (I'm not trying to rule out community colleges or any other educational environments—I'm just speaking to what I know well for the moment.)

You need to do the following:

1. Find a student. Preferably, one who would love to contribute to your project, but so far has not found something "the right size" to work on.
   
   
2. Find a mentor. The student will need a project mentor at the institution. They should be able to do this. Get the student to introduce you, and then have a conversation with the faculty member about what you're trying to do, and how you'd like to get the student involved. Start with email, but remember, you're potentially building a long-term relationship here; if this is successful, you might find yourself with a steady stream of engaged contributors. Hence, perhaps having a phone call to make sure you understand what the expectations are, how the project will be evaluated, and so on, would be a good idea. (There's probably an entire blog post in my "and so on.")
   
   
3. Wait for the start of a semester. It is February 4th. (Actually, it depends on when my Benevolent Editor releases this post.) At my institution, the "add/drop" period is over. If you walk in the door with cash—enough to make people's ears perk up—I might be able to beg the Registrar to add a project now. However, the Registrar is a very powerful individual/office at the college level, and they live and die by rules that they never bend or break.
   
   So, your engaged student contributor that you'd love to have on your project is already carrying a heavy courseload, and while they'd love to work on your project, it will now have to wait until the Fall. And while summer would be nice, they're going to be doing a summer REU program, and really won't have time, since they'll be doing really cool research somewhere, and their limited spare time will be spent hanging out with the other students who came in from all over the country to take part in that research.
   
   Put simply, you missed the boat. Now wait.
   
   
4. Structure, structure, structure. College students typically have poor time management skills. I say typically, but the truth is they have a lot going on. You're going to need to have a weekly meeting with them, or their mentor at the institution will. This is not unreasonable; they're adding value to your project, and you should likewise invest in them. The point of the project is that they both investigate the core concepts in the project as well as learn something about real-world software development.
   
   If you can't mentor them in this way (again, this depends on what you and the faculty member discussed), then perhaps you shouldn't be working with college students. These students are going to be graded for their efforts at the end of the semester based on the success of their work with you. When they're volunteers, you can treat them however you want—it's your boat, and you can drill holes in it if you want. But when you're working with me and my students, I expect you to be engaged, just like I expect excellence from my students.
   
   
5. Promote, promote, promote. When a student contributes to your project, highlight it. This may be the first time they've stepped into the world of community FLOSS development. You've grown our base. It's a big deal: tweet it, blog it, make sure they're in the release notes.
   
   This provides the student with fodder for future interviews, and they can then point to your acknowledgement of their effort. Likewise, if you're working with a professor who is on the "tenure track," you should send them an email—a physical letter would be better—where you thank them for their support in introducing a student to one of the most powerful and important software movements in history. Wax poetic. The faculty member will use this in their promotion process regardig how they are providing excellent, real-world learning opportunities for their students.

There is a great deal more to say on this topic. For example, faculty will already have their own research agendas which they must publish on (hacking software rarely counts—a discussion for another time). They're usually looking for students to work with them, not with you. So you're trying to utilize a limited resource (dedicated, hard-working undergraduates) and ultimately you need to bring value to the table. Put another way, why should I, as a busy college professor, mentor students who are working on a project for you, when they could be working for me?