How to get a class involved with an open source project | Opensource.com

How to get a class involved with an open source project

Posted 27 Jun 2013 by 

Ruth Suehle (Red Hat)
Rating: 
(4 votes)
open source projects in the classrom
Image by : 

opensource.com

submit to reddit

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.

submit to reddit

4 Comments

Heidi JC Ellis
Open Minded

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!

Vote up!
8
Vote down!
0
bbehrens
Open Source Sensei

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!

Vote up!
6
Vote down!
0
Dan Saint-Andre

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.

Vote up!
4
Vote down!
0
Heidi JC Ellis
Open Minded

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

Vote up!
2
Vote down!
0