Leading items

The scarcity of college graduates with FOSS experience

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.

Comments (40 posted)

Whole-house audio with free hardware and software

The Black Forest fire destroyed over 500 Colorado houses in June 2013; one of those belonged to longtime Debian developer Bdale Garbee. As he reported during his talk at the 2016 linux.conf.au Multimedia and Music miniconf, the house has been redesigned and rebuilt and life is generally better now. Part of the rebuilding process included the incorporation of a whole-house audio system; naturally, Bdale took a unique approach to that task. His talk showed what can be done when one starts from scratch — and doesn't mind designing a circuit board along the way.

A common approach to whole-house audio is to use a network — typically WiFi — to distribute audio bits to various places within the house. Companies like Sonos and others happily sell that kind of system; there are, Bdale said, a number of free-software projects working to replicate those products. His approach was different, though. The system was designed around speakers built into the ceiling of each room; all are wired back to a central audio server installed in a mechanical closet. In other words, analog audio, rather than a digital stream, is distributed around the house.

There are plenty of proprietary products that follow that sort of design as well. They are typically built around a two-dimensional crossbar switch that can connect specific audio sources to any of a number of audio zones. He would have been happy enough with a proprietary solution, he said; in the end, it's just an appliance installed into the house. There was, though, one absolute deal-breaker: his due-diligence work turned up the existence of probable GPL-infringement issues with these products. Just reading the manuals was enough to make it clear that they were Linux-based, but there was no mention of software licenses, and no downloadable firmware in any form, much less source code. So some other sort of solution was called for.

The revised plan called for the builder to put in the speakers and wire them back to the central closet, but to install no server; Bdale would supply that part. He spent some time looking into commercially available amplifiers and switches, but he found them to be "clunky and expensive." The products were designed as if they were to be installed into professional recording studios; they had a level of complexity that he just didn't need. If only, he said, there were a nice USB-attached device with stereo output, the rest could easily be assembled from available hardware and software. Such things do exist, of course, but there were none that met his requirements; they required things like wall-wart power supplies, something that gets awkward when you mean to install nine of them. So he ended up designing his own hardware.

The result was the small board shown to the right. It features a PCM2705C digital-to-analog converter — essentially a USB stereo audio chip. Among its advantages are the fact that it already has good support in the Linux kernel. Tied to that is a TPA3118D2 class-D audio amplifier with 30 watts/channel of output power. Some of his audiophile friends evidently give him grief about using a class-D amplifier, but, he said, these amplifiers are good enough for a system built around ceiling-mounted speakers.

(Given that, as he said earlier in the talk, his previous office audio system was a tablet playing out of its built-in speaker, there can be no doubt that the new system sounds much better even if the gold-cable crowd would turn up its collective nose at it).

Nine of these modules (which go by the name usbclassd) are plugged into a MinnowBoard Max system. That board provides what's needed: a network interface and a USB port. The Intel architecture also seems to be important: some of the software components needed to obtain audio from commercial streaming services (he mentioned Spotify in particular) are binary-only. He is not entirely happy with that but, he said, keeping the family happy trumps adherence to open-source software principles.

The MinnowBoard is running a minimal Debian system; in general, he said, the earlier one can get out of the distribution's installer, the better. The directory tree for media is automounted (using NFS) from another server on the network. The audio software system is built around Mopidy. It was, he said, designed to be part of a desktop environment, so running it on this type of audio server is moving it a bit out of its native mode, but it works well enough. It supports the MPD protocol allowing for remote control, and has a web-interface protocol as well. He is not, he said, using Debian's packaged version of Mopidy since he needs the proprietary Spotify plugin which, naturally, Debian does not provide.

One interesting problem that had to be worked out is USB enumeration. The usbclassd boards are plugged into an inexpensive ten-port hub obtained online; those hubs, he said, are "randomly wired." The usbclassd boards lack unique serial IDs (something he could have added with another chip, but chose not to), so there is no way to tell them apart in the software. Fortunately, with a fixed hardware configuration, USB enumeration in the kernel is deterministic so, once he worked out which was which, it was a simple matter to map each device to the zone it serves.

One of the nice features of the amplifier he chose is that it can power down when the USB interface suspends itself. But, after realizing that those amplifiers were hot when no music was being played, he realized that things didn't quite work as he had expected. The USB audio interface doesn't suspend itself when there is no packet traffic; it depends on the suspend state of the interface in general. USB autosuspend tends not to be enabled by default, since there is a lot of second-rate hardware that doesn't support it well. His hardware does support it, though. A simple udev rule tweak was enough to get around that issue. It is still necessary to actually stop the audio stream out of Mopidy to get things to suspend, though; simply pausing it is not sufficient.

Getting back to Mopidy, he noted that it is designed to only support a single audio stream — a bit of a mismatch to his use case, with nine independent zones. His solution is to just run nine instances of Mopidy; it's a "clunky workaround," but it works. Each instance has its own MPD socket; the Mopidy Mobile app can be configured to know about all of the zones.

His final topic was clock skew. Digital audio interfaces work by streaming a series of samples to the digital-to-analog converter; that converter converts them to audio at the rate determined by the on-board clock. If you are feeding the same stream to multiple boards simultaneously, even small differences in the clock rate will accumulate over time. That can lead to the different zones being out of phase (an audiophile issue that Bdale found kind of laughable, especially given that the different zones are in different rooms) or eventual buffer underruns on the board with the faster clock. Bdale said that he could have gotten around this issue by creating a nine-output board with a single clock; a member of the audience suggested he could look into the clock synchronization support in GStreamer (which Mopidy uses). The simple fact, though, is that he doesn't really care about this issue. That could be reviewed if he ever develops the wish to drive multiple zones in parallel, but it is not an issue now.

The system is working, and the entire family seems to be happy with it. There are always improvements that can be made (he mentioned replacing the power-supply fan with "one that has ball bearings"), but, in a sense, the project can be seen as complete. For the curious, some more information, including schematics for the usbclassd board, can be found on his web site.

[Your editor thanks LCA for assisting with his travel expenses.]

Comments (26 posted)

Maslow's hierarchy and expanding the open-source community

On the last day of SCALE 14x, Sarah Sharp delivered the morning keynote, speaking about what individual community members can do to foster increased diversity in the open-source community. Sharp took a unique approach to the question, though; she looked at the factors identified in Maslow's hierarchy of needs, examining what those in the open-source community can do at each level to help people participate fully.

The hierarchy, she said, was first articulated by Abraham Maslow in his 1943 paper "A theory of human motivation." It describes five levels through which human motivation progresses, starting at the most fundamental and with each subsequent level building on the those below. For people to reach their fullest potential, each level's requirements must be satisfied, progressively up the hierarchy. That is, it is impossible to work on level three until levels one and two are satisfied.

The exact terms applied to each level can vary a bit depending on where one looks; Sharp described them, from the lowest level on up, as "homeostasis," "security," "community," "esteem," and "self-actualization." Homeostasis is the physical-survival need. In general usage, this means needs like food and water. For a geek in the open-source community, Sharp said, the equivalent need is the ability to get into "deep hack mode" where a person sufficiently tunes out the world to pour themselves into their projects.

To get there, Sharp said, a geek needs four things: sufficient uninterrupted time, some sort of computer, the electricity to run it, and (usually) some form of Internet access. But not everyone has access to all four. Uninterrupted time is a scarce commodity for many people—in particular, for anyone who is the caregiver to someone else (children or the elderly, for instance). And caregivers today are statistically more likely to be women than men—and, disproportionately, women of color.

Things the community can do to help people with limited time, she said, include providing daycare at events like conferences or hackathons, and not treating periods of inactivity (as can happen when caregiving duties become particularly time-consuming) as a negative—which is a particularly common bias when assessing job applicants' resumes. Individuals can also support initiatives like OpenHatch that try to provide "non-standard entry points" to open-source participation.

As for computer access, it is often taken for granted these days, but reality is more complicated. Even in the US, there is a significant disparity in computer ownership based on race, and an even bigger disparity based on income. Furthermore, the statistics quoted often focus on "households with a computer" or similar metrics—but they do not tell the whole story. A household might have a computer, but in many cases it belongs to one member of the household (say, the father or an older sibling), and others in the house have limited or no access to it.

And many of the computers in such statistics tend to be low-end devices like Chromebooks when, too often, the open-source community assumes everyone has access to a powerful PC (e.g., one fast enough to run a virtual machine at comfortable speed or with hundreds of gigabytes of storage). To accommodate people with reduced access to computers, she said, projects can set up development servers on which community members can run builds or do other work. They can also donate systems to non-profits that revamp them to distribute to low-income households, or contribute to low-cost-computing projects like Raspberry Pi.

Electricity and Internet access are not distributed evenly, either. In particular, it is easy to overlook the fact that people in developing regions often pay by the byte for their Internet access. This creates a barrier to entry, as many open-source projects expect new volunteers to download enormous source-code bundles or to contact the project through always-on services like IRC. A 500MB data plan in India, she said, costs the equivalent of 17 hours of average wages (and 500MB happens to be roughly the size of a current kernel source bundle). It takes an average of ten page clicks to file a bug report, she said, which at the average web page size works out to nearly an hour's wages in India. That makes bug reporting a rather unappealing way to contribute.

Projects can help reduce these barriers to entry by consciously reducing their web site's footprint (in terms of of bandwidth and page-click count), by fully supporting asynchronous communication channels, and by bundling important resources like documentation with source-code downloads. In addition, she noted that Git still does not support interrupting and resuming download operations, which is an important bug to fix. And few web sites make any effort to detect when a session is over a slow or unreliable connection; site owners would do well to fall back to low-bandwidth versions of a site in such circumstances.

The homeostasis level occupied the longest portion of the talk, Sharp said, but that is because it is the most fundamental. The next most fundamental level is security, which means ensuring that each individual feels personally safe. Sharp did not want to spend time debating the frequency of online harassment, she said. Instead, she referred the audience to the Petrie Multiplier, which describes why members of a minority within a group encounter bad behavior with considerably greater frequency than do those in the majority. All else being equal, a few bad actors disproportionately make participating in the group unpleasant for those in the minority, just due to the minority:majority ratio.

The takeaway, Sharp said, is that projects should not discount reports of bad behavior experienced by those in the minority. If someone says they have experienced bad behavior, the community ought to believe it even if it does not seem to match with their own experience. Codes of conduct are what most projects employ to make people feel safe in their community; Sharp said it was good to see more and more projects using them, but cautioned that they should not be taken for a "magic checkmark." They only work when they are put into action. She also advised projects that "rolling your own" code of conduct is a bad idea akin to rolling your own cryptography. Instead, projects should contact experienced professionals like Frame Shift Consulting or Safety First PDX.

Codes of conduct are effective at cutting down on negative incidents, but they do not encourage participation—which is the goal at the community level of the hierarchy. Many projects would like to encourage more diverse participants, she said, but if 90% of all newcomers fail to make a contribution and drop out, minorities cannot be expected to do better.

She cited several things that projects can do to encourage new participants, including taking a look at on-boarding procedures and at documentation. Leaving newcomers to explore on their own is unlikely to succeed; projects need to document how to communicate with the project, how to get started with builds, how the release cycle works, and what the coding style and testing procedures are like. It is important to identify appropriate tasks for beginners and for intermediate participants, and to provide mentors.

The esteem level concerns recognizing a person's work, giving them attribution for their contributions, and acknowledging their successes. The key factor for enabling such recognition is providing open doors and invitations. It is too easy for us to unintentionally overlook individuals that do not match our preconceived expectations, Sharp said, and to accidentally limit who hears our invitations by advertising them only to the circles of people we already know or who resemble the people we know.

Projects can help improve this situation by deliberately focusing on growing new contributors into leadership roles: documenting what those leadership roles involve, appointing backup and "vacation maintainers," and seeking out those with diverse perspectives. Open-source projects already have a bad habit of burning out longstanding leaders and contributors, she said; introducing planned succession for leadership roles would alleviate that problem as well.

The last level, at the top of the hierarchy, is self-actualization, which means being able to reach your full potential at the things you are passionate about. It is important to recognize that self-actualization may mean something quite different to one person than another, Sharp said. For some, self-actualization means helping other people reach their full potential. She then listed a number of individuals who choose to work on projects that encourage diversity, like Mariella Paulino of Code For Progress, Asheesh Laroia and Karen Rustad Tölva of OpenHatch, Leslie Hawthorne of Google Summer of Code, and Karen Sandler of Outreachy.

But one does not need to start a large project to help other people achieve their goals, Sharp said in conclusion. Her own story, she explained, involved numerous allies along the way who encouraged her in her journey through the technical community—from her first computer, through college, into the general open-source community, the kernel community, Outreachy, and now the graphics community. Everyone in the audience, she said, can do the things mentioned in the talk. The important thing is that they stop being a bystander and start to contribute.

Comments (12 posted)