Open Source and Plagiarism: What do we Teach Students?

26 December 2017

Some members of our HFOSS team recently submitted a proposal for a discussion session at a computer science education conference. The proposal was to bring together instructors involved with teaching Humanitarian Free and Open Source Software (HFOSS) and other faculty who might be interested in introducing open source to their own students. The proposal was rejected, which was disappointing but not a big problem since rejections are a normal part of life in academic conference participation.

But I was quite surprised by the comments of a reviewer who had concerns about the proposal. The concern centered around open source and potential plagiarism by students. Essentially, the reviewer was concerned that if we teach students about open source that we would be enabling them to cheat by copying freely available source code from FOSS projects. The reviewer was hesitant about the very notion of teaching open source, and felt that a session on open source could not be held without discussion of student cheating it might encourage.

Now, like any instructor, I understand concerns about plagiarism. Cheating in many forms is far too common in higher education, and all instructors are constantly looking for ways to detect and prevent cheating. But from my perspective, there is no easy jump from concerns about plagiarism to concerns about teaching students to participate in open source. In considering this connection, it seems that there are several relevant points:

First, there’s not a shred of hope for a strategy that suggests that we can keep students from plagiarizing code from the Web by not teaching about open source. It’s true that most students don’t really know much about how open source actually works. But they all know that there is lots of source code on the Web – and that it’s as close as their preferred search engine. Teaching open source isn’t necessary for them to plagiarized, if that’s what they choose.

Second, open source provides an excellent opportunity to discuss intellectual property, attribution, and correct and incorrect use of all that code available online. Academic integrity has clear parallels to professional attitudes we want our students to develop. Wouldn’t it be better to make that parallel clear to students as part of helping them develop as professionals?

Third, the reviewer’s comments carry an implication that student work should be individual and done in isolation. Students learning to program do need to spend time writing small programs from scratch, but that needs to be just part of the picture. Students also need to develop understanding and skills reflecting the reality that most software products are team efforts and most software work involves working with large, existing code bases. Unless we prepare our students for that reality, we will turn them loose at graduation with major deficits in their professional preparation.

Moreover, this perspective on professional work is best introduced early in the curriculum. The computing profession is struggling to attract under-represented groups, including women. Research shows that the social aspects of team-based computing work are attractive to women students. Introducing students to open source communities early in their education shows signs of appealing to women students. The humanitarian aspect of HFOSS also seems to have appeal to women and under-represented groups.

HFOSS participation offers excellent educational opportunities for our students. For faculty like this reviewer who hesitate because of cheating concerns, we need to be very clear that teaching open source will not raise the risk of cheating and provides a great opportunity for learning, including opporunity to address academic and professional integrity.