The moral imperative for open-source hardware.

07 October 2010

As a participant in a recent effort to draft a definition of open-source hardware, I've been carefully considering the practices that constitute it: allowing commercial reuse of a design, for example, and publishing the original source files (not some intermediate, read-only format). This aligns with my generally pragmatic attitude towards open-source hardware, which I see as one of many possible approaches, appropriate in some circumstances and not others.

What this attitude neglects, however, and what the definition-drafting effort has largely omitted is the moral imperative for open-source hardware. Given the increasingly large role that technology plays in our lives, it's critical for us, as a society, to know what it's doing. The more decisions we entrust to technology, the more its design determines the policies that govern us. Writers about open-source have long argued this about software, but it applies also to hardware. Devices - physical electronic objects - embed policy decisions in their construction, decisions that cannot, unless the device is open-source, be examined and questioned.

Consider, for example, the machines in airports that check your bags for explosives. What, exactly, do they look for? How do they report their findings? What else might explain a chemical they consider evidence of explosives? Answering these questions requires access to the design of the machine, its software and its hardware. Without its "source", you might be denied boarding on a flight, even arrested, because of the behavior of a device you have no possibility to examine.

Electronics, computation, and network connectivity are increasingly embedded into the objects around us. Unless we know how they're designed, we won't have control of what they do - or what they do to us.

Sensor Library for Arduino

10 June 2010

As my final project for Joe Paradiso's sensors class, I created a sensors library for Arduino. It provides abstractions for some of the hardware peripherals on the ATmega328 microcontroller on the Arduino: timer 1, timer 2, and the analog-to-digital convertor (ADC). On top of these, it provides higher-level functionality like a sleep function and a function to sample the ADC at regular intervals. I'd eventually like to add something similar to the low-level hardware abstraction to the Arduino core and the class provided a good opportunity to test the capabilities of such an API.

If you're curious, you can read the overview of the library (pdf) or download the library itself: Sensor.zip.

Making Prototypes Work (TEI paper submission)

11 November 2009

My submission to the TEI conference was rejected, but I wanted to share the paper anyway. Here's an excerpt:

Working prototypes have many disadvantages and difficulties. Foremost among these is the time they take to build. In the course, most of the student groups spent fully two weeks (half of the time) constructing their final prototype. Compared to the hours or days taken on most of their earlier prototypes, this was a large commitment. It can also be difficult to estimate the time required to complete an electronic prototype, particularly because they tend to be non-functional until they are almost finished. Almost none of the students in the class slept the night before the final presentations as they struggled to get the prototypes into a demonstrable state.

Electronic prototypes can be particularly inflexible, difficult to adjust or craft as one's conception of the design changes. Component choices and circuit designs constrain the flexibility of the prototype, even as its functioning begins to reveal new possibilities. Tweaking prototypes is particularly difficult for non-technical students who may only know the specific component or piece of code they're working with. The components they’ve already used or purchased often shape the behavior or interface of a prototype.

Another obstacle to adjusting the design of a prototype is that any change risks breaking it completely. This points to one of the other weaknesses of electronic prototypes: their fragility. They are difficult to transport, hard to maintain, and often poorly documented. This greatly limits their lifespan and scope. Although four of the prototype built for the class were later exhibited at a conference, they required significant effort and rebuilding for the occasion. In particular, the more custom electronic circuitry involved (as opposed to standard modules or computer peripherals), the greater the difficulties.

One surprising drawback of electronic prototypes is their tendency to engross and distract students. It's easy to become so intent on getting something to work that you forget its purpose, or fail to consider other ways of achieving the same end. Often the prototype detracts from the design by moving focus from the interface and interactions to the implementation. Although many of the students do not intend to to use electronics later in their careers, in this class, they showed a strong desire to prove that they could make their prototypes work.

Finally, working prototypes (at least in an exhibition) tend to discourage contemplation of the role that the object would play in one's life. Visitors tend to be absorbed by the behavior and functionality of the prototype - playing with it rather than thinking about it. A combination of a model and video can better suggest the relationship one might have with an object outside of the exhibition (see [2] for an in-depth discussion).

Download: Making Prototypes Work - Mellis.pdf

Updated XBee library for Processing

09 November 2009

For a project in my group, we needed to talk to multiple XBee radios from a computer. I adapted the XBee API library for Processing by Rob Faludi and Daniel Shiffman, adding methods for sending and receiving serial data (Series 1 radios only).

To send data to a specific radio (identified by its 16-bit address), you use the xbee.sendDataString16(int addr, int[] bytes) function. There's a new constant, xbee.SERIES1_RX16PACKET, that's returned by XBeeDataFrame.getApiID() for incoming data from a radio. XBeeDataFrame's with this API ID support the getAddress16() and getBytes() methods.

Download: xbee-api-library-for-processing-1.5.zip

The open-source hardware distribution model?

20 July 2009

Most open-source hardware projects (including Arduino) seem not to have taken advantage of the distributed manufacturing models enabled by the open nature of their designs. Instead, we mostly see two conventional distribution models: centralized manufacturing and artisanal production.

The centralized manufacturing model

Centralized%20Manufacturing.png

The centralized manufacturing model is a simplified form of the process followed by most corporations. Here a manufacturer (the small red dot) produces the product and sells it to multiple distributor. Each distributor marks-up the product (represented by the red rings) and resells it to consumers. This makes the product available in many places, but increases the cost to the consumer, as the manufacturer and distributor both take a cut. It works well for assembled products, where economics of scale continue to improve at relatively large volumes. This is the model followed by Arduino.

The artisanal production model

Artisanal%20Production.png

Many other makers of open-source hardware produce and distribute products themselves, a model similar to that of an artisan. This keeps the costs low because there's only one party profiting from a product, and they may not focus on making money. It can, however, limit the product's availability to those places easily reached by the producer. This model works well for kits, which limit the production effort to a level that can be handled by an individual or a small group.

The open-source hardware distribution model?

Open-Source%20Hardware%20Distribution%20Model.png

The natural model for open-source hardware (particularly kits) would seem to be distributed manufacturing. This would involve a number of smaller groups independently producing the same design for local distribution. It would make the product available in many places, but avoid the cost increases associated with a separate manufacture and distributor. PCB production and component purchase seem to yield much of their economies of scale at quantities of around one hundred, so this model would not require a large volume from each producer. The documentation and instructions could be created collaboratively and housed centrally, as all the products would be the same. I'm surprised that I haven't seen many open-source hardware projects following this model. It seems to offer a means for the collaborative production of products, a system that matches the philosophy of open-source hardware.

This blog post comes from a presentation I gave at the Grounding Open-Source Hardware Conference (GOSH) in Banff, Canada.

Making Money from Open-Source Hardware

27 June 2009
View more documents from David Mellis.

A designer makes things. Sometimes he makes the final product; more often, he makes a representation – a plan, program or image – of an artifact to be constructed by others. He works in particular situations, uses particular materials, and employs a distinctive medium and language. Typically, his making process is complex. There are more variables – kinds of possible moves, norms, and interrelationships of these – than can be represented in a finite model. Because of this complexity, the designer's moves tend, happily or unhappily, to produce consequences other than those intended. When this happens, the designer may take account of the unintended changes he was made in the situation by forming new appreciations and understandings and by making new moves. He shapes the situation, in accordance with his initial appreciation of it, the situation "talks back," and he responds to the situation's back-talk. — Donald Schön, The Reflective Practitioner

Value and the Arduino Ecosystem

06 June 2009

There are a lot of people creating value around Arduino: e.g. this experimentation kit from oomlout, tons of videos from Make Magazine, various books, etc. When I see all this activity, two questions come to mind, one selfish and one altruistic. The selfish question is: how can I capture more of this value? The altruistic question is: how can I make these things more accessible and useful to the Arduino community?

To rephrase the first question, should I (or others on the Arduino team) be doing these things ourselves, to earn more of the money flowing into the Arduino ecosystem? I think the answer is "no", I should be doing what I enjoy, what I'm best at, and leave the rest to others to profit from. As Tim O'Reilly says: "create more value than you capture." Still, it can be difficult to be at the center of a movement in which others seem to be reaping most of the rewards. I need to remember that the goal (and the importance) of Arduino is about empowering others to do things for themselves - not selling lots of circuit boards (or kits or books or magazines).

The second question doesn't have a simple answer. Can we do more to publicize other resources on the Arduino homepage? Probably. Should we make it easier for others to build on our software and hardware? Yes. Can we use our position to convince others to open up their work? I hope so. But what's most important? What should we do first? Good question!

Any suggestions?

Open-Source Data Models?

27 May 2009

What could help people share the models they use for generating data so that others can investigate alternative scenarios or presentations of the model (and not just the resulting data)?

For example, in the The Economics of Structured Finance [pdf], Joshua D. Coval, Jakub Jurek, and Erik Stafford discuss the impact on the value of collateralized debt obligations (CDOs) and CDOs-squared of changes in the default correlation and probability of their underlying assets. They present one graph showing the change in value versus the change in default correlation, and another showing the change in value versus the change in default probability. But they don't show the change in value versus combinations of changes in default correlation and default probability. An open-source model would allow someone to calculate these hybrid scenarios, or even to create a visualization allowing others to explore the model in other ways.

To be relevant, of course, such an open-source model would need to be in a format accessible to those interested in using it. What tools do these models tend to be created in? If these are proprietary and expensive, an open-source model may be useful to other researchers and professionals, but not the broader public. Is it possible to make it easier to create or modify these models in free (e.g. most programming languages) or common (e.g. Microsoft Excel) tools?

Alternatively, it is enough to encourage the distribution of data resulting from such models, in the expectation that a comprehensive data set would enable most or all of the uses of an open-source model?

Update: This week's Planet Money discusses another possible audience for open-source (or, at least, shared) data models: rating agencies and investors. That is, rating agencies could publish the models and calculations they use to determine their ratings - giving investors an opportunity to evaluate their assumptions as well as their final judgements.

Testing "Copy as HTML" in Arduino

24 May 2009
 
/*
 * Blink - the basic Arduino example.
 */

int ledPin = 13;                // LED connected to pin 13

void setup()                    // run once
{
  pinMode(ledPin, OUTPUT);      // sets the pin as output
}

void loop()                     // run over and over again
{
  digitalWrite(ledPin, HIGH);   // sets the LED on
  delay(1000);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED off
  delay(1000);                  // waits for a second
}

What is the potential of open-source hardware?

17 May 2009

This is something that Simona asked me recently. To be honest, I'm not sure what the answer is. I don't expect that a large portion of the population will ever design a circuit or even assemble a kit. But perhaps it can provide for the creation of many products that would not otherwise have existed, and which have the potential of mass consumer appeal. The possibilities for industry are also fascinating, but something I know very little about.

I hope that in a few years I'll have a better answer to Simona's question.