This chapter is from the book
This chapter is from the book
This chapter is from the book
Case Studies
There’s a lot more to open source hardware than just the fabrication and electronics technology. The following case studies draw on my personal experiences with open source hardware to discuss some of the real-world issues involved. The first case study looks at the Arduino electronics platform, a well-known open source hardware project. The second case study discusses my research at the MIT Media Lab, building open source and DIY consumer electronic products.
Case Study: Arduino Microcontroller Development Boards and Their Derivatives
Arduino is a platform for building interactive objects. It consists of microcontroller-based circuit boards and the software for programming them (both of which are open source), along with relevant documentation and community support.
Arduino builds on the work of many other projects, including the Wiring electronics prototyping platform, the Processing development environment, the GNU C Compiler (gcc), AVR libc, avrdude, and more. Since the Arduino electronics prototyping platform started in 2005, it has spawned and participated in a diverse ecosystem of software, hardware, communities, and companies. The relationships between the various actors in the Arduino ecosystem take many different forms: some specifically relate to the open source nature of the Arduino hardware, others reflect its open source software, and still others are based on more traditional business factors. As a co-founder of Arduino, I’ve witnessed many of these stories over the years. This case study attempts to make sense of the lessons of Arduino for open source hardware and personal manufacturing.
Because the original Arduino circuit boards are relatively simple, were created with a low-cost circuit design tool (Eagle), and use widely available parts, it’s relatively straightforward for someone to make their own versions of them. This has led to a proliferation of Arduino derivatives, with a number of different modifications. These boards reveal an open source hardware ecosystem with a very different structure than that of most open source software projects. Successful open source software projects typically involve decentralized collaboration efforts, in which a number of individuals contribute to a single body of source code. The derivatives of the Arduino hardware, in contrast, tend to be produced by a small group of people, often the same ones who sell the resulting product. These derivatives often undergo few public revisions, even though some have remained available for purchase for a number of years. Moreover, relatively few changes have been contributed back to the design of the official Arduino boards. Overall, the derivatives constitute a diverse set of alternatives from different producers, in contrast to the centralized codebase that seems to prevail in most open source software projects (including, in many respects, the Arduino software itself). While some derivatives (like the LilyPad Arduino) have been incorporated into the official Arduino product line, very few (if any) modifications have been contributed to existing boards.
There are multiple obstacles to collaboration on centralized hardware designs that go beyond the need for human skill and motivation common to other domains (like open source software). One is the difficulty and expense of fabricating and assembling boards. Soldering them by hand can be done in small quantities (facilitating changes and the creation of unique variations) but is time consuming, error prone, and limited in the parts it can work with. Automated assembly is more efficient but typically requires larger quantities, limiting the frequency of changes to the circuit’s design. Even worse, it can be difficult to switch between these approaches because they may require the use of different components.
Another obstacle is the relative unavailability of tools for tracking and merging changes to the design of circuit boards. Open source software has robust version control tools that allow the tracking and merging of changes by many different people. The free and low-cost circuit design tools used by most of the people designing Arduino derivatives don’t provide automated methods for viewing or merging changes. Without these capabilities, the process of proposing changes to the design of an Arduino board is one that in many ways fails to take advantage of its digital nature. That is, you describe the change you’d like to see and rely on the original designer to re-create it for themselves, if desired, rather than providing a digital encoding of the change that can be automatically previewed and merged. This lack of easy methods for merging the efforts of multiple individuals reduces the viability of peer production for electronic circuits.
A final obstacle to centralized collaboration is the complications relating to the role of money and business in the production of hardware. When developers have to invest money and time in making and testing changes to the design of a circuit, they may be motivated to recoup those investments by selling their own version of a product rather than contributing their changes back to the original producer. This can create confusion around identity and branding as well, as it can become challenging to distinguish between boards of similar or identical design from different producers. As a result of these complications, Arduino has trademarked the Arduino name, using it to identify only products made by the company. This decision was initially contentious but since seems to have become an accepted practice.
The Arduino ecosystem also points out the importance of open sourcing the complements to the hardware itself. Because the Arduino software is open source (as are its underlying software tools), it gives the makers of derivatives a platform that people can use to program their boards. This factor has slowly pushed the Arduino software to become ever more general; it originally supported only a single AVR processor, then spread to most of the AVR product line, and now can support multiple processors with completely different architectures. This provides a uniform, centralized software platform for the whole ecosystem of derivatives. It also allows others to customize the software along with the hardware, adopting it to both specific uses and available resources. Online documentation (especially if liberally licensed) also makes it easier to support a new board, as that product doesn’t need to be documented from scratch. This open source software and documentation, combined with accessible circuit board fabrication and electronic components, together yields a healthy ecosystem of Arduino derivatives and alternatives.
It’s not clear what the relative importance of these various factors has been in promoting the vibrant Arduino ecosystem that exists today. Certainly, the Arduino software is more sophisticated (and, therefore, would be more difficult to re-create from scratch) than the basic Arduino circuits—and, in many cases, the derivative circuit designs have been re-created from scratch rather than derived from the files for the original Arduino. In theory, if the Arduino software were simply flexible and extensible, but not actually open source, it could still support a variety of derivatives of the Arduino hardware. In practice, it seems clear that many of the improvements that have been contributed to the software (including those for better support of third-party hardware) have relied in various ways on the fact that the code for the software is available. It’s hard to guess which kinds of extensibility people will need, and we probably would have done a bad job if we had tried to predict those directions; instead, individuals have been able to modify the Arduino software in whatever ways they needed and the most useful of these changes have been merged back into the main codebase.
In short, it’s difficult to separate electronic devices from the software that works with them. On the one hand, open sourcing just the hardware limits the modifications that can be made (without requiring reimplementation of the software). On the other hand, if the software is open source but the hardware isn’t, it might not be clear that derivative designs are allowed. Thus open sourcing the hardware can help make it clear that it’s acceptable to create derivatives of or add-ons to an electronic device. In addition, the design files can serve as a de facto specification and reference, facilitating the creation of compatible products. In general, the more aspects of a device’s design are shared, the more likely it seems that others will reproduce or modify it.
Case Study: Open Source Consumer Electronic Products
While Arduino has demonstrated that open source hardware can create a thriving ecosystem, it’s sobering to note that the vast majority of devices that people use remain proprietary. In my research at the MIT Media Lab, I’ve been researching the possibilities for people to build devices for use in their daily lives. I started with well-known consumer electronic products: a radio, speakers, a mouse, and, most recently, a cellphone (Figure 11.1).
)
Figure 11.1 (a) A radio. (b) Speakers. (c) A mouse. (d) A cellphone.
(Source: Images CC-BY 2.0 David A. Mellis)
I design the products, prototype them, and use them in my life. In workshops, I help others to make and modify the products for themselves. In general, I try to start from technologies that are accessible to individuals and find ways to put them together into robust and attractive devices. This requires integrating the enclosure, electronic circuit, and embedded software into a complete product—and doing so in a way that lends itself to replication and modification by other individuals. It also means designing specifically for personal fabrication, which has very different opportunities and constraints than the mass production that creates most of our electronic devices.
Electronics
For the electronic aspects of a device, determining the core functionality, interface, and components is an important first step in the design process. Knowing the parts that will compose a device gives a general sense of the required form and shapes the specifics of the electronic circuit. For example, in the speakers, the decision to use three AAA batteries as the power source placed constraints on the size and shape of the speakers and on the design of amplification circuit. Component selection is also crucial for mass-produced devices, of course, but many additional constraints apply when designing devices for personal fabrication. The components have to be available to individuals and possible to assemble without expensive machines or processes. Often, there are limited possibilities available, especially for key components. The radio, mouse, and cellphone all have, at their core, an electronic part that performs much of the basic functioning of the device (receiving radio signals, interpreting the mouse movements, or communicating with the cellular network). For all three, I’ve had problems finding or maintaining a supply of these core components: the radio receiver and mouse chip that I used have since become unavailable and the cellphone module may become obsolete as cellular networks are upgraded.
This experience points out the essential role that industry can play in DIY: the components it makes available shape the devices that individuals can make for themselves. (There are efforts to produce open source or DIY implementations of core technologies like microcontrollers and cellular baseband modules but, in general, these don’t yet seem to offer a feasible alternative to commercial components.) For these reasons, the personal fabrication or DIY process is perhaps better viewed as an individual’s ability to assemble the available technologies into a desired product rather than the ability to make everything oneself, from scratch.
The limitations on component selection need to be considered when designing the circuit. For example, with the cellphone, I had to carefully balance the functional requirements against the overall size of the circuit board to yield a usable device. This imposed severe limitations on the functionality: the screen (an LED matrix) shows only eight characters at a time and there’s no headphone jack, loudspeaker, removable storage, or many other common features. Even so, the phone can send and receive calls and text messages, keep time, and function as an alarm clock, which is enough functionality for me to have used it as my main phone for the past year. Cramming in more functionality may have made the device too big or fragile to actually use.
Being selective about the functions I needed (and being able to choose them for myself) allowed me to find a compromise that worked for me. In addition, because I faced similar constraints on component selection as many other hobbyists, I ended up using components for which I could download open source libraries. I was also often able to find existing circuit designs incorporating the same parts, which I could use as a reference in designing my own board.
Developing successive versions of my devices has also shown me that it’s important to design your circuit boards with iteration in mind. Building extra flexibility into a design speeds up the process by making it possible to try out different forms and functions without having to fabricate a new board. For example, breaking out additional microcontroller pins, allowing for multiple types of power, and providing different mounting options can allow the board to be used in new and unexpected ways. Another approach that’s sometimes useful is to provide a footprint on the board for some parts but not actually solder them on unless they’re needed. These development techniques mean that you can try out new variations on a device’s form and function without having to wait for a new circuit board to be fabricated, assembled, and tested.
Finally, while the design files for a device capture the components selected, they don’t necessarily document the requirements or tradeoffs that led to those decisions, which may make it more difficult for others to create their own modifications of the device. In the cellphone, for example, I restricted the circuit to components shorter than 6 mm so that they’d fit within the laser-cut enclosure. This decision isn’t shown in the circuit’s design file but is an important constraint on the components that can be used.
Enclosures
Most of my devices have been housed in cases made on the laser cutter. This has allowed me to use natural materials, such as wood and fabric, that are rarely seen in commercial devices. It has, however, required finding clever ways to combine the flat pieces made by the laser cutter into three-dimensional objects. The radio and speakers use two parallel laser-cut plywood faces connected by struts. The faces are then wrapped with another material (either fabric or veneer). For the cellphone, I’ve sandwiched the circuit board with two pieces of plywood and then covered them with veneer. (In general, I’m not a fan of the finger-jointed boxes found in many laser-cut projects.) All of the designs have fairly simple contours, making it fast to laser-cut them. That constraint has allowed me to quickly iterate through designs by actually making them and seeing how well the parts fit together and how they relate to the electronics. Because the parts are designed in a simple, open source 2D drawing software (Inkscape), they are relatively easy for someone else to modify, whether by simply adding personal text to be engraved or by changing the overall form.
Another approach, which I used for my computer mouse, is to model the circuit board in 3D (using Rhino or similar software) and then use it as a reference when designing the enclosure. This strategy takes advantage of the relative flexibility of 3D printing and the resulting ability to visualize the desired object in software. In addition, 3D-printing parts can be relatively slow, particularly if you are using a high-end machine via an online service. By working in CAD before printing the enclosure, it’s possible to experiment with various designs and iterate on their form and relationship to the electronics. Because this process uses more sophisticated 3D modeling software, it tends to be more difficult for a novice to modify the design of the enclosure, even in a simple way. Conversely, experts can capture more of their work in the 3D model, potentially achieving greater leverage of their skills as they share those models with others.
Assembly
I’ve tried to take advantage of the manual assembly required for my devices by using this step as an opportunity to engage people in their design and production. The radio and speakers include a fabric element that can be chosen by the individual making the device, giving it a unique appearance and personal significance. Other users, particularly those with prior CAD experience, have created more distinctive variations on the design of the products—creating an owl-shaped pair of speakers, in one case, or producing cellphone enclosures from a variety of materials. Assembling a device offers an opportunity and an engaging context for learning or practicing various skills, such as soldering or hand work. Many of the participants in my workshops are motivated by the desire to create a finished device but, in the process, gain experience with and appreciation for the skills involved in the process. In addition, the mere fact of putting an object together for oneself can invest it with a meaning not present for purchased products.
General Principles
The case studies suggest that there is more to making an open source hardware project successful than simply sharing its design files. These guidelines attempt to distill their lessons in ways that can be applied to other open source hardware efforts:
- Use standard parts and materials (in conjunction with your open source design files). For others to make use of an open source design, they need to be able to get the parts that it relies on, whether those are electronic components, screws, stock material, or something else. The more standard and widely available the parts you use are, the easier it will be for someone else to reproduce your design. That might require foregoing components that are convenient for you if they’re not available to others. Note that this guideline is in some ways opposed to some quick prototyping techniques, which may favor the materials at hand regardless of their future availability.
- Understand and design for the fabrication process used. Different fabrication processes are good for different things—and they also have different processes and constraints. By designing for a specific fabrication process, you can take advantage of its strengths, avoid its weaknesses, and optimize for its parameters. Be specific: different kinds of 3D printers have very different possibilities, as do different stock materials that you might cut with a laser cutter or CNC machine. Working with a particular machine or process as you iterate on your design allows you to learn the capabilities of the machine and ensure that your designs are compatible with it. Of course, other people trying to reproduce your design might not have access to exactly the same machine or process, so try to find ways to avoid relying too heavily on individual quirks or features. Pay special attention to the tolerances of your chosen fabrication process. Don’t create designs that rely on a precision that’s not possible to reliably achieve with the machine (e.g., if you have to laser-cut 10 parts to get 2 that actually work, you might want to rethink your design). Hand-soldering is not a particularly exact process; when designing enclosures for a circuit, remember that some components may not end up exactly where the design file specifies they should.
- Pursue unique meanings, functions, and aesthetics. The power and efficiency of mass production make it difficult to compete with this approach on its own terms. Instead, try to find unique values for your open source devices. Those might come from solving a problem that’s of interest to only a small group of people, albeit possibly of great value to them. It might mean using unusual materials or aesthetics to differentiate your devices in ways that might not appeal to a mainstream consumer but might be appealing to someone looking for an alternative. Or the unique value might simply flow from finding ways to meaningfully involve individuals in the production of the devices. Take advantage of the fact that personal fabrication allows you to make devices in small quantities to find audiences that aren’t well served by existing commercial products.
- Find ways to make iteration faster, cheaper, and easier. A key benefit of digital fabrication is that every part it produces can be different. To take full advantage of this ability, find ways to iterate on your design rapidly. Getting direct access to a laser cutter, for example, might mean you can try out a few designs in an afternoon instead of waiting a week or two to get a single one in the mail. Similarly, having the electronic components on hand to solder them to a newly fabricated circuit board will allow you to test that board more quickly and update its design accordingly. Identify the biggest barrier or barriers to iteration and try to find ways to remove them, whether by getting hands-on access to a machine, using software tools to refine your design before fabricating it, or being able to modify or update a part after it’s been made.
- Open source the complements to the hardware itself. Someone who wants to re-create or modify your design will likely need more than just a raw CAD file. Provide whatever additional information seems likely to be useful—for example, parts lists, assembly instructions, firmware, and user documentation. Furthermore, by providing the original sources for these additional resources (not just compiled binaries or Hard-to-edit documents like PDFs), you enable others to update them together with your hardware files when creating new variations on a design.
- Clearly distinguish between open source design files and the products based on them. Selling a physical product is very different from sharing a hardware design file, even if the former is based on the latter. Someone who buys a product may have higher expectations for its functionality, reliability, and safety than someone who makes a device for himself or herself based on your design. If you make and sell products based on someone else’s design, be sure to distinguish between the two, making it clear that the product is from you but giving credit to the original designer.