The scarcity of college graduates with FOSS experience

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

In the education track at SCALE 14x in Pasadena, Gina Likins spoke about the surprisingly difficult task of getting information about open-source development practices into undergraduate college classrooms. That scarcity makes it hard to find new college graduates who have experience with open source. Although the conventional wisdom is that open source "is everywhere," the college computer-science (CS) or software-engineering (SE) classroom has proven to be a tough nut to crack—and may remain so for quite some time.

Likins works on Red Hat's University Outreach team—a group that does not do recruiting, she emphasized. Rather, the team travels to campuses around the United States and engages with teachers, administrators, and students about open source in the classroom. The surprise is how little open source one finds, at least in CS and SE degrees. Employers expect graduates to be familiar with open-source projects and tools (e.g., using Git, bug trackers, and so forth), she said, and incoming students report expecting to find it in the curriculum, but it remains a rarity.

Likins identified several practical obstacles that, based on the team's conversations with instructors, seem to stand in the way at many schools. First, instructors generally do not have the freedom to create new courses. CS and SE degree plans tend to be packed as it is, designed to cover a set array of topics with little wiggle room. And that limitation is on top of the usual restrictions on instructor time, classroom space, and departmental budget. Furthermore, there is the chicken-and-egg problem: "open source" as a topic is not well-established, so creating a new course to address it is largely undocumented and more time consuming than other potential new topics.

Second, the existing CS and SE curriculum guidelines do not include open source and do not leave sufficient room to incorporate it as an add-on topic. In a sense, of course, this problem overlaps with the preceding one, since departmental degree plans tend to have little flexibility. But Likins highlighted a more specific issue: there is only one "standard" for CS curriculum available, and it is published by the Association for Computing Machinery (ACM). Thus, the ACM guidelines are essentially the only ones in use, and in the 518 pages of detailed topics, open source is addressed only once. That occurrence is the "Foundations of the Open Source Movement" sub-topic, which is one elective among seven sub-topics within the "Intellectual Property" topic, itself one of ten topics within the "Social Issues and Professional Practice" knowledge area, which is one of 18 "knowledge areas" in the guidelines. In other words, open source is not exactly a central issue for the ACM.

Third, many instructors exhaust their available spare time working on publishable research (either for tenure and promotion or for grant support), and open source is not a topic that is covered in any research journals or at any academic conferences. Most of the CS-related journals and conferences are run by the ACM, Likins said. In addition, few technology journals are interested in research about educational techniques and no education conference has an "open source" track. Put together, these factors leave instructors interested in open source with nowhere to take their research.

Fourth, open-source projects simply move at a different pace than academia. While six-month cadences have been the norm for distribution and large-project releases over the past few years, she said, academic departments tend to plan four years ahead. While open-source software events often have call-for-papers (CFP) deadlines a few months before the event, academic conferences like that of ACM's SIGSCE (the Special-Interest Group for Computer Science Education) have CFP deadlines a full year out. Since open source moves so fast, it is difficult to plan material so much further out on the calendar.

Fifth, CS and SE instructors tend to be risk-averse. Few have any experience with open source, which makes it awkward to bring up in a course—lest the instructor get stuck on an issue to which they do not know the answer in the middle of a class. Most instructors are kept busy enough by their teaching duties and research that they do not have time to set aside for learning open-source tools and concepts.

What to do

After painting the rather dire picture of open source's absence in the undergraduate classroom, Likins went on to list several things that interested community members could do to make a positive impact. The first was to support programs that introduce instructors to open source. There are several such endeavors. Red Hat runs a summer short course called the Professors' Open Source Software Experience (POSSE) and OpenHatch has run workshops called Open Source Comes to Campus in the past (although it appears to have no such events planned for 2016). POSSE is supported by a US National Science Foundation (NSF) grant and is free for instructors to attend.

Formal programs like POSSE may not be an option for every instructor, though. Likins noted that, on several occasions, the University Outreach team has encountered universities with official "incubator"–style programs run with industry partners and requiring a six-figure buy-in from each company just to be allowed on campus. Fortunately, there are also several online resources for instructors, such as Foss2serve (which hosts classroom materials and teaching aids) and TeachingOpenSource.org (which is a community forum). She also encouraged attendees to share success stories, since many educators face the same basic questions when they first look at open source as a topic (such as how to grade students' work when that work is part of a larger, collaborative project).

There are also several areas of direct "evangelism" that tend to bear fruit, she said. One is encouraging instructors to teach version control—a topic that, surprisingly enough, is often overlooked, but serves as an excellent gateway to open-source concepts. Another is to tell recruiters at one's employer to ask about open-source software contributions when they talk to universities. For instance, asking a CS or SE department if its students have GitHub histories.

Community members can reach out to nearby universities on these topics, but they can also encourage schools in other subjects that relate to open source. There are several other movements that address openness and transparency in the academic sphere, such as open-access research and open data.

A lively question-and-answer period ended the session. Audience members raised several other possibilities for getting open-source concepts into the classroom, such as reaching out to vocational and technical schools. One audience member who is a CS student at a nearby university suggested engaging with teaching assistants (TAs). Her class had studied version control with Git, she reported, but it was taught by a programming class's TA, not its professor.

Other audience members pointed out that there is already a strong presence for open-source software in other places in universities, such as in IT programs. Lance Albertson of Oregon State University's Open Source Lab (OSU OSL) commented that the lab had started in a non-academic division of the university and only recently had made inroads into the activities of the undergraduate CS program. He also noted that a great many universities embrace open-source software in a big way at the Masters and PhD level, but it still does not filter into undergraduate curriculum.

The disconnect between undergraduate CS and SE programs and the open-source community is a perplexing problem; one without a simple solution. On the plus side, the community is taking the issue seriously and working to bridge the gap.

