Increasing open-source inclusivity with paper circuits

Huang started by asking why we should care about making technology more inclusive. Open-source software gets its power from inclusiveness; that power is so strong that we can (quoting Chris DiBona) claim that, without open-source software, the Internet as we know it would not exist. As an engineer, he thinks that's great, but he has a concern: that means that the user base now include politicians.

The problem with politicians is that they may look at the open nature of open-source software and conclude that random people, some of whom may be criminals, have access to the public infrastructure. That does indeed lead to the possibility of things going wrong. The leftpad() fiasco was one example that affected a large group of developers, but there are scarier examples, such as criminals who are typo-squatting in the NPM repository, trying to get malware into others' applications.

Huang also mentioned a time bomb he encountered in XScreenSaver, which started complaining that it was too old and needed to be upgraded. This was not a malicious act; the developer was just finding a way to say that he's tired of Debian not shipping updates to the code and using that code to try to force a change. In a Debian bug-tracker discussion, Jamie Zawinski (the author of XScreenSaver) described his interactions with users, who evidently tell him "but I don't know how to compile from source, herp derp I eat paste". To Huang, exchanges like this make it clear that the "everybody" that is empowered by open-source software is actually a small and elite group. Few people know how to compile a program from source.

What would happen, he asked, if some developer put in an obnoxious warning that popped up on every Android phone? It might be a well-intentioned act, but it would upset a lot of people and show how much power this small group has. That, in turn, can lead politicians to propose that, for example, programmers should be regulated and that a bonding requirement be put into place. One might say that such a thing would clearly never pass, but democracy is a tricky thing, and there are plenty of examples of things not going right. He cited the repeal of network neutrality in the US, the "Brexit" decision, and the recent US presidential election. One cannot, he warned, count on preposterous things not passing.

If one looks at voter demographics with regard to their understanding of technology, the picture is scary. Few people truly understand technology; the best of the bottom 50% in this regard can barely type a search query into a web browser. Far less than 50% of the electorate is qualified to vote on technical issues. So, he asked, do we really want to put issues like network neutrality, surveillance, DRM, right-to-repair, open-source software, or even emoji selection up for a vote? The outcome would be essentially random.

Open-source is politically powerless without the sort of inclusiveness that enables people to understand it, but nearly 100% of the population relies on it. We need the government to help to enforce our licenses, and we need society to support our work. If we believe that open-source software is important, he said, we need to empower more people to preserve and sustain it.

Efficient inclusiveness

That said, teaching people one-by-one to code is an inefficient process; the engineer in him wants to optimize the effort. That led him to look at the demographics of the technical community as it exists now, and he concluded that we're missing half of our society — there are few women in technology. If we could get them involved, we could double the size of our community in one stroke.

Currently, women earn 11% of the degrees in computer engineering, and just under 16% in computer science. Female representation in computer-science faculties is poor, worse than physics or math. It is, he said, an "exclusive boys club". One might ask if this is a cultural problem, and he thinks that it is; he has noted that there is a far better gender balance in China, for example. So he has concluded that there is no fundamental reason why we couldn't get more people involved.

Others have done the same. An effort at Carnegie-Mellon University [PDF] changed the approach in the computer-science curriculum and changed female participation from 10% to 40% in five years. At Harvey Mudd University, the female graduation rate was increased from 12% to 45% in five years. So it is possible to make things better.

The key insight Huang drew from these efforts is that computer-science programs assume that students know the material before they begin to study it. Medicine programs do not expect incoming students to have already done surgery, and law programs do not expect them to have participated in trials, but computer-science programs expect that students can write complex code in a C-like language when they walk in the door. Anybody who didn't decide to learn about computers at a young age is going to respond by concluding that this field is not for them.

The bias that keeps women from learning about technology starts at a young age. According to this study [PDF], over 60% of construction-kit gifts are given to boys (in this study, 9% went to girls, the rest were unknown). Universities like Carnegie-Mellon and Harvey Mudd have responded by creating a softer on-ramp that doesn't assume a lot of familiarity with the field and, as a result, they have succeeded in including a lot more people. Doing this isn't a mystery, we just need to make it easier to get started.

Changing culture with paper circuits

Huang's way to make it easier is to try to change the culture around electronics and, in particular, to do so by building circuits on paper rather than by using breadboards. Paper is the substrate, conductive tape is used for connections, and circuit elements are either taped on or soldered. The result is a lot closer to a real circuit board than any breadboard circuit; it demonstrates issues like wire crossings that don't arise with breadboards. That makes a paper circuit easier to move to a true circuit board once it has been finalized. Paper circuits are also flexible — literally. They can be incorporated into a pop-up book, for example.

There are other advantages to paper circuits. They are, for example, compatible with both surface-mount and through-hole components, while breadboards only handle the latter. Paper, he noted, natively supports comments — they can simply be written on the substrate. It's thin, flat, and light, and the substrate is free; breadboards have none of these attributes. On the other hand, with breadboards there is no soldering required and components can be reused, which is why breadboards tend to be favored in educational settings.

The soldering issue is one of the key barriers to mass adoption of paper circuits. In truth, surface-mount components can also be tricky; they tend to be tiny and can be hard to position correctly on a paper circuit. So Huang met up with Jie Qi, who has done a lot of work in this area, and developed the idea of creating stickers with components that could be easily applied to paper circuits. That, they thought, would make the whole idea much more approachable.

Huang and Qi ran a pitch on Crowd Supply to raise some money to develop this idea. They set their goal to an eminently achievable $1 just to see what they would get; when the time ran out, over $100,000 had been pledged. That put them into a position of running an "accidental startup" that they had to somehow make a proper company out of. One of the first things they decided is that they would not be providing "pinked-out" or watered-down technology. Instead, they would be providing rigorous technology that is accessible and fun. Design and technology would be seen as equals, each of which has value.

The people who initially funded this effort were 67% male. But the customers for the product on chibitronics.com were 74% female, and Amazon.com customers were close to that figure. The number of women has been growing over time; 78% of the customers are now women. Huang said that he would like to make things more balanced again and get more men, but he feels that it is a positive thing to have all of those women playing with the technology.

Love to Code

The next step is to move beyond circuits and add coding into the mix; that was the driving force behind the Love to Code project. This project, too, had some founding principles behind it. One was that engineering and design are equally important. We tend to measure achievement on a single axis, but that can exclude people who don't excel on that axis. By combining engineering and art, it's possible to create a two-dimensional space with a lot of ways for people to stand out.

Familiarity is another core part of Love to Code. Paper is a familiar material to most people. It is also expressive, allowing circuits to be made into all kinds of interesting works of art. But paper is also a technical material with many attractive characteristics.

Finally, simplicity was a key goal; there need to be few barriers to getting started. That led to some interesting challenges: how does one get compiled C code into a microcontroller, for example? By default, that is a difficult process requiring users to figure out details like what their serial port is named. It is frustrating and being able to do it doesn't make anybody better than anybody else. So they tried to find a universal interface that would be easy for everybody to use.

In that search, they concluded that ports on computers change frequently, but humans tend to stay the same over the years. In particular, they still have eyes and ears. As a result, there is an audio jack on almost every device — unless you get a modern phone that tries to lock you into a DRM ecosystem and you have given up your sound port, he said. Sound is capable of carrying data, so Love to Code uses it to upload compiled code. This code is played out of the audio port and into the device. The result is one of the few microcontrollers that can be programmed with a mobile phone.

There were many other challenges to overcome. The component stickers went through several generations of design until the problems were worked out. The problem of connecting a microcontroller to a paper circuit was eventually solved by attaching it to a plastic clip. The result is a usable controller that is suitable for classrooms. The curriculum had to be developed from the beginning; it starts with fun characters and introduces coding concepts in an approachable fashion. It makes the point that code isn't so scary.

The book is, naturally, available for download [PDF] under a CC-BY-SA license. All of the code and hardware designs can be found on the Chibitronics GitHub page. Everybody is encouraged to have a look and make it better.

Details

Huang spent a few minutes talking about how the hardware works. Sound is transmitted using AFSK modulation; it employs two tones like an old modem. Those frequencies are relatively high but were chosen to be "MP3 survivable". The demodulator on the microcontroller is based on linmodem; when running it takes 65% of the available CPU time, not leaving much for anything else.

Picking the microcontroller took some work. It needed to be cheap, open-source friendly, have a digital signal processor, an analog-to-digital converter, and so on. After looking at a number of candidates, they chose the Kinetis MKL02Z32VFK4. It has a 48MHz Cortex M0+ processor ("haha it's not vulnerable to Meltdown"), and 32KB of flash memory. The processor costs less than $1 when purchased in volume and there is no non-disclosure agreement to sign for documentation. The winning feature, though, was a fast GPIO port; it is used for USB low-speed emulation, allowing the controller to function as a USB keyboard.

A normal audio jack is too big to fit onto the microcontroller, so another solution was required. In the end, they created a hybrid USB cable that carries audio over the 5th pin. There is no channel back to the host on this cable, so there is no way for the microcontroller to request retransmission of corrupted data. Instead, the host transmits the whole thing three times.

The microcontroller operating system is based on ChibiOS, which is a separate project not related to Chibitronics; "chibi" means "small and cute" in Japanese. Much of the needed support code has been added to ChibiOS to minimize the size of code downloads from the host. The whole system operates under the "patience of a child constraint", meaning that downloaded code must be small enough to arrive and run before the child gets bored. The smallest programs compress down to about 256 bytes of code.

Huang said that Love to Code is not just for kids; it's intended to be a complete "novice to startup" course. Thus, for example, threading is part of the curriculum. Threading, he noted, is easy (but concurrency is hard). The hardware was also chosen to be "China ready". Kits sold in the US often include components that are available there, but which cannot be had in China; that makes it hard to move a prototype circuit into production. Love to Code uses components available in China, avoiding the need to redesign a circuit around new parts.

The "experience layer" can be found at ltc.chibitronics.com. There are a lot of examples ready to go. A simplified form of C++ is used for the introductory material, but it can get "as hairy as you want it" later on. For the smallest kids who might have trouble finding curly braces on the keyboard, a partnership with Microsoft led to makecode.chibitronics.com, where programs can be created using a visual block language.

Conclusion

Huang concluded by reiterating that sharing source is just the first step toward inclusiveness. Saying "I pushed to Git" is inclusiveness in passive-aggressive form. Reaching out to the wider world is a much bigger project, but it's an important one to take on; open-source software was built on inclusiveness. It is not a "commit and forget" thing, it's about pulling, merging, forking, and accepting new ideas. One way or another, we have to empower more of society to understand and value open-source software, he said, or society may come up with its own value with results that we don't like.

The video of this talk is available.

[Your editor thanks the Linux Foundation and linux.conf.au for assisting with his travel to the event.]