How to get a class involved with an open source project

No readers like this yet.
word learn in chalk on blackboard

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.

POSSE 2013 discussion

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.

User profile image.
Ruth Suehle is the community leadership manager for Red Hat's Open Source and Standards team. She's co-author of Raspberry Pi Hacks (O'Reilly, December 2013) and a senior editor at GeekMom, a site for those who find their joy in both geekery and parenting.


This June's POSSE cohort is making great progress on various HFOSS projects including OpenMRS, GNOME Accessibility projects, Sahana, and Ushahidi. Another POSSE is planned for spring 2014 so keep your ears open for the announcement!

That's great to hear, Heidi. Have members of the cohort established a Web presence for their projects? Or perhaps they'd like to write something for us so we can highlight the great work they've been doing? Let us know!

In my experience teaching software development in both industry and the academy, I found it crucial that students work on software written by someone else. There are so many opportunities to learn when you encounter code designed and implemented by a stranger. I strive to have two such code migrations during a semester.

Most students immediately want to re-write code they don't understand. The reasons for that lack of understanding include mediocre or poor commentary in the code, difficult to use conventions for identifiers and even coding style. Even the way that source code files partition the components often result in more smoke than light into the components.

Veteran developers will appreciate the vast differences between the code passed off the first time and the code created for the second migration. Second pass tudents adopt an almost universal attitude creating better artifacts because they hope to receive better artifacts themselves. A good lesson learned.

Agreed! Students take the learning more seriously when it is embedded in a real-world project. And the opportunities for learning are myriad.

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