Lessons learned from NCSU FOSS class

Free and open source software (FOSS) is only beginning to find a foothold in computer science departments in North America. FOSS tools may be used in teaching or be the subject of research or special committees, but few departments include courses that introduce students to the FOSS community. As a result, when North Carolina State University created a FOSS graduate course in the 2008 spring semester, it turned to Red Hat to find an instructor with a suitable background of FOSS involvement and university teaching experience. Community manager Greg DeKoenigsberg recommended performance tools engineer Will Cohen, who now looks back at the experience with an eye to how what he and his students learned might help other instructors.

Cohen says he taught Open Source Software Communication (CSC 591W) as a graduate course to nine students. Eventually, the course may be offered to undergraduates, but Cohen says that this spring’s format was “more a case of making sure we get the mechanics down, and the course material.”

Teaching about FOSS at the graduate level simplified Cohen’s role as instructor in the first offering of the course. He says, “If you teach an undergraduate course, you have to be more concerned with accreditation requirements in terms of the design and test requirements.” Moreover, because of the emphasis on direct experience, the course had an open-ended structure that would be more comfortable for graduate rather than undergraduate students, to say nothing of being easier for Cohen to grade because of the much smaller size of graduate courses. Nor, on the graduate level, was there much need to worry about prerequisites — students either had the programming skills to participate in the FOSS community, or else could be safely assumed to be capable of quickly picking them up.

Just as importantly, a FOSS course could benefit graduate students most. Not only could grad students “leverage existing software for their own research purposes,” rather than writing what they needed for themselves, but their code could potentially find a larger audience.

“If you take a look at some software projects that students work on,” Cohen says, “they may have something that’s really great and interesting, but it never gets very much exposure because it’s built in their own little lab and only really gets used in the lab.” Instead, by contributing to a FOSS project, students could both get more peer review and have a portfolio sample when they start to look for employment after graduation.

Lectures and hands-on work

Cohen taught Open Source Software Communication in two parts. First, in the regular schedule of lectures, he introduced basic concepts of the FOSS community — both the tools, such as bug-trackers and version control systems, and the culture, including such concepts as how project members communicate and the etiquette of interacting with them.

As textbooks, Cohen used Karl Fogel’s Producing Open Source Software, supplemented by
Eric Raymond’s The Cathedral and the Bazaar and Lawrence Rosen’s Open Source Licensing: Software Freedom and Intellectual Property Law. All, appropriately enough, are available in free online versions. Cohen also made extensive use of other Web pages throughout the course.

The midterm and the final exams were based on material covered in the lectures and the textbooks. However, two-thirds of each student’s grade was based on their involvement with a FOSS project.

Project involvement was broken down into four assignments. Together, the four assignments led to progressively greater involvement in the community.

In the first assignment, students were asked to pick a FOSS project that fit their research interest. In the second, they were asked to become familiar with the project’s bug-tracking system and fix some simple bugs. “The idea,” says Cohen, “is that some of the bugs should be fairly easy to address and would give students the ability to do something useful, but not something so complicated that they got tied down.”

In the third assignment, students were asked to participate in testing for the project, and perhaps to construct some tests “to help give them an overall view of how things work in software.” In the fourth assignment, students had to propose and add a feature to the project, so that they could learn about patches and experience peer review and other common features of FOSS projects. In both these assignments, one of the key roles for Cohen was to “talk with students and get them to aim for things that were of reasonable scale.” Another was to encourage students to become involved in the projects they had selected, since “if a student’s passive, [the course] is not going to work very well.”

While doing these assignments, students were required to post weekly reports of their activities for both Cohen and the rest of the class. This process helped class members to create their own community during the course — where, for example, a student unsure of how to submit a patch could get help from someone else — and also eased Cohen’s efforts to track what each student was doing.

Even so, Cohen describes student evaluation as unorthodox compared to a regular class. “Things were much less self-contained for this class,” Cohen says. “In a traditional class, when someone turns in an assignment, the expectation is that the work is all their own, but I was actually encouraging students to communicate with other people and not work in a vacuum.” Similarly, unlike a traditional team assignment, “for the most part, I was only looking at one person on the team” — that is, the student in the class and not all the members of the project.

Lessons learned

Since school ended last month, Cohen hasn’t checked to see how many of the nine students in the class are still involved in the projects of their choice. However, he notes that one student who worked on SQLite’s autoconfig was asked to maintain it temporarily, and that one or two students who are employed in the software industry told him that the course helped them to understand how they could use FOSS in their work. Overall, the course appears to have been at least a modest success, and, partly on the strength of student evaluations, the university plans to offer it again next year.

Looking back, Cohen sees two major changes he would make to the course. “I would probably give more guidance in terms of what to look for when choosing an open source project,” he says. He is considering offering a checklist containing such items as how the project handles contributions from external sources and whether the code repository is available publicly — two items, he found this year, that cannot always be taken for granted just because a project uses a free license. For instance, one of Cohen’s students planned to work with DrJava, only to find that patches were accepted only from those taking a particular class at Rice University, making it impossible for the student to contribute more than bug reports without unnecessarily forking the project.

Cohen is also considering offering a “menu” of potential projects to help orient students on their first assignment. Students would not be restricted to the list, but it would offer them a greater sense of the possibilities. Should the course ever be offered to undergraduates, he might steer all the class to a large project like Mozilla to help him manage the larger number of students, or perhaps spread students around so that the class did not swamp a project with only a handful of core contributors.

One thing that he does not want to do is create a project solely for the purposes of teaching. “I wanted to avoid the situation where projects have a life that starts at the beginning of the semester and ends at the end of the semester,” he says. Such a project would defeat the purpose of giving students real life experience.

However, none of Cohen’s experience in this first semester make him believe that the course is not suitable for undergraduates. “The material itself is not purely graduate level,” he says. “I would look at the class as a way of apprenticing students, allowing them to work on actual projects and do useful work with some guidance.”