Teaching open source software development principles in universities
From Google Summer of Code Mentor Wiki
We had a delightful session that outgrew our original room and forced us to migrate into the courtyard.
Some highlights from notes scrawled in the sun by Philip Johnson:
There are three stakeholders: the open source project, the students, and the professors. We need to figure out ways to (a) identify projects that are "academia-friendly", identify students with the wherewithal to participate in OS projects; and incentivize professors to do the extra effort required to integrate open source development into their curriculum.
We distinguish between using OS tools in the classroom, which is done all the time, from pedagogy and practices that engage students and professors in OS development. The latter is much more difficult. For many (non-tenured) faculty, their incentive structure does not necessarily reward OS participation (either by themselves or by their students).
There is a google group: http://groups.google.com/group/foss-universities. Unfortunately, this group is not open! One participant in this session is a member and said that there is not much activity. We think that one good direction is to revitalize this group (and make it more open!)
There was the sense that it is important to have a "seed" person in the university organization, either the professor, or else a member of the OS project that can be closely affiliated with the university. This person provides a resource that supports the students/professor in getting familiar with the project culture and practices.
The Haskell Project (http://www.haskell.org/) was identified as one that does an excellent job of attracting involvement from academics and universities. They have a very friendly, welcoming culture, and not disdainful of newbies and their questions. Plus, many of the contributions are "publication friendly", in other words you can write an academic paper based upon what you did. This makes the project much more amenable to academic participation since it is in alignment with the university incentive structure.
We feel that projects that enable a new participant to make a relatively small change and "see" the results are more amenable to university participation by students. Such systems might have a modular architecture or some other kind of design that provides a low barrier to entry.
Drupal (http://drupal.org/) is other OS project that seems quite friendly to newcomers, and also has the property that it is easy to make small contributions that have a visible impact. Good communication, good forums, not much of an "oral tradition", no flaming for asking stupid questions.
One participant noted that a very useful property of a newcomer to a project is a fresh set of eyes on the installation instructions and basic documentation which might contain errors or omissions invisible to more experienced developers.
We believe that there needs to be some sort of meta-level organization to understand and advocate for the integration of OSS development in academia in general. Perhaps help identify "academia friendly" projects, and/or professors who are actively interested in this issue. This mentor summit is an excellent source of people who could take leadership roles in such an organization. There is currently no clear way for the three stakeholders (projects, students, professors) to find each other. Perhaps the foss-universities group could be revitalized/repurposed for this.
Europe seems to be farther ahead of the US on this front. There are large OSS conferences there that are interested to some extent in these issue.
A couple of example project approaches: (1) Take a closed source system that "needs" an open source equivalent. Use that as the basis for writing a specification, then implement it. (2) Take an existing specification (such as an IEEE spec) and provide an open source implementation of it.
(p.s. I attended the Melange session in the afternoon. What occurred to me at that session is that the mentors in GSoC experience (and sometimes solve) each summer many of the problems associated with OSS development in university settings. Melange could thus serve as a mechanism for developing and disseminating "best practices" which could then be adopted in/adapted to academic pedagogy. Conversely, GSoC mentors could "go meta", in the sense of rising above mentorship for their specific projects and starting to support general issues in getting students involved in OSS.)
