Archives for Open-Source
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.
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
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
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?
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.
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.
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.
11 April 2009
Open-source hardware raises a number of economic questions. Primarily: how do unaffiliated individuals collect and spend money? Presumably, this applies to other endeavors, but what are they and how does the answer differ?
08 February 2009
Some general principles for the development of open-source hardware that I hope to elaborate on in the future:
- Use common components
- Use standard layouts and connectors
- Provide clear instructions
- Distribute widely (especially internationally)
- Introduce in person (workshops are good)
- Grow your community
- Meet a real need
- Help others make money
- Build a brand
- Keep innovating
04 August 2008
"I posit that the usability and elegance of any product, software or hardware, tends to reach and seldom surpasses the level that satisfies the taste of whoever is in charge of the product. This applies universally, not just to free and open source software. For example, it explains why Microsoft produces such crummy software even though the company employees thousands of talented programmers and even designers — Microsoft’s decision makers have no taste. But the problem is endemic to open source.
"The people in charge of most free and open source software products tend to have poor taste in user interfaces; people with good taste in user interface design are seldom in charge of open source software projects.
"Put another way, if you have to ask for better design, you will lose. You need to be in a position to demand it." –Daring Fireball
12 July 2008
Open-source hardware requires money. This fundamentally distinguishes the nature of its participants from those of open-source software. In open-source software, the fundamental contributor is the developer, many of whom collaborate in order to create a single software application. In open-source hardware, the fundamental contributor is the entrepreneur, who builds on the work of others in order to offer his or her own products. Open-source software is collaborative; open-source hardware is derivative.
As an example, consider the YBox, a small electronic device for creating textual television channels. The first version of the YBox was created by Uncommon Projects for Yahoo's first hack day in 2006. Yahoo sponsored the creation of 80 kits to be given away at the Maker Faire in 2007. The YBox was then redesigned by Robert Quattlebaum, dramatically lowering the cost. The design was further refined by ladyada, who now sells it as a kit.
In this example, the open-source nature of the design enabled multiple people to improve and redistribute it, as in open-source software. Notice, however, that these improvements were not accumulated in a single, canonical version of the product; instead, each iteration remained as an independent design, documented on its own location. In open-source hardware, a fork is the rule, not the exception.
Also significant is that without the economic assistance or incentive to produce and distribute kit versions of the hardware, the YBox would have remained nothing but a cool hack: a singular instance to read about online, but not use or improve. After the product is designed, built, and tested, the distribution remains – unlike software, which only needs to be put online. This is where the entrepreneur gets involved, without whose investment (of both time and money), the freedoms of the design would go unrealized, just as those of open-source software require a developer to manifest.
Some see this as a weakness of open-source hardware: the process inevitably requires money, and thus can never provide the same broad accessibility as does open-source software. I would argue that it is only a difference: some people can invest money but not time, and others the reverse – either, given the appropriate freedoms, can create a vibrant ecosystem. As we gain time and experience with open-source hardware, we will begin to understand more of the ways in which its operation parallels and diverges from that of open-source software. Both, I think, have a vibrant future.
29 June 2008
The idea of open and open-source hardware has been growing in popularity and practice, but it's not always clear what is meant by the terms. Make laid out something of a choose-your-own-definition, but it's difficult to use a term which can simultaneously refer to a multitude of possibly incompatible meanings.
To me, the definition of "open-source hardware" is straightforward, and analogous to that of open-source or free software. It is, simply, the provision of the digital artifacts necessary to reproduce, understand, and modify a piece of hardware. As in software, the open-source design may depend on closed or proprietary components (e.g. an operating system or a integrated circuit) so long as those may be incorporated into the copy or derivative of the original open-source work. I would exclude, however, those products for which the information provided allows only for the use or extension, but not the reproduction or modification of the original. It's not enough to tell people how your hardware works, you have to enable them to build it for themselves.
Finally, a few notes from my experiences on Arduino, an open-source hardware and software platform for electronics prototyping. Open-source does not entail democracy: you can make your own, so you don't (necessarily) get a vote on how I make mine. In open-source hardware, forking can be a valuable method for making more products available to the community, rather than a last resort in the face of irresolvable differences. Additionally – and this is crucial when many entities sell competing versions of compatible products – open-source does not imply the right to another group's identity. As with open-source software, you can use a project's work as the basis for another, but you can't claim that it's part of the original.
For more information, check out ladyada's take or see the short but suggestive write-up at openhardware.org.
I hope to write more about topics related to open-source hardware, but felt it was important to start by defining the term. Check back for more.