This is the story of a college class taught inside an open source community. Last fall, I taught Release Engineering to a small group of undergraduates at Olin College, an engineering school a few miles outside Boston. The goal was to teach them how to become functional technical contributors to an open source project–without writing any code. In the hopes that others will be inspired to teach similar classes, I’ve written our experiences up as a case study in three pieces: cultural, technical, and "getting real."
The cultural
My students all came from different backgrounds, so we started the semester by diving into some of the cultural particularities of open source communities reading pieces such as "the Cathedral and the Bazaar." See our reading list and notes from the first session.
We grappled with concepts such as "scratch your own itch," "radical transparency," and "release early, release often." (See a more detailed list of concepts.) Experienced open source contributors practice these cultural norms daily and often take them for granted, but norms vary from community to community and might not be immediately obvious to newcomers. When going into a new environment, it is important to know how not to offend.
The technical
The technical meat of the course came in a strange format: packaging–the art of getting an application into a distribution’s repositories. Although the task of packaging is at the core of every Linux distribution, it is unusual outside the world of open source, so many (if not most) computing majors will never experience it. So why teach packaging? It’s a complex task that depends on knowing and using a large number of key skills in release engineering, but it can also be done in a very short period of time, in a matter of hours or days–you don’t have to wait through an entire 6+ month release cycle.
For instance, dependencies need to be tracked and kept up to date, meaning that students quickly get a firsthand knowledge of the chaos that ensues when developers independently decide on API changes that break compatibilities. Patches need to be maintained for accuracy. Bundled libraries need to be cut out without damaging the actual application. Things like "documentation" and "version control" and "modular design" become painfully relevant instead of abstract values students know they "should" follow but don’t see the reason for. However, I do want to point out that these materials are designed to be taught by an experienced packager and release engineer; as with many arts, engineering is best taught through apprenticeship. Since I’ve been doing release engineering in major open source projects (including Fedora, the project where my students worked) since I was 16, I was able to guide them through. CS professors may want to find one or more community liaisons to mentor their students through these sorts of activities.
Real projects and interactions
As their large project, my students packaged the programming language io. In order to facilitate teamwork, I required them to write the configuration file in Etherpad, a collaborative text editor. This way, they could see at all times what the other students were doing, ask questions, and launch into a conversation. Control was not solely in the hands of a single student holding the computer. The experiment worked quite well. They returned with a set of very precise questions and an almost-complete configuration file, which was farther than I’d expected. We eventually found that the package was already part of Fedora. (Read more details.)
By the end of the semester, my students had interacted with the open source community primarily through IRC, but I also wanted to show them that in-person events were also valuable. So when Fedora Engineering Manager Tom Callaway gave a talk at the nearby Western New England University, we organized a field trip. Tom’s talk, "This Is Why You FAIL," (inspired by this chapter of The Open Source Way), was a hit. Having someone else explain to my students now not to Do Things Wrong was powerful. The Western New England students seemed to think so too.
Many teachers, many thanks
One of the best parts of teaching open source is that your students get to learn from many people, not just you. I’d like to express my gratitude to Tom "Spot" Callaway and all the Fedora contributors who answered my students’ questions online, as well as to professors Allen Downey, Heidi Ellis, and Zhenya Zastavker for being models and mentors for my own teaching.
