Zen and the Art of Open Source Hardware – Day 3

Today, Chris and I drove to and finally arrived in Las Vegas. The odd thing is, this place is a ghost town. Sure, it’s not the middle of the summer right now, and it’s a Wednesday, but when we talked to some of the “locals” who work here at restaurants, they pretty much agreed… the recession has hit. Now I’m not much for casino’s, and I never gamble, so I’m writing this from the hotel room, while Chris is hacking away on the TouchShield Slide. Earlier today, I spent a lot of time thinking and debating with Chris about how Open Source hardware might help in the recession, and why it needs to exist in the first place… at some point it was obvious that neither of us could define what it was we were doing when we shared schematic files and source code with each other… so we dissected it.

Yesterday’s article was written like an email letter I might have written to a close friend of mine. Today, though, I’ve had some more heavy and serious thoughts on my mind, and so this tone will be like an editorial or paper.

In one of my recent interviews, I was reminded and humbled by the observation that many fields of study have cleverly avoided spending too much time trying to define their central organizing themes: biology has never satisfactorily defined “life”, medicine has avoided the definition of “health”, and physics avoids specifying the “big bang.” Perhaps there are some concepts so subjective that they avoid attempts at crisp, clean definitions.

An economic and complexity theoretical explanation for why Open Source exists…

Looking back to the first calculators (Babbage machines, digital accountants, and mechanical computers), there was a clear distinction between the unchangeable, static, immovable “hard” ware. Back then, hardware in mechanical computing devices consisted of gears, cranks, and pushrods. Now, they’re silicon devices that are one-way programmable gate arrays, or components that are connected to each other on immovable substrates (e.g. printed circuit boards). Perhaps there’s something to be learned from this comparison, after all, the old mechanical computers had much more to do with “physical” and “tangible” products, and so the metaphor might help:

Mechanical computers – consisted of static gears, pushrods, pins – assembled and built from blueprints – programmed by encoded holes, knobs, or punchcards

Digital computers – consists of static gates, component connections – assembled from gerber and schematic files – programmed through chip flashers, bootloaders and source code compilers

Both share a common “fixed” dimensionality. In other words, they tend to be physically constrained: the creation and assembly of each involves fixing parts, components, or objects in 3-dimensional space. Also, a part’s relationship to other parts is fixed by the design of the computer, or in other words the “architecture” is pre-determined and largely immobile.

Is this always the case that hardware circuit configurations need to be immobile and static?

When hardware begins to have options, or configurations or possible “states”, it begins to need instructions (or software) to meaningfully configure it and alter its behavior. Borrowing from Wolfram’s complexity framework, there might have a simple tiered rank of complexity in instructions:

Simple / basic – a static configuration state; this merely indicates how to set up a machine once, e.g. where to move the parts, connecting rods, etc. (like an abacus or simple hand-held calculator with no memory or repeat and store function)

Complete – possible to implement many complex behaviors, and algorithms; a lot like simple calculators that support programs (like the HP-90 or TI89 calculators)

Complex – a self-referential, self-modifying, fused relationship between the physical parts and the instructions; this is what excited individuals like Turing, Shannon, and Weiner – computers could be self-aware (like Core Wars, or Brainf*ck, or Forth, or cellular automata)

If a set of instructions is always simple or basic, they’re by definition open source, because it’s immediately obvious what they do. The instructions are a simple mapping, like “put this here” and “put that there” that are visually obvious just through observation or description. A lot of math papers read this way, since they contain complete descriptions of their algorithms, mapping tables, and sometimes even test vectors. At the simple level, pictures or descriptions of the device are by definition Open Source.

If a set of instructions is complete, there is now a meaningful distinction between binary and source code, and there is now a role for a compiler. There is a non-obvious mapping the obscures the source, and makes understanding it difficult. Tools are created like high level languages, macros, compilers, assemblers, linkers, etc. to simplify the process, and abstract the complexity to a higher level, making individuals more productive at manipulating behaviors. Open Source is a choice to release the high level, efficient instructions at the beginning of the compiler tool chain.

Finally, if a set of instructions is complex, it contains self-referential code structures where the storage, and instructions are blurred, losing the distinction between “programs” and “data.” The old game “Core Wars” or the programming language “Brainf*ck” or Forth come to mind – to run them and interact with them, the architecture, data, and instructions are always exposed, dynamic, and interactive. Under this circumstance, the instructions, architecture, and system is by definition “open source,” because the architecture supports it.

Oddly enough, in this complexity framework, “open source” as a “choice” only becomes relevant in a narrow “complexity band,” which is determined largely by the complexity of the instruction set, and the presence, availability or necessity of simplifying tools.

This feels like progress.

This establishes a social and relativistic debate over what “open source hardware” is. And this complexity framework helps us explain many of the current debates in Open Source Hardware communities. Many of these debates center largely around positions of perspective and comparative subjectivity. What is “open source” to some may not be to others, and so “open source” has evolved an ambiguous, amorphous, and unsettling implied definition.

Under the complexity framework, simple, or basic electronic circuits like LED blinkers, analog knob circuits, and pushbutton switches are like building elementary block structures out of Lego’s. Some people can just “look” at the device, or a picture of it, and “know” how to replicate it or build it. Some people I know - like Matt B. - can look at picture of a complex Lego structure from only one angle, and deduce precisely how to build it from scratch. Others - like Chris L. and Limor - can do the same with circuits, even ones that are quite complex!

On the polar opposite end of the complexity spectrum, some circuits are so “complex” that interaction with them at all requires that you work directly with the underlying architecture and components, and the meaning of “source” or “instructions” themselves lose meaning. In a Forth programming terminal or Ruby scripting environment, all words are available to the user to build upon. Compiled binaries are impossible in the architecture by design. Like programming a Forth or Brainf*ck, Core Wars bot, or one of Wolfram’s cellular automata, the program is the data is the instruction set is the interface. The interface is the interpreter is the program is the data. The system is fully transparent to begin with, and so “openness” is a function or attribute of the architecture, not of the availability of “code” or “instructions.” (One could even argue that complex architectures like this are “open source” if documented, and proprietary if not, but that’s quite a loose definition.) In the meantime, physical circuit analogies include hi-fi synth amps with feedback knobs, and many analog projects built from capacitors, resistors, and inductors – in this case, interaction and behaviour does not require instruction sets or programs, they require interaction.

So what about the middle zone?

Somewhere in the middle of this complexity spectrum is a zone where tools have been created to help optimize productivity, human understanding, and efficiency of design and incrementalism. Here, tools have been built to create efficiencies of design and production, and these are similar to building assembly lines, or large pieces of equipment in the Henderson Experience Curve world. And under this theory, it’s why digital electronics gadget and software companies can exist and make profit to begin with; they’re reducing the cost and effort of making a device by finding scalable tools and processes. If the architecture is sufficiently transparent and obvious, there would be no complexity arbitrage opportunity, no simplification or productivity efficiency someone else would be willing to pay for, and so no need for a company (examples would include trying to sell instruction books for obvious topics like breathing, eating, or sleeping). On the other hand, if the architecture is complex and pervasively interactive, the economic opportunity doesn’t come from proprietary distribution of instruction packages, it instead involves individual interaction (examples include services, art, aesthetic design, and healthcare treatment).

So when tools are necessary to advance efficiency and labor productivity, there is a choice to become open source. And this choice is about the distribution of higher level instructions, tutorials and file formats that reduce complexity for others, and improve efficiency and productivity for other individuals.

Seems like I’m finally ready to assert a socially-relativistic, complexity economic definition of “open source hardware”:

In an economic sense, the degree of open sourceness of a hardware project is measurable on the basis of what measures are taken to reduce labor, complexity, and learning curves for others, and consequently maximize efficiency, productivity, and gains for others.

So, what does this mean for someone wanting to make open source hardware, like me?

In no particular order, I’d propose this list of 10 assertions about what Open Source is - a bit like Asimov's rules of robotics:

1. Open source will always be a qualitative – not quantitative – feature assigned to a hardware project
2. Open source is not a binary attribute applied to a project
3. Open source principles mean different things to individuals with varying levels of talent, knowledge, and experience
4. Open source is only a meaningful decision to be made for projects of complexity where meaningful tools have been created to accelerate productivity
5. Releasing source files, schematics, etc. is not by itself sufficient to be as “open source hardware” as possible; it may be impossible to be “as open source as possible” given it means different things to different communities
6. Open source hardware is a function of target community and tool choice, and this can be maximized to varying degrees; the opposite suggests that purposefully selecting tools can be a way to prohibit community sharing while still “appearing” open source
7. Releasing a file (e.g. gerber) in a format that requires expensive commercial tools to interpret is more open source amongst a community of professional practitioners than it is to a community of individual hobbyists
8. Releasing a schematic picture is more “open source” amongst a community of engineers or professionals than it is to a community of artists
9. Open source reduces the economic opportunity for companies because it reduces the ability to optimize and arbitrage product complexity through tools and accumulated knowledge, so companies need to profit in other ways
10. Open source requires a community and audience, and is a function of that community’s shared knowledge, common infrastructure, and tools

Of course, Open Source Hardware will evolve as new projects come on the scene, and perhaps with the arrival of new more powerful, readily available production tools!

I’m exhausted, but also excited. This the clearest I’ve ever felt about “open source hardware”, but I’m sure not everyone will agree. And that’s perfectly ok, because I’d love to know how other people would define “open source hardware,” and what it means to them…

Zen and the Art of Open Source Hardware - Day 2

Today was a long day! Lots of time to struggle and think... and so I'm starting the first of my "diary entries" by pulling together the complete state of my thinking so far. I'm going to focus especially hard to cluster all of the ideas and concepts I've collected in my notes into "topic areas." I want to try to identify a common language, and set of terms that I think might be helpful for me for the rest of the week... and unfortunately it means more problems than answers at this point. Here goes nothing...

If Open Source hardware means open economics, and open community and business models, then it also means transparency. Transparency of file formats, circuits, schematics, processes, community, communications, and even cost and profit structure.

Open source hardware involves real, tangible products, processes, and people. It's not just "imaginary", it's real stuff. Sometimes it feels great, like when someone other than yourself holds something you've made, and they say, "that's cool!" And sometimes it can feel bad, like when you get an email that says, "this doesn't work" or "I didn't get what I thought I paid real money for!"

Recently, for instance, Luca bought an Ethernet Shield from the store, but the store had been out of stock for a week and a half until I got more from the guys at tinker.it. My auto-emailer script on the site has been broken unbenownst to me, and so Luca wrote in and said, "what the heck, where's my stuff!" That simple little email contained so much of why open source hardware is different that open source software: real stuff comes with real money and real people and emotions.


Conceptual Preconditions of Open Source Hardware
So here's some groundwork on the "conceptual pre-conditions" of Open Source hardware. What is it that allows Open Source hardware to work or not? What are some of the major concepts at play?

1) Shared Infrastructure
Open Source businesses and hardware companies are reliant on shared infrastructure. For liquidware, that means shared "virtual services" (I'm going to ding myself every time I use stupid buzzwords) like Paypal, Google's adwords, even web servers and bandwidth. It's a lot like in Zen and the Art of Motorcycle Maintenance, you can be as free as you want to be on a motorcycle driving across the country, but at the end of the day, you're still reliant on the government because at some point, they paved the roads beneath you. And you need the roads to be free. Open Source hardware needs similar tangible shared infrastructure. But who's going to pay for this?

2) Real Time
An Open Source hardware community, project, club, group, or company takes real time. Real time for me means sneaking around the day job, in between meetings, when traveling on public transportation, pretty much any time I can. The funny thing is, so far, nothing I've ever done at Liquidware, Antipasto, Arduino, or anywhere else, has reimbursed the value of my time, and the curious thing is ... that's perfectly ok. In the book Predictably Irrational, Dan describes a phenomena by which people are willing to work or barter or trade huge amounts of things because they'd do it just to help someone else out. Reciprocity, perhaps. But as soon as you put a price tag on their time, they switch into "economic" mindset, and start thinking, "there's no way I'd do that, because my time is worth more than that." Well, Open Source hardware faces this problem every day, because things immediately cost money. Ever part bought in a catalog costs money, just as every hour assembling something "costs" labor. And every time someone's thinking "hmmm that feature would be soooo cool" they're also hit on the head with what I'm going to call the "doh! now I have to reach to grab my wallet and buy this part from Sparkfun or Digikey" factor.

3) Long tails
So there's this guy Chris Anderson, and Clay Shirky, and a handful of others, and they all have the same basic idea: how can we cram as many pretty charts and graphs into a book with lots of jargon, and confuse the heck out of a reader? :-) That too. They also had this other idea that some people like to point to iTunes for; that individual needs can be met in a "long tail" system, because someone can get precisely what they want, even if there are only 1 or 2 of them out there. Perhaps a benefit of Open Source hardware is that if you want a slight permutation (like a Type B mini rather than Type B big adapter on the Arduino), you can take the source code files, and quickly and easily change it. You could even make up your own adapter, and then build one or two boards, and you'd be the only one who had one, but it would do exactly what you wanted. But! That faces a few problems to follow...

4) Experience and scaling
There's this curious little phenomenon I've read about recently called Henderson's Law, or the "Experience Curve." It states that the more volume of something you make, the cheaper it is on a per-cost basis. It seems that everything tangible produced has fixed and variable costs (just like every piece of circuitry has fixed and variable costs too). As someone builds more and more of something, they learn how to make it better, and more efficiently (e.g. by building machines or equipment like pick-and-places or solder-flow ovens or by designing better processes like assembly lines or Mike and my Illuminato assembly station). Normally, this is a good thing. But for Open Source hardware, it's a very bad thing. That's because building something in the long tail at a quantity of 1 or 2 costs just as much as designing something in the "fat" tail (err... whatever you call the left hand side of those 1/x graphs)! The point is that when building and designing a new Arduino (e.g. Illuminato?) it costs literally just as much to build *the first one of two* you build, as it does to build *the first one of thousands* ($300 if you're lucky and get it right on the first try, to $2100 if you're like me and you miss a few traces each time, and reverse the pin headers on the second to last try even though you triple checked them). After you get the design right, the decision to build higher and higher quantity is completely independent, which leads to the next point below. But the more you build, the lower the cost, so there's a penalty to customization. If the "open source hardware scaling penalty" were an equation, it would look something like this: (Between $300-2100 sunk cost) + (difference in price you could have gotten if you could have found others who wanted your one-off customized product) * (volume you actually made). Believe me, this is a very real, measurable, and perceptible cost, and for the Illuminato project, the scale penalty was somewhere around $2000 (but I was willing to spend it because I figured I did it to learn electronics, and so it was worth it to me!).

5) Capital inventory and opportunity cost
I've never taken a "real" traditional economics course, but from what I understand of "opportunity cost" it goes something like this: if money's tied up doing one thing, it could have been doing something else, so pick whichever one makes the most money. Ok. There are two problems with this in the "community commons": 1) profit? who said anything about profit, and who's making it, and where do I meet them? :-) where does it go, how's it accounted for, and who pays taxes on this?, and 2) where does the initial cash come from to build the inventory? Holding aside the first one for now (more on this later though!), the second one is a big problem for open source hardware. In order to achieve lower per unit cost for everyone, especially by building higher inventory volumes, someone has to pay the manufacturers and component companies to buy large volumes of parts from them. So someone has to take a "risk" in order to build tons of something, in order to produce them at lower cost on a per-unit basis. What happens if I decided to build the Illuminato in a really ugly color and no one liked it? Then the 50 I built (on top of the ~50 my mentor bought) would have been a complete waste, and I'd be out a lot of money! Who benefited from my misfortune? The PCB manufacturer, and the parts suppliers! Because they got "guaranteed" sales when I bought my parts from them. That brings me to...

6) The open source "value chain"
I have a couple of business books that I bought from the business book store up in Boston. They're very dense and hard to read (err hard to stay awake reading, to be more precise), and if you're not careful (and completely attentive!) you'll find yourself thinking that "synergy" and "vertical integration" are acceptable terms that have real meaning... they don't! (and if you already thought electrical engineers don't have too many friends ...which is true to a dataset of n=0001b (me)..., a surefire way to alienate everyone is to be an electrical engineer that's spouting business jargon nonsense!) But I digress. The Open Source hardware value chain looks something like this: idea->schematic circuit->layout file->pcb manufacturing supplier company->components and parts company->assembly company->testing->delivery and shipping. In order for true, long-tail, scalable "open source" hardware to work, every step along the way has to be equivalently scalable. Combining the points in the previous paragraph (5) with the point in paragraph (4), the problem is that the component manufacturers don't pass scale savings on their parts unless you commit to buying large quantities. That forces prices in the "long tail" at low quantities artificially high. And that "kills" or certainly limits the long tail customization. Borrowing some concepts from a few biology books I've read recently, it would appear that "diverse speciation" comes at a high cost to the environment. Assuming for a second we believe in a God that created the animals (I don't, but that's another story), that means that it cost God more money to make more diverse species of animals, and so if God wants to keep the total cost of making earth low (after all, he needed to save some money for other worlds), he tries to minimize the number of species. Darwinians might say there's an "invisible force", Adam Smithians might say "invisible hand". As long as any one step in the "open source value chain" does not pass along at-cost economic scaling, there is an "environmental fitness function" trying to shorten the long tail. (PHEW! That was the brainiest thing I've written in years) If my mom had asked me to paraphrase, I'd say, "as long as there's a big company somewhere in the development process that's trying to make money, they are inadvertantly forcing the number of open source projects to a minimum."

6) Ownership and assets in the commons
Can assets be shared by a pool of people, geographically distributed, and virtually connected? I start to imagine fanciful big-wigs talking about "micro-finance" and "peer-to-peer loans" and my eyes glaze over, because I think those are just fancy terms for what could be simpler concepts. But assuming point (5) could be solved by having lots of people pool their money into a single order, and therefore reducing the cost to everyone (hmmm... another example is that t-shirt company, Threadless... but they're a little too trendy for my tastes), the result would be a shared opportunity cost. Depending on which economic jurisdiction you're occupying at any given time, large companies typically get tax shelters and protection in the form of "depreciable capital assets" when they build large stockpiles of shared, pooled assets. The assumption is that they built it, needed it to survive, and so the government encourages them to grow by encouraging institutions to build up assets. But there aren't really any corporate forms that protect distributed, commons-like, shared assets. Communism? Socialism? (ha - insert your favorite anti-capitalistic slogan here). The "common thread" (pun intended) is the virtual firm that the government protects, if not incents to share and stockpiled assets. Can this be done on the internet? Can this be done with distributed accounting? Who knows!

7) Time barrier thresholds
It doesn't really matter if an open source project is "open source" if it takes an infinite time to understand the files, an infinite time to edit the files, and another infinite chunk of time to compile and turn those files (e.g. schematics) into a real product. To give a perfectly real example of this, if Linux were written in assembly code instead of C, it would take me about 30x longer to understand, and a simple change to the core kernel would take me many hours to do (but I could still do it!). At some point, the "I have better ways to spend my time" principle would come into play, and prohibit any productive progress, and I'd probably just turn around from my desk chair and instead watch reruns of The Office. Taking it a step further, if Linux were written in machine code (and, technically, all software, including Microsoft Vista is machine code "open source"), it might take 300x longer to understand, and a simple change might take days if not weeks to implement. Well, the same is true in hardware. Obfuscation of schematics serves the same purpose. It's just like the old days of running HTML source code obfuscators on websites you didn't want people to rip off. People did it to increase or magnify time barriers, as a protective technique. This feels less "open source" than it could be in the "best of all possible open source worlds." Likewise, it seems that "open source hardware" should be conscious of, if not constantly minimizing the amount of time it takes an individual person (not an instituion!) to pick up something and tweak it.

8) Access
From a philosophical perspective, "open sourceness" is a function of the tools at your disposal. Someone with a brilliant reverse-engineering compiler sees a compiled binary as "open source" just as someone with a set of lock-picks sees locks as "open source." Likewise, if someone built the Illuminato with a commercial grade schematics program that only contains proprietary file formats, yet publishes those files in the public, does anyone really consider this "open"? Well, yes and no. By comparison, another company that could afford to pay $10,000's on tools would see these files as "open source". In a similar way, an extreme nerd (*cough* Chris *cough*) could consider a picture of a schematic to be sufficiently "open source", because he's so quick at reverse engineering and laying out parts, that a picture is just as easy for him to use as a raw schematic file... up to a point. At the hyperbolic extreme, I suppose one could say that someone with a scanning electron microscope and atomic realigner would theoretically view *everything* as open source hardware, because they could immediately reverse engineer any physical, tangible object, and manipulate individual atoms in that object to tweak, reconfigure, or alter it. At the risk of irritating my philsophy friends, I suppose someone could even go as far as to say open source was "socially relativistic."

9) Incrementalism
Academics, and professors like to say "a corollary of X is Y" as a way to obscure a more simple phrase like, "X is a lot like Y." Incrementalism is a corollary of time barrier thresholds. :) Imagining for a second that we want to make an Open Source hardware project that mimics Linux or Wikipedia, what would it take? We'd want some incredible changelog and revision systems, thousands of core contributors from around the world, and contributions ranging from functional enhancements (like faster virtual memory paging algorithms) to architectural enhancements (like the holy wars over whether to pre-compile or runtime load-modularize a driver). This last piece I'll call "incrementalism", because that's what it feels like when actually doing it. It feels like biting off a small piece of the project (e.g. Linux), playing around with it, and then "checking it in" again when you're done. A bit like a "github" for circuit files. But to promote this form of work-process, or "productivity", we'd need a distributed file format. I've talked to some of the guys at EagleCad, and even NI, and I'm greeted with the same response... "what's open source?", "who's git?", "where did you get my number?", "I'm on the national do not call list no I don't want to switch long distance carriers." So I suspect it's not going to originate there. But until there's a structural, and architectural schematic-writing file format that encourages "social incrementalism," open source hardware isn't going to see the same prolific productivity that makes traditional magazine and print editors excited...

10) Inclusion and completeness
Every list has to have ten items because humans have ten fingers, and have obsessed about it, and even went as far as creating their number system in base 10. This list ends at 10 because it's getting late and I have a long way to drive tomorrow. Right now, the "open source" hardware community is a distributed smattering of nomadic tribes, wandering the web, picking up fruits and berries ("Arduino" even sounds like it ought to be a small red berry that looks tasty, but is probably tart, and makes your mouth pucker and they put it in flower decorations at Christmas time). At some point, the community will need to coalesce and start to hunt in packs and tribes, and maybe even get ambitious and go after a woolly mammoth from time to time (do NOT watch the movie 10,000 BC the timeline is totally inaccurate). Who are the woolly mammoths and where will they come from? Will they be academic grants, nice guys with extra money to donate to good causes, companies with donation budgets, or others? And when will organized civilizations start? How will the system evolve?


Wrapping up
Well, I don't normally aspire to be terribly removed from practicality, but every once in a while it helps me organize my thoughts by conceptually structuring what it is I'm even thinking about. I'm sure I've missed plenty of ideas, but I'm hoping this will start me off in at least in a productive direction. And at the minimum, now that I've called out these concepts, I don't have to regularly refer to them from now on, I can just link to this post, and save everyone from here on out a ton of unnecessary and weighty conceptualism in future posts!

Oh, and I desperately need to include some pictures in my blog posts to illustrate my ideas better, lest I get too wordy! I'll try better next time...

:-)

Zen and the Art of Open Source Hardware - Day 1

The problem
Open Source hardware. I've been writing up Chris, Mike, Justin, Matt, Chris, Mark, Omar, and my (wow, that list is getting longer and longer) notes from all of our discussions about "Open Source" hardware... and it hit me:

Open Source hardware is not about circuits and schematics and whatnot. I mean it is to some extent in the fact that it's the "hardware" electronic version of "software." But it's also about economics, capitalism, innovation, collaboration, and business models. At an even more basic level, Open Source hardware is about ideas, sharing, building, and exchange of tangible things. It's hard to specify precisely because it's complicated - what's open source, what isn't? But it's only complicated because many mainstream people just aren't used to it yet. Well, over the past few months, I've been writing together a "book" with Justin collecting all of my thoughts, and right now it's a downright mess.

A complete mess... because it just doesn't *feel* right. I've interviewed and read "big think" books by professors like Karim Lakhani, Eric von Hippel, Clayton Christensen, as well as writings by software visionaries like Stallman and Linus. I've talked to fellow folks like me in the community, like Limor, Phil, and Paul. I've met fascinating people along the way, especially at the Santa Fe Institute, and Institute for Advanced Study (impressive, to say the least, if not humbling!)...

But something feels very, very wrong. It just doesn't make sense. "Open Source hardware can't work in today's modern economy" I've been told. "It violates the central ethic of capitalism, proprietary innovation." It just can't work... Or so they think.

The intervention
Well, my head is getting ready to explode. And every time it does, there's just this one little thing I do, that I've always done when I need to sort things out:

Drive across the country.

I'm leaving for LA on Tuesday. I'll be in Las Vegas on Wednesday, somewhere in Kansas or Colorado on Thursday... and who knows what next. Chris is coming with me... and we're going to bring Gamepacks, Arduino's, Illuminato's, TouchShield's, and plenty of scrap paper. We'll take turns driving... and we're going to drive from LA to CT over the course of 6 days.

And all we're going to do is talk about Open Source hardware. In the spirit of open source, anyone's invited :) Just email me if you want to come!

The plan
I'm going to answer some nagging questions that I've had... by sifting through all my notes and articles I've collected over the past few months:

What is open source, really?
Why do some academics and theoreticians claim it violates capitalism?
When can Open Source work? When can't it?
Why innovation and why is sharing good?
Are people supposed to make money from Open Source?
Licenses, the law, patents, and transaction costs - why do they exist, what are they good for?
What changes given the economy and the recession - can Open Source help?
Who does Open Source? Who are the names, faces, and institutions involved?
How does a beginner get involved? How does an experienced person stay involved?
What are the units of analysis in Open Source hardware? Labor, parts, circuits, etc.?
Where does Open Source hardware begin and end?
What are community economics?
What makes Open Source software work? Who does the work and who doesn't?
Why would large companies want to use Open Source hardware or not?
Why would educational institutions adopt Open Source ideals? Open Source hardware?
What is "Open Source capitalism" and an "Open Source business" and can they succeed?
What are similar concepts to Open Source that might lend some ideas?
What is the Open Source brand, label, and "image"; what does it mean when something gets called "Open Source"?


Well, here goes!

New Haven Arduino Hackfest

I had so much fun last night!

Arrived at Panera in North Haven at 5:40ish

Started Programing as soon as I sat down

Mark S showed everyone a case he built for his arduino, inputshield, and two touchshields.
Very cool!

Mark also gave a demo of the fonts library he is working on for the Slide

From what I remember he had quite a few Hershey fonts in variable sizes:
Block
Cursive
Greek
Times Roman
Times Italic
Gothic English
Music
Symbols



Chris and Mark discussing the roatated fonts


The rect function is fixed for the touchshield

We stayed till they kicked us out at 9:40...

Matt mentioned that he is going to get something together in NYC on the weekend of the 7th and 8th.

I can't wait to do this again!

Up and running on the Illuminato in 5 minutes

Matt's been a pretty busy bumble bee during the last few weeks, and so has Mike. They've been working so hard it's actually pretty motivating. So, I've spent the past week or so picking up Matt's original Illuminato core file, and integrating it into a special distribution of the Arduino IDE, to save people all the hassle of manually installing the core themselves. If you want to manually install it, it's still possible, just following the instructions over at the wiki, but you probably have more important things to do ;-)

Here goes:

Step 1: Download the Mac or Windows IDE package here
Mac - the OS X version is here
Windows - the Wintel version is here
Linux - help? I don't have a lot of experience on Linux, sadly

I guess you could call this a branch of the main Arduino IDE tree that David Mellis maintains over at the arduino website. I've started to host over at github (git is a code repository versioning system that Linus Torvalds uses, and is gaining popularity, so I figured I'd try it out) ... thanks Matt (the other Matt) for helping me figure it out.

Step 2: Run the downloaded installer
I met Omar at a local meeting up in Hartford through a mutual friend, and he actually knows how to write real, professional installers (he does it all the time at his day job). He's written the first formal "installer" for the Arduino IDE that I think anyone's ever written! The reason is because that this version of the IDE includes significantly upgraded AVR compilers that fix a lot of the compiler issues I've been having on the Mac recently.

Step 3: Open the Arduino IDE
This one's easy, once the installer is done, just open the IDE from wherever it installed, just like you normally would. The biggest changes to this are completely transparent to most people, because they're all under the hood. But the biggest visible change for now is the fact that in the Tools-Boards menu, you can select the "Illuminato" as a core option.

Step 4: Start playing around with the Illuminato's functions
Also, for anyone wanting to get up and running on the Arduino, usually the "blink" app is the first thing anyone runs. Here's a version of it for the Illuminato, except instead of blinking LED 13, it blinks the bling() LEDs on the back of the board!



//****************************************
//* Blinking LED on the Illuminato
//* ------------
//*
//* blinks the background white LEDs on the 
//* back of the Illuminato board
//*
//* adopted from H. Barragan from Wiring, then
//* adopted from the Arduino wiki by
//* DojoDave at arduino.berlios.de,
//* then updated for the Illuminato by me :)
void setup()
{
   /* Nothing to Setup! */
}

void loop()
{
   bling(ON); //turns bling on
   delay(1000); // waits for a second
   bling(OFF); //turns bling off
   delay(1000); // waits for a second
}

The truth is, for the most part, all the core, base functions are the same as they are on the original Arduino. Matt and I ported the Software Serial to the Illuminato completely since that's the one he and I use the most, and so it can run now on pins 0-7, which lets it support almost every shield out there. Here's a little example of how to use it:



//****************************************
//* Here's an Illuminato software 
//* serial example!
//* ---
//****************************************
#define RX_PIN 3
#define TX_PIN 2
SoftSerial mySerial = SoftSerial(RX_PIN,TX_PIN);

uint8_t inComingByte;

void setup()
{
   mySerial.begin(9600); //let's setup for 9600 baud
}

void loop()
{
   mySerial.print('U'); //sends a 'U' character to the Slide
   inComingByte = mySerial.read(); //reads a character from the Slide
}

When that blinking and Serial gets boring, check out Matt's Apple Sleep-button-like pulsing program over here, which is also downloadable on the App store here.

Don't forget to grab Matt's handy reference chart sheet over here:

All the code in the new branch is posted over here at github. Matt's gotten a lot of emails (Mike too) of some guys wanting to help port the libraries to the Illuminato, so I think that's a perfect use for git, and it'll help everyone keep the code so much more organized :)

The cookies are ready! The cookies are ready!

When I was a little kid, my sister and I would run around outside while my mom baked cookies. (Wow, that sounds cliched and very suburban... oh well, I guess that's what I get for growing up in Connecticut) But I digress ... the point is, at some point, after all our running around, and lots of kickball with the kids who lived across the way, my mom would announce that the cookies were ready, and we'd all run inside, and get comatose and sugar high and then crash (optional: nap). I guess that's kind of what this feels like ... maybe?

After... almost... a... week.... The Illuminato's are done ... every single last, hand-soldering, manually bootloaded, solder-paste aligned, polished, ion-friendly isopropyl cleaned, esd-bagged one of them :-)

I even set up a temporary "shipping center" if that's what you can call it, in the basement. Voila!

Here's a picture of the Illuminato's at the sink, getting ready to get an isopropyl bath - I bought a toothbrush just for the job, to lightly scrub off all the extra solder flux (that's a little trick I learned at one of the informal meetups in Hartford):

Here are all the boards lined up after their bath, getting ready for programming the bootloader:

This is the little connector that I put into the gold holes up at the front to program the bootloader - actually, this is a picture of Mike's hand, because while I washed 'em, he programmed 'em:


And when they're programmed, I put them all into little ESD bags:


So there you have it, now all the extra Illuminato's I had that were bought with "immediate" delivery will go out first thing in tomorrow morning's mail!

That was positively exhausting! But it was also pretty fun, since I really felt a sense of accomplishment building these things with Mike. I wouldn't trade it for the world. There's just something that "clicks" when you see a sketch turn into a circuit, into a pcb layout, into a real board, followed by a functional, working real live thing. In retrospect, I'd almost go as far as to propose a new version of the "man and machine" feeling you get driving sometimes ... maybe a new phrase, like "man and circuit"?

:-)

Beyonce's "If I were a boy" in Morse code on an Illuminato

What can I say? It's been a pretty long weekend :) Mike and I were literally holed up in CT building Illuminato's by hand, and have a couple of pictures to prove it!




I have to admit, to keep things a little interesting while soldering all those little LED's together, I had my itunes playlist running in the background with a few new songs from the pop list. Normally, I wouldn't admit that kind of thing in public, but I suppose the solder fumes are getting to my head.

So since I now know all the lyrics after about 70 times on repeat, I figured it was only fitting to make a nerdy tribute to Beyonce's "If I were a boy" song ... so here's a little program that flashes the lyrics of the song in Morse Code in sync with the real song, and it does so by blinking the white LED's on the backside of the Illuminato, called with the bling(ON) and bling(OFF) commands. I've included the source code, which of course contains a complete morse ASCII-to-morse encoder.



And yes, at the end of the app, I appended a few extra letters... just for fun. :-) I also uploaded all my code to the app store here. This app has zero practical purpose, except maybe if it had a Lithium Backpack on the other side, you could carry it in your pocket, in case you need to communicate with a U-boat or signal mayday or signal for help from the Titanic and the date is 1920 and they can somehow decode +60 Morse code words per minute, visually not auditorily, and they're not weirded out by the fact that you're saying "If I were a boy, I think I could understand how it feels to love a girl I swear I'd be a better man." I think that rules out everyone. And even if they did, they'd probably leave you alone anyway.

Here's a snapshot of the morse code decoder code:


void morse( char m) {
switch (m) {
case 'A': case 'a':
dit();dash();
break;
case 'B': case 'b':
dash();dit();dit();dit();
break;
case 'C': case 'c':
dash();dit();dash();dit();
break;
case 'D': case 'd':
dash();dit();dit();
break;
case 'E': case 'e':
dit();
break;
case 'F': case 'f':
dit();dit();dash();dit();
break;
case 'G': case 'g':
dash();dash();dit();
break;
case 'H': case 'h':
dit();dit();dit();dit();
break;
case 'I': case 'i':
dit();dit();
break;
case 'J': case 'j':
dit();dash();dash();dash();
break;
case 'K': case 'k':
dash();dit();dash();
break;
case 'L': case 'l':
dit();dash();dit();dit();
break;
case 'M': case 'm':
dash();dash();
break;
case 'N': case 'n':
dash();dit();
break;
case 'O': case 'o':
dash();dash();dash();
break;
case 'P': case 'p':
dit();dash();dash();dit();
break;
case 'Q': case 'q':
dash();dash();dit();dash();
break;
case 'R': case 'r':
dit();dash();dit();
break;
case 'S': case 's':
dit();dit();dit();
break;
case 'T': case 't':
dash();
break;
case 'U': case 'u':
dit();dit();dash();
break;
case 'V': case 'v':
dit();dit();dit();dash();
break;
case 'W': case 'w':
dit();dash();dash();
break;
case 'X': case 'x':
dash();dit();dit();dash();
break;
case 'Y': case 'y':
dash();dit();dash();dash();
break;
case 'Z': case 'z':
dash();dash();dit();dit();
break;
case '1':
dit();dash();dash();dash();dash();
break;
case '2':
dit();dit();dash();dash();dash();
break;
case '3':
dit();dit();dit();dash();dash();
break;
case '4':
dit();dit();dit();dit();dash();
break;
case '5':
dit();dit();dit();dit();dit();
break;
case '6':
dash();dit();dit();dit();dit();
break;
case '7':
dash();dash();dit();dit();dit();
break;
case '8':
dash();dash();dash();dit();dit();
break;
case '9':
dash();dash();dash();dash();dit();
break;
case '0':
dash();dash();dash();dash();dash();
break;
case '/':
dash();dit();dit();dash();dit();
break;
case '+':
dit();dash();dit();dash();dit();
break;
case '=':
dash();dit();dit();dash();dit();
break;
case '.':
dit();dash();dit();dash();dit();dash();
break;
case ',':
dash();dash();dit();dit();dash();dash();
break;
case '?':
dit();dit();dash();dash();dit();dit();
break;
case '(':
dash();dit();dash();dash();dit();
break;
case ')':
dash();dit();dash();dash();dit();dash();
break;
case '-':
dash();dit();dit();dit();dit();dash();
break;
case '"':
dit();dash();dit();dit();dash();dit();
break;
case '\_':
dit();dit();dash();dash();dit();dash();
break;
case '\'':
dit();dash();dash();dash();dash();dit();
break;
case ':':
dash();dash();dash();dit();dit();dit();
break;
case ';':
dash();dit();dash();dit();dash();dit();
break;
case '$':
dit();dit();dit();dash();dit();dit();dash();
break;
case ' ':
waitalittle();
break;
default:
break;
}
}


void dit( void) {
bling(ON);
delay(DITDELAY);
bling(OFF);
delay(AFTERCHARDELAY);
}

void dash( void) {
bling(ON);
delay(DASHDELAY);
bling(OFF);
delay(AFTERCHARDELAY);
}

void waitalittle( void) {
delay(SPACEDELAY);
}



Remote Controlled Tank

Now that tons of Arduino shields exist, I was finally able to make a remote controlled robot using modular parts!

The Robot:






Robot Modules:
Arduino
XBee Shield
TankShield
Black ExtenderShield
Lithium Backpack
TriAngles
Arduino Code for the Robot



The Remote:





Remote Control Modules:
Arduino
XBee Shield
InputShield
Red ExtenderShield
Lithium Backpack
Arduino Code for the Remote