Open Source + Independent Studies

Register or Login to like
Register or Login to like
A key and a building

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?

Matt is passionate about the design and development of usable languages for embedded control. You can some of his work at, a rallying point for parallel programming on the popular Arduino platform. However, most of the time Matt keeps himself busy as a member of the faculty at Berea College.

1 Comment

"So you're trying to utilize a limited resource (dedicated, hard-working undergraduates) and ultimately you need to bring value to the table.

Telling the story behind not only projects and initiatives, but the people who make them happen, provides a kind of value you just can't get from a pile of money; recognition, appreciation, and legacy. Most people who are willing to put themselves headlong into a project are seeking more than just an intern's payday. A well-timed plug on a few upstream blogs and sites can quickly build bridges and rapport with resource and attention starved projects--possibly remedying both situations without much (material) input.

One strategy that has been effective at getting students involved at our University has been Hackathons. These events serve as an opportunity for intensive short-term commitment (12-48 hours), with immediate results (running code) and a great story when documented properly. You may not get the same kind of long-term buy-in as you would with a semester program, but Hackathons can be utilized as a shotgun approach to seeking talent and closing tickets.

Code sprints will build interest and visibility for projects, but more importantly the <em>people</em> that move projects. In the proper environs hacker work ethic presents itself, and is necessarily adopted by those uninitiated caught in the headlights. Rockstars and neck-deep hackers, who become your lead devs and mentors for future students and projects, rise to the occasion when presented with an opportunity. Protohackers and other susceptible movers-and-shakers can witness the productive power of rapid web development, and the responsivity of realworld opensource communities, and inevitably catch the bug.

Our recent <a href="">Hackathon for Haiti</a> was a good example of this Hackathon model, but with the added incentive of Community Service Credit. Many student organizations have a Community Service requirement as part of their charters and missions, and easily make the connection between the public domain and the public good.

Regardless of the approach, incentives, or execution, knowledge share is always the added value of storytelling; even in failure.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.