I was at Drexel University in Philadelphia last Thursday and Friday participating in the SoftHum Workshop on Involving Students in Humanitarian Free and Open Source Software Projects (to use its official name). I was there representing Mozilla, and in particular to talk about our Mozilla Education initiative; I was one of the folks invited to provide the open source project perspective, along with Greg Dekoenigsberg of Red Hat and the Fedora Project and Darius Jazayeri of the OpenMRS project.
It was an interesting workshop, and I thank the organizers, Greg Hislop of Drexel and Heidi Ellis of Western New England College, for inviting me. Here are some quick thoughts arising from the workshop:
Institutional interest. The attendance list for the workshop confirmed that a lot of the interest in teaching open source is coming from smaller colleges and universities, both private liberal arts institutions and smaller state institutions. (In the latter case “small” is relative; I mean small relative to the major state universities.) This is not surprising to me; as I wrote in my original post on Seneca College, disruptive innovation theory predicts that larger and more research-oriented institutions will be the least likely to innovate in terms of teaching open source practices.
The downside of having smaller institutions involved is that at a typical institution perhaps only one or two faculty members may be interested in teaching open source, and they won’t necessarily have a lot of institutional support and resources backing them up in their efforts. This reinforces the importance of having people like Dave Humphrey, Chris Tyler, and others who can bridge the gap between the academic world and the open source world and support faculty members just getting involved in open source efforts.
Humanitarian orientation. I initially thought that the emphasis on the humanitarian applications of open source software embodied in the HFOSS project was somewhat irrelevant to the overall task of getting the teaching of open source development into college curricula. However it’s now clear to me that from the perspective of liberal arts students and faculty it’s important that they work on projects that have a direct positive impact on the lives of people who are not as well situated as they are. This is somewhat at odds with the classic open source tropes of “scratching your own itch” and developers developing for other developers. There are open source projects that were created primarily for humanitarian purposes (e.g., the Sahana software for managing disaster relief efforts) as well as humanitarian aspects to more general-purpose open source software (e.g., the various Mozilla accessibility activities), but most open source projects, including many major ones, have no obvious humanitarian angle.
(I should add here that while activities to promote the open web and the participatory Internet are clearly of public benefit, these don’t yet resonate as strongly from a humanitarian perspective, at least with the liberal arts students and faculty who are interested in open source. I think we should look at what we can do to more clearly tie these goals to other goals like economic growth, building social capital, promoting personal development, and so on.)
Joining a project vs. creating your own. One of the major issues that arose during the workshop (sometimes explicitly addressed and sometimes implicit in people’s choices) was the appropriateness and feasibility of having professors and students join and contribute to an existing open source project as opposed to starting a new project on their own. I think part of this relates to the concern faculty has about the difficulty of getting up to speed on an existing project and finding useful and doable activities for their students to get involved in. I think the best way to address this concern is through providing personalized support for faculty and useful information targeted to students—basically what we’ve been trying to do in the context of Mozilla education.
Other aspects of this are related to control, comfort level, and humanitarian orientation: For example, several institutions have done (or are proposing to do) development projects for local non-profit groups, e.g., creating a web site and associated web applications for them. These projects are presumably appealing because they are self-contained and relatively well-scoped, offer students a chance to do an entire project from analyzing requirements to prototyping, development, and testing, and are done for clearly deserving clients.
However while such projects may make students more familar with working with open source software (e.g., the LAMP) stack, Ruby on Rails, and so on) and perhaps some familiarity with open source-related topics such as licensing (e.g., of the developed software), they do not in my opinion offer as intensive and useful an introduction to open source practices as could be add by contributing to an existing project. Here again we have to meet the challenge of making it more attractive for faculty and students to work within a project like Mozilla instead of working on their own.
All in all I thought this was a good meeting, and well worth my attending. I look forward to participating in similar events in future, including the Red Hat-sponsored POSSE program and the Teaching Open Source Summit to be held in conjunction with FSOSS 2009.