The sun could not have been shining any brighter in Philadelphia on May 28, 2014. But in the basement of Drexel University's Rush Building, home to the school's College of Computing and Informatics, matters were a bit more hazy.
Inside, a cohort of nearly 20 faculty from colleges and universities across the country debated the merits of designing courses that embed students directly in free and open source software communities. Heidi J. C. Ellis, Chair and Professor in the Department of Computer Science and Information Technology at Western New England University in Springfield, MA, and Gregory W. Hislop, Associate Dean in the College of Computing and Informatics at Drexel, convened the group as part of this year's Professors' Open Source Summer Experience, a three-day immersive conference for faculty wishing to enhance their students' learning experiences by introducing them to open source tools, projects, and values.
Ellis and Hislop explained to their colleagues the wonderful benefits of linking students with open source projects. But the decision to teach students the open source way is never clear-cut, they cautioned, for it introduces a number of unique challenges into the classroom.
For example, open source projects are complex—in terms of both their code bases and the tools their communities use to collaborate. Getting students up to speed might take weeks—even months—leaving them little time in an academic term for making concrete contributions to a project. Communities also embody particular characters: norms, values, and prefered methodologies that one can learn only through extensive participation in them. Projects' respective release schedules may not neatly overlap with the classes' academic calendars, making joint work even more difficult. And, students enter their computer science classes possessing varying degrees of familiarity with tools and platforms, so setting up a development environment suitable to everyone can be tricky indeed.
The joy of tinkering
Jim Kiper from Miami University in Oxford, Ohio, had an additional concern: What were the consequences—for his students, his department, his university, and his chosen open source community—if class participation in a project backfired, introducing frustrating complications or even derailing the project altogether?
Colleagues like Cam MacDonald of MacEwan University, Canada, who has involved students with open source crowd mapping and visualization software Ushahidi, were quick to allay Kiper's fears. Open source communities' extensive use of version control forms a failsafe for the kind of devastating mistakes a student might accidentally introduce into a project's code, they said.
"In any project worth its salt, that can't happen," MacDonald explained. "That'd be like the nuclear power plant letting the intern run the plant on the weekend."
So professors should encourage their students to dive into open source code repositories and begin to tinker, imagining how they might meaningfully contribute to a project. Toying with open source code for real-world applications is a learning activity with unparalleled benefits, POSSE members said.
By participating in these projects, students not only sharpen their coding skills, but also learn how to work with teams distributed in remote locations. They become more familiar with intellectual property and software licensing issues, Ellis said, and must acquire working knowledge new domains—like cryptography, health regulations, or bioinformatics—if they intend to to grasp a project's purpose (not to mention its constraints).
Contribution beyond code
But students needn't simply submit code to open source projects. They might confirm bugs, update documentation, design new logos or icons, test new features, or simply assess an application's accessibility features.
Ellis, whose students have contributed to Caribou, an on-screen keyboard that's part of the GNOME desktop, explained that seasoned students often prefer to submit patches to projects, while beginner-level students are more content to interview existing contributors, explore collaboration technologies like Git or IRC, and embark on what Ellis calls open source "field trips"—toe-dipping excursions into various communities, where they might lurk for a bit to get a sense of how open source development really occurs.
Through it all, Ellis and Hislop stressed, professors must remember that open source communities are available to assist their students. They'll guide students through the code for their projects, answer student questions, or meet with them on IRC. But to completely leverage the benefits of these communities, professors must get comfortable with the prospect of their pupils interacting with individuals outside the traditional teacher-student relationship.
"It's a different style," Hislop told the POSSE cohort. "And some people just aren't comfortable with that style."
Doing computer science coursework the open source way does expose a class to the kind of unpredictability and flexibility that's part and parcel of open source development. And yet POSSE attendees agreed: teachers and students alike benefit from engaging with open source communities. Some lessons just can't be outlined in a syllabus.