A guide to teaching FOSS: teachers as learners

No readers like this yet.
Leveraging 21st-century education with open source


Knowing everything about any open source project is impossible. If you're going to deal with a large community, you're not going to know all the details. This is unlike teaching courses where everything is black-and-white, and there are plenty of reference texts. If you're going to teach open source, you're going to have to change the way you teach. Rather than a lecturer, you're a mentor.

In these classes, you help guide the search for answers instead of handing them out. And it's OK to tell students that. Simply say, "This is different from other classes you've taken." It's a different learning style, which means they need expectations set so they aren't frustrated in the end.

Similarly, you may learn as much as your students do in the process. You're a co-learner. And that can be intimidating. It's hard to stand up in front of a class and admit you don't know everything you're about to teach. But remember that you know more than you think you do. You know what a good assignment is and what good results look like. You know when a class is going badly. And you know how to ask questions. You have the skills and tools to do this; this teaching is just a little different from the usual process.

Position yourself as a learner to your students. Explain that there may be areas in which you don't know the answers. But what you do know is where to find the answers and how to keep the learning on path. Explain the benefit of life-long learning. Then put them in the instructor role. Have students learn and then teach.

POSSE 2013

Be opportunistic in your instruction. Conference or meeting happening nearby or affordably? Declare a FOSS field trip and go! If a conference isn't feasible, visit the local user group meetings. Remember that not every such event will be a win. But if nothing else, you'll learn about a group's culture and something that isn't the right approach for your students. Alternately, you can invite FOSS developers into your classroom or host a hackathon at your school. Bring the FOSS to you.

Of course, all of this leads to a degree of unpredictability in your course. What happens if your contact leaves the project or the project has architecture changes or gets forked? What if you discover the scope was too large before you're finished? In general, the answer is to be flexible and work with the community. Find a new contact. Figure out how to make your deliverables work, or figure out where you can continue to fit in the project.

You can avoid some of the problems of unpredictability by planning for it, as strange as that sounds. For example, don't work on anything in the critical path of the project. That means your students aren't under the pressure of the project in addition to their grades, and if something goes awry, the project isn't affected. (The community is unlikely to support your class' involvement in that way anyway.) Start small. Identify several small contributions rather than one large one. You can even have students estimate the time they'll think it'll take. This will also help you avoid schedule creep problems.

When it comes to evaluations, define the rubric when you define the assignment. Create a grading checklist for yourself based on it. You can, however, also separate the grade from whether or not the task was accomplished. Grade on the quality of presentation. Get feedback from the community to help with your evaluation.

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 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 is a very interesting post. I am no teacher, but as an active contributor to open source projects e.g. communities, I can see this concept of taking the learners-seat instead of the teachers-seat applied to other roles in projects/communities.

Community managers, developers, forum moderators, they could all benefit from taking a seat *next* to a member instead of opposite to them. It would be the open source way of guiding another member, in whatever role you are, and whatever task you have at hand. To learn from each other in this way can be very rewarding.

It totally agree it would be a rewarding open source way of learning/teaching, i.e. through a guided horizontal exchange, with roles not so clearly defined.

One of the main reasons that drove me to open source was the truly anti-authoritarian and creative acceptance of uncertainty, where locally defined problems are addressed in dynamically distributed ways.

I'm putting the first sentence of this article on a (virtual) post-it note. It is so important to remember that we don't/can't know everything, both in the classroom setting and when working on open source software as part of the development/support community. The best teachers and open source support people I've worked with were the ones who knew how to say "I don't know, but let's find out together". Every single time, they managed to figure things out, but, if they didn't have the humility to say "I don't know", they might not have be able to do so.

There's a recent book related to this teaching/learning concept in general (not specific to FOSS):

Thanks for this post.

I would add as a teacher: Help me to know better.

The teacher by experience put the group of learner on the start and the teaching effort is done by guiding the collobaration to learn together to acheave a goal.

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