The open source learning experience
David Nalley
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
# whoami ●
●
●
Community Manager for CloudStack at Cloud.com Fedora contributor (docs, packaging, ambassadors, marketing, infrastructure, various governance positions) Developer behind several virtualization monitoring extensions for Zenoss
●
Recovering sysadmin
●
Involved in a few other projects.
Why opensource in .edu is powerful ●
Larger effect
●
Not hidden by NDAs
●
Becomes visible work experience
●
●
Forces collaboration at a level that class can't provide. Lots of other reasons the speakers here will give you
The dangers and problems Experiential learning using open source is fraught with opportunities for Bad Things (TM) to occur.
Unfamiliar ground for Professors â—?
â—?
F/LOSS is not busy work you can send students to go make great things happen. Students being sent in sans professor involvement invariably ends in failure (for student, class, and open source project)
Why is it unfamiliar ●
●
Participating in F/LOSS projects tends to take time Ramp-up isn't always easy
Open Source projects want to help ● ●
Wait – why is this a problem?
Open Source Projects want to help ●
●
●
F/LOSS participants understand that failure is part of the learning process. F/LOSS projects tend to not discriminate on a persons education, experience, etc. and when there is no history of actual work, they tend to give people the benefit of the doubt. F/LOSS participants will actively help your students fail in ways they never imagined possible (not necessarily bad, but certainly disheartening.)
Inappropriate tasks/efforts ●
●
●
Most students are not ready to make commits to the Linux kernel or a major database. (and there are long term maintenance issues as well) Most participation shouldn't be core – it should be legitimate peripheral participation. The actual steps to get work done should be at least generally known. (i.e. editing a web page requires more knowledge than HTML)
Bad Open Source Projects ●
●
Not all projects can absorb students, or even would if they could. Some projects are somewhat gruff with newcomers.
Students don't understand the need for communication â—?
â—?
Because F/LOSS projects are widely distributed. They fall apart when communication stops. Most participants will never meet in person, the really fortunate ones will meet their peers once a year. Students are used to being given assignments and then going off to do them, and turning them in when done. That will fail in open source.
Fixing it ●
●
●
●
Professors should get involved in an open source project. Ideally 6 months before a student will. Professors who want to fast track their (and their classes) success will attend POSSE Professors should choose a limited subset of projects for appropriateness and work to find suitable tasks. Open Source projects should assign mentors to those students
Fixing it â—?
â—?
Expectation with the students should be set so that they will be reading the mailing list every single day. That they will be on IRC any day in which they do work on the project The expectation for students should be that accomplishing $task is only about 33-50% of the total involvement.
Resources ●
●
Teaching Open Source (teachingopensource.org) POSSE – Professors Open Source Software Experience
Questions, contact David Nalley ●
david.nalley@cloud.com
●
david.nalley@fedoraproject.org
●
ke4qqq on irc.freenode.net