We talk about "community" a lot when it comes to open source, but it's important to remember that just like local communities within a city, town, state, and country, each community has its own culture. One community is not just like another. Each has its own ways of communication and tracking and decision-making. Processes for code submission differ—perhaps two communities both use Bugzilla, but with different flags. Others require you to also alert a mailing list. A large software project may even have smaller sub-communities within it with their own customs and quirks.
Learning these differences is important to the success of your involvement in an open source project, and students need to understand these nuances when they're getting involved. For this year's POSSE class, Heidi Ellis and Joanie Diggs offered suggestions that apply broadly to getting yourself as an instructor and a class involved in a community.
Be productively lost. Maybe you've gotten involved in a large community, and you simply feel lost. The scope is just too broad. The best thing you can do is learn whom to ask when you have questions.
Give back. FOSS survives on contributions. It's core to the process. You can pay back in documentation, reviews, and testing—all sorts of ways that don't necessarily involve code. Small contributions are valuable! And eventually you can be the resource for the next newcomer who has questions like you once did.
Opportunism reigns. FOSS development tends to be highly opportunistic, which means your plan for a 10-15 week term may fall apart two weeks into the semester. Recognize that and be prepared.
If it isn't public, it didn't happen. Decisions in FOSS are made only on public artifacts, including mailing lists, forums, and IRC. If it's not public, it's not accountable, and it's not a contribution. Ideas are shared before they're perfect, and that's OK. Get used to public communication, and get your students used to it as well.
Ask forgiveness, not permission. Very little in FOSS can't be reverted. Try new things. Something may turn out to not be in line with the community's intentions, but it may turn out to be interesting and useful to them after all. Branches are free, and sometimes odd experiments have interesting results.
Keep a history. Version control helps a lot—history-keeping should be automatic whenever possible. History helps students understand the project and gives you context for why the project is headed in a particular direction. It also helps someone else pick up where the previous contributor—like a student leaving at the end of a term—left off.
Finally, remember that at the end of the course, it's better to communicate undone work than to do uncommunicated work. Students need to gracefully hand off their work. Have them document what's remaining to do and try to find someone to continue it (and make it better) or leave it in a place that's easy to find with a clear note that it needs a maintainer. The contribution isn't complete until a handoff has been achieved.
POSSE (Professor's Open Source Summer/Software Experience) is professional development for instructors interested in student participation in free and open source software. This post is based on a presentation at POSSE 2013 by Joanie Diggs and Heidi Ellis.