The scarcity of college graduates with FOSS experience

By Nathan Willis
February 3, 2016

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.

Index entries for this article
Conference	Southern California Linux Expo/2016

to post comments

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 2:03 UTC (Thu) by deater (subscriber, #11746) [Link] (2 responses)

What about Computer Engineering programs?
Lots of open source use there, as computer engineers actually build things.

Computer Science is mostly theory. Being upset by the lack of open source exposure there is similar to being upset that the math or physics departments aren't pushing open source.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 3:09 UTC (Thu) by danielkza (subscriber, #66161) [Link]

The distinction between SE and CS is much blurrier in practice, and in many cases there is not an option between either - only one is available, so content from both is mixed, proportion varying wildly depending on location and course background.

Either way, FOSS can still be quite valuable even looking strictly at CS. It includes many areas of research that do involve constructing software, even if purely for exploration, evaluation of practical applicability, or a subject onto itself. Knowing and using tools that are freely available means the results are much more accessible and useful for other researchers.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 15:08 UTC (Fri) by jhhaller (guest, #56103) [Link]

The software engineering curriculum was reissued in 2015 - se2014.pdf. It has several references to open source, in particular in curriculum guideline 5, "Learning certain software engineering topics requires maturity, so these topics should be taught toward the end of the curriculum, while other material should be taught earlier to facilitate gaining that maturity.", with the reference "students also need practical material to be taught early ... such as ... open source project participation"

This curriculum guideline is a joint effort between the ACM and IEEE Computer Society, and appears to be evaluated/updated every 10 years. The next cycle will presumably start in 2020, and complete in 2024 with publication in 2025. Courses and curriculum will be updated following the guideline publication, as things move slowly in academia. The process for participation in the curriculum is open, but any additions to curriculum has to be accompanied by removing others, so that a degree won't take 5-6 years to complete. Not all of the coursework will be in the department of the degree, and some of the material is elective, to allow students to specialize in their interests, leaving only some time to have the same baseline for everyone.

One of the important distinctions is the difference between computer science and software engineering. Many of the incoming students really don't understand the difference, and may pick one curriculum over another on matters such as whether they have to take a chemistry class or not. There is a difference between math department instruction and engineering department instruction, and student need to pick a curriculum (and even university) before they find this distinction, and it's hard to change once they pick it. The link above has a better description of how software engineering has evolved from computer science than I could write it it's description of the evolution of software engineering.

Some long-winded observations from an undergrad. student (The scarcity of college graduates with FOSS experience)

Posted Feb 4, 2016 3:01 UTC (Thu) by danielkza (subscriber, #66161) [Link]

I'm fortunate to be enrolled in an undergraduate CS course that uses FOSS extensively (my college even has a FOSS research/development department). Some observations, positive and negative, that I've made over the years (please forgive my verbosity):

1) I've had many colleagues that basically had no real exposure to FOSS, or at least any that they had given any thought to, when joining the course. Yet virtually all assigments were corrected using Linux.

We have two sets of computer labs, one run by the university staff and other by students (which I helped admin for a couple of years). Both have Linux machines available, which is very helpful, but no official help or material was provided about Linux itself or how to set up a personal environment, even from teachers that used it on their laptops.

That caused the interesting situation of most CS students knowing Linux, but not ever using it outside the time they reserved for their assignments in the campus. Which is quite unfortunate, as I personally find the times where I pick projects of my own interest essential to my enjoyment of computing.

2) During my period as lab admin we hosted a couple of events to help people installing or getting to know Linux. We were also available to help people with basically any kind of Linux troubles they had during the school year. But I noticed that some users ran into papercuts, annoyances, or even huge driver messes, and were discouraged from staying with Linux or even gave up altogether. Secure Boot in particular was a huge generator of help requests. Consider how many people will never bother asking for help and will simply give up due to not knowing the particular option to turn off in their BIOS. Quite unfortunate to think about.

3) The CS course's usage of FOSS is a huge contrast to some other courses which seem to suffer a lot from vendor-lock in. In my faculty, that also offers math and statistics courses, many people go to labs for the available copies of Mathematica, or pirate it for personal use. While not a direct comparison, I talked to some people that had never even heard of R, an awesome piece of free-software. They unfortunately didn't even consider they could get a good deal of their work done with FOSS.

The economics and administration faculty is a huge Microsoft shop, and an even worse case of lock-in. It's all Excel from day one, and people naturally will associate a lot of their domain knowledge to it, which I find quite off-putting. In CS a multitude of languages and tools are taught to hopefully let students construct a foundation that does not depend on any particular one. I wonder how beneficial applying similar principles to other areas would be.

4) The aforementioned FOSS center and the professors that participate in it seem to be making some good inroads in influencing material, and I've been lucky to be able to participate in a discipline specifically about FOSS development. In groups, participants were tasked with getting some kind of contribution accepted in a project with an existing community.

Pretty much everyone ran into major trouble setting up development environments, getting help from other developers or even being able to use the mailing lists at all. And the class was mostly composed of FOSS enthusiasts and people with experience with package management, building from source, etc. Even someone that had previous KDE development experience couldn't get much done in Amarok.

The only exception was a piece of Java software (JabRef). Maven may suck in many ways, but it provides a reliable way to set up all the dependencies, even if it means some wasted time and disk space. That is *hugely* valuable for any project looking to get students involved. I'd say any project that doesn't have that *very* well figured out would be problematic in a classroom setting.

---

PS: If anyone is looking for help about FOSS in teaching, spreading awareness, etc - specially in Brazil - try reaching out to CCSL (http://ccsl.ime.usp.br/en) (pt: Centro de Competência in Software Livre, en: FLOSS competence center) - I'm sure they be glad to help in any way they can.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 3:54 UTC (Thu) by admorgan (subscriber, #26575) [Link] (1 responses)

As a member of the ACM, it looks like I might want to advocate for helping frame some of the education goals to at least help with the options of open source. I discovered FOSS my freshman year of college and it was rampant at the University of Missouri Rolla. In 1994 we had the option of booting lab computers into Linux or Windows. Most of my friends chose the latter. Having this option has significantly improved my career.

Reading the article I felt that the interaction of the ACM with the community was misunderstood. While the ACM has a different schedule than many FOSS projects and events they are not exclusive. I have encountered a number of excellent papers based on FOSS, and ideas that were later implemented as FOSS. The big thing to remember is that everyone does not have to work at the same speed to work together.

When I was an undergraduate students do not tend to do a lot of "real world" work in class. Convincing universities to use FOSS tools such as LLVM and GCC seem like obvious ways to begin the dialog. Unfortunately getting exposure to the options outside of corporate buy-in is something that will require working with the standards groups, book manufacturers, and university executives that are profiting from companies trying to "advertise" their wares to new professionals.

The scarcity of college graduates with FOSS experience

Posted Feb 19, 2016 4:15 UTC (Fri) by glikins (guest, #107162) [Link]

admorgan - this may not have come through as clearly in my talk, but I don't fault the ACM for the guidelines being as they are. The scope of what needs to be covered is *enornmous*. We are glad to see that open source is mentioned -- and we are interested in working with standards bodies, etc. as you mention. (PS Greg Hislop was also on that team and is a friend -- think you all do good, and often under appreciated work :-)

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 7:14 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> Employers expect graduates to be familiar with open-source projects and tools (e.g., using Git, bug trackers, and so forth) [..] 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.

Version control and bug trackers are not specific to open-source, they're just basic software engineering. Teaching software engineering sounds even more basic and urgent than teaching open-source.

Academia has low interest for software engineering since it's useful only for products - not for publishing papers.

What's less understandable is when and how Academia lost the requirement for published research to be reproductible; which implies open-sourcing any software involved.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 12:39 UTC (Thu) by JanC_ (guest, #34940) [Link] (2 responses)

Publishing the source code of software doesn't make it open source.

The scarcity of college graduates with FOSS experience

Posted Feb 8, 2016 6:02 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

More than not publishing it.

The scarcity of college graduates with FOSS experience

Posted Feb 10, 2016 18:23 UTC (Wed) by kpfleming (subscriber, #23250) [Link]

It's necessary but not sufficient :-)

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 12:59 UTC (Thu) by dps (guest, #5725) [Link] (15 responses)

My degrees in CS date from a while ago (the most recent is 2003) but I doubt several things have changed:
- Collaboration is not exactly encouraged: what is alleged to be your work on that problem sheet should be yours and only yours. MSc or PhD theses are also supposed to be your own work too, although you might be able get away with some help given it is appropriately signposted.
- Specific technology, both closed and open source, has an expiry date. This discourages teaching it.
- Open source is useless for publishing anything in academic journal and that matters in academia.
- In 6 months time you presumably won't be studying the same modules in a taught course. There is already enough problem fitting things in already. In this context any project large enough to have a bug tracker and version control system probably does not make sense.

A lot of theoretical CS, which you need to know to publish anything, has the nice property that it is much less affected by expiry dates. Quicksort will remain usually faster than heapsort but inappropriate if guaranteed performance is required even if the favored programming language changes. It is probably worth noting that I do have a degree from a known center of theoretical CS, which you can do without a computer, and it was called "mathematics and computation".

Given the range of things called CS I don't think the ACM CS curriculum has that much traction where I live. There was no room for "Intellectual property", period. I am however aware of the difference between patents and copyrights, and some people that claim to know about intellectual property clearly don't. (Copyrights protect expressions of ideas but not be ideas themselves. If you want to protect the idea itself then you need a patent.)

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 13:35 UTC (Thu) by KSteffensen (guest, #68295) [Link] (13 responses)

As a matter of curiosity: why is open source useless for academic publications? I would have thought would be that open source is ideal for publications, since the source is right there and can be freely distributed.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 14:12 UTC (Thu) by deater (subscriber, #11746) [Link] (11 responses)

> As a matter of curiosity: why is open source useless for
> academic publications? I would have thought would be
> that open source is ideal for publications, since the
> source is right there and can be freely distributed.

One would think, but sadly at least in many areas of Computer Architecture and Computer Science source code is almost never published along with a paper.

And yes, this is contrary to the whole idea of science being about reproducing others works.

In fact, if you write to an author of an academic paper requesting to see their source code they will often refuse. Even if the entire point of their paper was some huge chunk of non-reviewed code that they wrote.

This is going to have to change at some point, as it means much of what is currently published in academia is pretty worthless. The change is going to have to come from the top though, as those of us who complain about it from the bottom are ignored or hand-waved away.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 15:19 UTC (Thu) by lgeorget (guest, #99972) [Link] (9 responses)

> One would think, but sadly at least in many areas of Computer Architecture and Computer Science source code is almost never published along with a paper.

I've the feeling that this is starting to change. More and more conferences in CS now require "artifacts" to be published alongside the paper and important conferences such as the Usenix symposium have in their paper template a section called "Availability" where authors are supposed to give a link to the homepage of their software as well as a place to download it from.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 17:16 UTC (Thu) by Shewmaker (guest, #1126) [Link] (7 responses)

It may be getting better, but it is a slow process. Repeatability in Computer Science woke some people up to how bad it has gotten, and they were only trying to build software ... not actually reproducing results. One of my fellow students is focused on enabling reproducibility of systems experiments, and it is a hard problem. Containers and VMs help, but scientists also need to become experts in configuration management in order to make their research reproducible.

Note that only the Latex USENIX template has an availablity section (not the Word template), and the calls for papers I've read recently (ATC and NSDI) don't emphasize availability or reproducibility. It seems to get a little more attention at ACM conferences, but it isn't consistent. For instance, SIGMOD included a reproducibility effort in 2012, but it isn't a part of any call for papers since then.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 9:55 UTC (Fri) by paulj (subscriber, #341) [Link] (6 responses)

Repeatability in CS is a huge problem. Fixing this requires:

1. Improving the descriptions of the methodology, so that the papers contain a complete and clear description of the key details needed to replicate the experiment.

2. Making it worth researchers' while to go to the effort of replicating experiments and publishing them.

The 2nd one is the biggest issue I suspect. At the moment, if you spend your time replicating an experiment, you are actually *harming* your career cause you'll never be able to publish it anywhere significant, and you're wasting time that could have been used on other work that could be published - which is what your competitors are doing.

Also, taking someone else's pile of crappy experimental code does *not* per se help to validate or replicate what they claim in the *paper*. It can confirm the data matches what is published, but it can *not* validate that their methodological claims in the paper are what produced that data. The best way to confirm methodological claims is to *independently* implement them and use that independent implementation to obtain a second set of results. Source code dumps or VM images (neither of which will be reliable over time) could even *discourage* such attempts, and hence *harm* science.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 16:41 UTC (Fri) by Shewmaker (guest, #1126) [Link] (5 responses)

I agree a lot with what you're saying. There need to be stronger incentives to improve the situation, and relying on black boxes (code, VMs, etc.) instead of enabling experiments to be independently verified would be a Bad Thing.

But providing " a complete and clear description of the key details needed to replicate the experiment " is not something well suited to a research paper format. Describing the key details of a particular algorithm is one thing, but it is an entirely different matter for the experimental environment. What are all the relevant system settings? Better to record as much as possible. Code works better than text to describe how a system is set up, and that's why I referred to configuration management. My day job involves being able to guarantee that the installation and configuration of HPC resources is automated, and an abbreviated version of the written instructions spans dozens and dozens of pages. Invariably, those written instructions are out of sync with reality.

I want both a clear description and the code necessary to replicate research and compare it against other research.

I think it is critical to teach students about Open Source (the mentality, as well as the tools). Whether they continue in academia or not, they will be much better equipped to improve the state of the art if their work can be used, modified, and built on. Too much research is interesting, but not useful.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 16:51 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

If there are system settings that are critical to the claims of the paper, then those settings should be in the paper. How many could there be?

The point of scientific papers is to distil and communicate knowledge in the most clear, succinct and precise way possible. As such scientific papers *should* present the *key* details needed to validate some claim. A paper without them is not a scientific paper, surely?

How does it serve science if we start to allow important scientific claims to be hidden somewhere in the bowls of GiBs of a VM image? Potentially splatted over a bunch of configuration files or, worse, experimental code?

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 19:56 UTC (Fri) by Shewmaker (guest, #1126) [Link] (3 responses)

Of course I want paper authors to do their best to present the key details well. I want *both* a clear description and the code necessary to replicate research and compare it against other research. To me, that means experiments are under configuration management because the number of important system settings is potentially huge. And I'm not talking about ad-hoc systems management — changes made to an installation are all organized and kept separate from an image. Everything is automated.

With both code and configuration management I can independently verify the key details the author of the paper described. Otherwise, if I can't replicate their results (with or without an independent implementation), then I can't be sure that some unknown key setting didn't cause the change in behavior. It could be as simple as the version of the C library, or as subtle as the amount of memory pressure causing the C library's qsort function to switch from merge sort to quicksort. Look under /proc/sys and tell me which settings are key to an experiment, which ones change between kernel versions, and tell me if you fiddle with every one of them independently and in every combination to prove that they do or do not affect your experiment. Repeat that for /sys, your environment variables, and every library and application setting.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 22:37 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

How many settings are they changing from the defaults that this is an issue?

There are obvious solutions to this. Reference a base distro. E.g. an EOL Fedora distro that is guaranteed to no longer change. Then document any settings changed from the default.

If the number of settings that are being changed is extra-ordinarily high and too many to document in a paper, then I suggest there may be a problem in the experimental design. E.g., a more differential approach that isolates the effect of different settings to determine which settings actually /do/ need to be changed would be good, so that the main evaluation for the paper can just depend on a couple of settings.

Again, if experiments are dependent on hundreds of different tweaks to variables in the base system, then that sounds like a *different* problem. ;)

The scarcity of college graduates with FOSS experience

Posted Feb 8, 2016 16:45 UTC (Mon) by Shewmaker (guest, #1126) [Link]

An EOL distro, sooner or later, won't be able to run on new hardware, won't provide versions of software that are relevant, and will quickly become a security risk. So, the obvious solution isn't a good one if you want to enable others to replicate or build on top of your research.

Let's consider two scenarios. The first is an experimental high performance distributed system that pushes the limits of CPU, memory, network, or storage resources. The second is an experiment in which the researcher is primarily focused on the functionality of their non-system program. In the former case, there are potentially hundreds of different variables to tweak and I don't find a claim that only a handful of variables matter believable — especially when just the functional setup, without performance tuning, of one of those systems may take pages to explain. In the latter case, the researcher isn't a systems expert and I don't trust that they know what characteristics of the system matter.

I'm more concerned with the potential of settings being missed than with the number of settings in any given experiment. And I think that Open Source and research into how to help researchers enable and encourage replication of experiments is critical to improving the state of the art.

The scarcity of college graduates with FOSS experience

Posted Feb 8, 2016 17:27 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> How many settings are they changing from the defaults that this is an issue?

How do you know 5-10 years from now know what the defaults were on the particular system that a test was run on and how those would have affected the results of the testing, all those defaults, some of which are auto-tuned based on the properties of the box the kernel finds itself in, how do you replicate results without documenting all of those underlying assumptions, if you get a different result on a newer kernel or different hardware, which of those underlying factors is the cause?

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 21:11 UTC (Thu) by karkhaz (subscriber, #99844) [Link]

It is happening, but slowly. A few conferences in the field where I work have an "Artefact Evaluation Committee", whose job it is to run the tool that accompanies the paper (or the mechanised proof, or whatever other thing you have to support your work). However,

* At every conference I've seen this at, it is optional: you don't have to submit an artefact to these conferences

* Having a 'working artefact' is not a prerequisite for having your paper accepted. In fact, the artefact evaluation process only happens to the artefacts of _accepted_ papers, i.e. after the decision has already been made.

* Actually doing the evaluation is a hell of a lot of work, and the people doing the work end up being miserable PhD students :(

The point of it is to get a cute badge [1] on your paper, showing that you've submitted an artefact for evaluation, which carries some amount of prestige.

[1] http://i-cav.org/2015/evaluation/

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 22:44 UTC (Thu) by kamil (guest, #3802) [Link]

Things are changing. For example, the US Department of Energy, a major source of research funding in the area of High-Performance Computing, *requires* source code of research project artifacts to be released, under an open-source license (BSD-style is the most common). I think that's actually more important from the FOSS point of view than the reproducibility of journal results.

Going back to the original point of the article about "college graduates with FOSS experience", I think the best we can realistically hope for is that students use FOSS tools where practical and appropriate. Specifically teaching about Open Source may not be realistic. There really are more important things for students to grasp first -- many entering a CS program have no idea about basic algorithms and data structures.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 9:46 UTC (Fri) by paulj (subscriber, #341) [Link]

Free software is *massively* useful to getting academic publications and extremely widely used. As a building block that is, for researchers to create their own experiments with.

Researchers publishing their own code for the experiments they base papers on is much less common. There's a number of reasons for that, including that experimental code is often very hacky; the fact there is generally next to no incentive in academia to take the time to clean up your code to release it; researchers being wary of giving code to competitors; researchers thinking they might one day commercialise the code; etc.

That said, it is becoming slightly more common to provide source code. There has already been a push by funding agencies (at least in UK and EU) for open-data, requiring that data be fully published as part of funding, and there are similar policies sprouting to at least encourage code to also be released.

I think it'd be good to see more code being released. However, I disagree with the argument that it is needed for science - I think it'd be bad on the scientific side actually if it started to become acceptable to refer people to code rather than clear descriptions of the methodology in a human language in the paper.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 9:40 UTC (Fri) by paulj (subscriber, #341) [Link]

You can use as much open source / free software as you want in a masters or PhD, as long as it correctly and clearly attributed. The thing is that you must _add_ enough of your own contribution on top or besides that to earn the degree.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 14:19 UTC (Thu) by deater (subscriber, #11746) [Link] (3 responses)

I would like to say that I do think having an open-source focused academic conference or journal would really help many researchers. It really needs to be a conference that is peer-reviewed and has published proceedings. The last conference that really met this was Ottawa Linux Symposium, which sadly is no more.

For academics aiming for tenure you really need papers in peer-reviewed printed form for them to count. This is unfair, but unlikely to change.

I often try to write Linux related papers and send them to the more mainstream IEEE/ACM/USENIX conferences, but often they are rejected with comments such as "this is very open source focused, you should try sending it to a Linux conference" without any hints about what they mean by that.

In the end I've given up on at least one academic paper after numerous such rejections and got it published here at LWN instead. I personally consider this a step up from any academic conference, but that's a harder case to make to your tenure committee which has their own rules to follow.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 15:03 UTC (Thu) by lgeorget (guest, #99972) [Link] (2 responses)

> I often try to write Linux related papers and send them to the more mainstream IEEE/ACM/USENIX conferences, but often they are rejected
> with comments such as "this is very open source focused, you should try sending it to a Linux conference"

Really? I'm a PhD student and I happen to work on the Linux Security Framework.
A lot of Linux-related papers have been published in IEEE/USENIX/ACM conferences,
including the seminal paper on LSM in 2001 published in USENIX, the numerous papers on
the position of the LSM hooks by Trent Jaeger et al., etc.

At least in my field (security of OSes), I feel that there is much more research done on Linux
than any proprietary OS (in fact, this might seem a bit exagerate but "proprietary" is often
undertood as a synonym to "insecure").

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 17:17 UTC (Thu) by deater (subscriber, #11746) [Link] (1 responses)

> Really? I'm a PhD student and I happen to work on
> the Linux Security Framework. A lot of Linux-related
> papers have been published in IEEE/USENIX/ACM
> conferences, including the seminal paper on LSM in
> 2001 published in USENIX, the numerous papers on
> the position of the LSM hooks by Trent Jaeger et
> al.,etc.

It varies, and of course the fault could be entirely with my research not the venues.

I often get rejected with the work being "too incremental", which is frustrating, as if you're doing open source work often you are doing steady incremental changes to an existing codebase rather than some amazing new thing from scratch.

So you extend an existing fuzzer in a novel way and find hundreds of new bugs in the linux-kernel: "too incremental, maybe try a Linux conference"

Use the Linux perf interface to validate the RAPL memory counters? "too incremental, maybe try a Linux conference"

Even amazing open-source tools like Qemu and Valgrind and such had a hard time getting published in any real venue. I often find myself citing project websites and tech reports just because it's not worth the trouble to some tool authors to get things published. Yet conference proceedings abound with papers about tools with catchy names that no one beyond the author even has the code to actually run it.

It's true that eventually with lots of revision and extra work you can sometimes find the proper venue to get published, but with the 6+ month turnaround time in academia this can be bad, as eventually your papers get rejected because your work is "old news, a tool already does this" and of course this is because you yourself wrote the tool 18 months ago, it became popular, and it's open source, so where's the novelty. I personally refuse to embargo my code for years just in case I can get a publication out of it.

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 10:07 UTC (Fri) by paulj (subscriber, #341) [Link]

+1 to this.

There is a terrible problem in CS at the moment, well at least the little corner I'm familiar with (networking), of a huge bias towards papers that implement a whole "system". So a paper about some idea with an evaluation via some toy system, that is too incomplete and immature to be useful in any real application is more likely to be published than a paper that evaluations the idea through some incremental improvement to an existing, useful system.

Very sad state of affairs, and it is generally making academic CS less and less relevant (least, it is in networking. Though, there are some notable exceptions.

Just an observation and thoughts

Posted Feb 4, 2016 15:05 UTC (Thu) by pizza (subscriber, #46) [Link]

Speaking of my own experience (the better part of 20 years old at this point) I got the impression that FOSS use in academia (at least in undergraduate instruction) was more due to its acquisition cost than any inherent "self-empowerment" principle.

I saw the dotcom boom give rise to large corporate donations of equipment and (proprietary) software, and with that, lessons tailored to utilize the equipment and software they now happened to have. The more cynical amongst us considered this akin to drug dealers giving the first fix away for free.

(This also aligned with the rise of PCs running Windows NT replacing UNIX workstations -- Most FOSS stuff simply didn't run on Windows, and never underestimate the appeal of shiny...)

I've had the opposite feedback

Posted Feb 4, 2016 15:16 UTC (Thu) by lgeorget (guest, #99972) [Link]

Maybe this is only in my country (France), but I've had echos by professors I work with that companies looking for Windows sysadmins had difficulties to hire because in enginnering schools, most students learns the basics of network administration, LDAP configuration, databases, etc. with open source software and when they graduate, they have no experience with ActiveDirectory and other proprietary (and too expensive for universities) technologies.

All my classes of OS architecture and administrations were taught using Linux as an example. What can you learn from closed-source software anyway?

And this is the same for development. I personnally had only one project with Microsoft technologies (a game to be written in C#/WPF, requiring VisualStudio). This was possible because Microsoft's Dreamspark parternship allowed the students to have free licenses. Apart from that, we only worked with free software. I never learnt to use a proprietary closed-source version control system. Admittedly, this is much more because of the price of the products than because of philosophical attachment to software freedom but...

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 15:54 UTC (Thu) by kfiles (subscriber, #11628) [Link] (5 responses)

What are we talking about here? The lack of open source operating systems, compilers, libraries, and toolchains in universities? Or the lack of specific courses discussing making development contributions to existing Open Source projects?

My education experience is admittedly quite dated, but when I got my degree in the 90s, our entire lab ran on GNU utils and compilers, all of our courses used BSD and open source compilers, and Linux was used extensively by undergrads, along with FreeBSD. In the IT department, I packaged, deployed, and sent patches upstream for apache and innd. I keep in touch with some folks in the undergrad computer labs, and I don't think too much has changed.

It is however true that I have *NEVER* heard of a professor advocating for making contributions to Open Source projects, or even using revision control. Nor have I seen at my alma mater any courses on the philosophical differences between proprietary development and Open Source. However, all academic research on OSs and compilers that I am aware of uses Open Source.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 17:26 UTC (Thu) by deater (subscriber, #11746) [Link] (1 responses)

> It is however true that I have *NEVER* heard of a
> professor advocating for making contributions to Open
> Source projects, or even using revision control. Nor
> have I seen at my alma mater any courses on the
> philosophical differences between proprietary
> development and Open Source.

It does vary by school and by program.

At our University the Computer Engineering students will graduate with Linux experience, including embedded Linux programming on Raspberry Pis, writing a Linux device driver, and multiple classes that require use of gitlab to submit code.

They also have a final capstone project which requires writing code and picking an appropriate license for it (which can be a proprietary license if they so choose, but they are taught the differences between the various types).

It's hard to say how atypical it is. A lot of it does just happen to depend on the personal whims (and ages) of the professors in your department.

And I do agree with previous posters that the use of open-source code in academic settings is often a matter of free-as-in-beer rather than free-as-in-Stallman.

It also helps that so much of the world is ARM centric these days which has a lot of open source around it. There has been a push though to teach Android or iOS programming which might start the creep back to more proprietary development methods.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 20:08 UTC (Thu) by pizza (subscriber, #46) [Link]

> It also helps that so much of the world is ARM centric these days which has a lot of open source around it.

Don't worry, the powers that be are working to change that.

Open source used to be the pragmatic, practical approach because there was such variation in ABIs, but now that the Cortex-A and Cortex-M families have managed to bring sanity and unification to the ARM world, one finds many, many more binary blobs then there used to be.

I guess ARM is finally catching up with x86, eh?

The scarcity of college graduates with FOSS experience

Posted Feb 5, 2016 23:13 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> It is however true that I have *NEVER* heard of a professor advocating for making contributions to Open Source projects

At RPI, we had (well, it's still there) an open source class. One part was to find a project and make some patch on it and then present on your experiences (I chose Wesnoth).

There's also the RCOS (Rensselaer Center for Open Source), funded by Sean O'Sullivan (the MapQuest guy) which gives credits or a stipend for working on a FOSS project. Some notable things which have come out of it include the course signup system used by RPI (and last I heard, other institutions wanted to use it as well), a campus shuttle tracker, the bulletin board announcement system used on campus, and I'm sure there is at least one more. RCOS is run by two professors currently.

I know Remy DeCausemaker is also involved with FOSS work at RIT as well.

The scarcity of college graduates with FOSS experience

Posted Feb 19, 2016 4:11 UTC (Fri) by glikins (guest, #107162) [Link]

<snip> FOSS at RIT and RPI

Yes! Those are two of the three schools that Red Hat is partnering with around open source -- we think they both have great programs and their focus on open source development and open source principles is at the heart of that.

The scarcity of college graduates with FOSS experience

Posted Feb 19, 2016 4:28 UTC (Fri) by glikins (guest, #107162) [Link]

> What are we talking about here? The lack of open source operating systems, compilers,
> libraries, and toolchains in universities? Or the lack of specific courses discussing making development
> contributions to existing Open Source projects?

^^^^^ this Almost every CS/SE/CE department we've talked to *runs* open source. Many of them teach Linux in their operating systems class. We have found it significantly rarer to find universities or colleges who teach about how to work in an open source project or what open source *is* (what it _means_ to be able to see/inspect/fork the code).

Teaching a class on open source will not always be the right answer -- in line with to jhhaller's comment earlier, we believe that using open source projects as a source of *material* when teaching concepts that students need to learn anyway may be the right route for many schools. This is especially true when you consider that so many of skills that are being identified as critical to success for tomorrow's developers are actually things that aren't straight-up coding, like: requirements gathering and communication skills.

In addition, students need to learn how to work on large, complex codebases -- open source projects can provide a way to do this that is both pedagogically sound *and* incredibly motivating.

The scarcity of college graduates with FOSS experience

Posted Feb 4, 2016 17:47 UTC (Thu) by Shewmaker (guest, #1126) [Link]

I'm a graduate student and I'm teaching an undergraduate course in Open Source Programming this quarter. I designed the syllabus, and it took me two tries to win a fellowship in order to launch the class. It was not easy to navigate all of the processes necessary to start a new class.

Part of the reason I succeeded the second time was due to it being linked to the launch of a new Center for Research in Open Source Software at UCSC. "The purpose of the Center for Research in Open Source Software (CROSS) is to encourage turning significant systems research prototypes on advanced research areas created during undergraduate senior projects and graduate thesis projects into successful open source software projects with vibrant user and developer communities."

I chose to introduce students to the Linux kernel community development process for a few reasons. First, my research group is systems-focused. Second, I figure that if the students can get the hang of Linux kernel, then they can be successful in pretty much any project. So far, they seem to be enjoying the hands-on nature of the course. And they are beginning to send me emails that look like real patches :)

I had some great instructors at the undergraduate level, but we didn't have a course anything like this. We did have Linux boxes in our labs, but I learned most everything about Open Source though internships and on my own. It has been a challenge to teach this subject since it is so easy to forget how little I knew when I was an undergraduate.

The scarcity of college graduates with FOSS experience

Posted Feb 11, 2016 3:35 UTC (Thu) by donbarry (guest, #10485) [Link]

I have to protest that an article on encouraging the adoption of "open source" in Universities suggests asking about student's "github histories".

Perhaps the fact that the phrase "free software" is never mentioned here indicates a deeper problem with the orientation of the article -- one can see from some the github reference that the choice of framing makes a difference. The appeal is largely pragmatic, not to more fundamental issues, and the encouragement of the use of a proprietary SAAS tool -- even to the point where failure to use such a tool would penalize the student -- cements the picture.