Anyone Can Share an App!!!

It's official...

Anyone can go to the app store and share there app for anyone to easily download.




I recently uploaded this paint app for free.

How to make your own bottle raft and get in trouble

Nooooooo... Ok, I was getting pretty excited to go to Make NYC this past week, but sadly it was postponed and now I just found out I can't make the new date. I was going to share with everyone Chris and my complete adventures of the USS Bottleware (or maybe the OSSWH Bottleware)? :)

P.S. this post has nothing to do with Arduino, Open Source Hardware, Open Source Economics, or anything like that. I was just going through my old pictures and found this, so I thought I'd share!

This story is a little old now, but a few summers ago Chris and I decided we didn't have enough danger in our lives, so we were going to build a sail boat to learn the principles of sailing. We didn't have enough money to justify buying a used boat, or even renting one, so we built a bottle raft and then later stuck a sail into the middle of it. Unfortunately, I don't have any pictures of the raft when it had it's blue tarp sail, but I'll say this much: it didn't work. We had to paddle pretty hard to keep it going, and it definitely did *not* tack against the wind.

So without further ado, here is my personal guide to building a bottle raft -the getting in trouble part comes at the end of the post:


Step 1: Find bottles

Find lots and lots of bottles. This was really hard for Chris and me until we discovered something... Thursday night was recycle night a few towns over. So we popped along in a little nearly broken down Subaru, and went from house to house picking out all of their nice bottles. We had the pick of the litter too, so we chose hardy, durable bottles.

You might think that 2-litre soda bottles are nice, but they're not. The problem is that they're too narrow, and they'll slip and pop out from under the boat if you're not careful in later steps. Also, I've seen a lot of tutorials recommend using 1 gallon Poland Spring water bottles - which are equally terribly, because the tops just pop off when you submerge the bottle. A good rule of thumb is: if you can take the cap off the bottle in a popping motion with your thumb, the bottle will leak, let in water, and you'll sink. On the other hand, using bottles with screw caps is ideal because they're thicker.

The perfect bottles are detergent and bottled water ones:


No, I'm not sponsored by Tide. In fact, I hate the way it makes clothes smell, but they make great raft bottles. Chris and I did calculate that it was almost worth just buying detergent just for the bottles, since we'd just dump out the detergent and save time scouring the neighborhood for the good bottles. If you value your time, then yes, it's worth just buying detergent and dumping it out. But if you don't, and you have good music to listen to, and a good story to tell neighbors when they see you taking their bottles, it'll probably just take a few hours. Another rule of thumb:

• An average family household does laundry once a week, and runs 2-4 loads of laundry
• The average bottle of detergent is good for 20-30 loads of laundry
• On average, a household is buying a new bottle of detergent once every 8 weeks, or every 2 months
• That means a household throws out a detergent bottle once every 2 months, or ~60 days - this is about right from my experiences growing up having to do laundry, so this checks out
• That means that you'd need to visit 60 households before finding 1 detergent bottle
• Not all households put their bottles in a recycling bin (let's say optimistically 80% do), so now you have to go to 75 households
• This seems bad, but there's a catch - recycling only happens 1 day a week, so everybody batches their bottles together at once, and so you actually get to reduce the time step earlier by 7, since you're synchronizing when you're checking everyone's detergent-throwing-out-status, so now you have a good chance of finding a bottle with every 10-11 houses you check
• The final step is a good and bad thing: some people seem to employ a multi-phase, or "stage-gated" recycling process (if you will), by which they keep a recycle bin in the garage, that they fill up first, and only when it's full will they put it out for collection. This is bad because this means there are some houses just sitting there - in front of your eyes, and you KNOW they MUST have a detergent bottle waiting to recycle, but you just can't GET IT! On the flip side, however, you know that when they finally do put their bins out, there's a pretty good chance (about 50%) that it will have a detergent bottle if they took 1 month to fill up the bin. On the other hand, there's a 25% chance the bin will have a detergent bottle in it if they let the bin sit for 2 weeks
• The nice thing is that you can easily tell if someone has put a recycle bin in front of their houses, so the transaction costs of checking are very low - just drive by the house, and if there's a recycle bin in front of the house, then check it for bottles. If not, don't check for bottles.
• Last tip: there's about a 1 in 50 chance there's a detergent bottle in the trash bin, hidden from plain site, but luckily most people put detergent bins on top of the trash, so there's a fairly good chance that if they didn't recycle it, it's the huge thing preventing the trash lid from fitting on snuggly, and you can see it. Again, visual inspection reduces time taken.

I can't help it - here's the Laundry-Dumpster-Diving-Time-Tradeoff-Equivalence equation:

W - loads of laundry / week (typical: 2-4)
L - loads of laundry / bottle (typical: 20-30)

New bottle bought = bottle thrown out

New bottle bought = L / W (range: 5-15 weeks)
New bottle bought (days) = L / W * 7 (range: 35-105 days, or ~1-3 months)

Pr - probability that house throws out detergent bin in recycling (assume: 80%)

Divide by 7 for single day-synchronization:

L / W * 7 / Pr / 7

Pt - probability that house throws out detergent bin in trash vs. bin disappears as kid's school project (assume 90%, round lower for technically-inclined neighborhood, or around the date of science fairs)

((1/Pr)(L / W * 7 / 7) + (1/(1-Pr))(Pt)(L / W * 7 / 7))

Tr - Time required to visually inspect recycle-bin (~5 seconds)
Tt - Time required to rifle through trash bin deposited detergent bin (~30 seconds)

Simplified:

((1/Pr)(L / W) + (1/(1-Pr))(Pt)(L / W))

So clearly, for the return, it's not worth spending the ratio of time on checking garbage, since you'd expend a *lot* (~20x) more labor for a garbage-bin collected detergent bin than a recycle bin collected one. Plus they're really messy.

So:

Number of houses to check: (1/Pr)(L / W)
Time spent checking: (1/Pr)(Tr)(L / W)
Time spent fetching: Tf (assume: ~10 seconds)
Time driving from one house (with recycle bin) to another: Th (assume ~60 seconds)
Total bottles needed: B

You have to drive and check every house: (1/Pr)(L / W)(Th + Tr)
You only have to fetch when you find: Tf * B

Total time needed: B* ((1/Pr)(L / W)(Th + Tr) + Tf)

Search: ~700 seconds / detergent bottle
Fetch: ~10 seconds / detergent bottle
B (from next section): ~35 bottles

Total time required: ~7 hours of driving around looking for bottles


How does this funny math validate empirically? From experience, about 1 in 8 houses has a detergent bottle, you're willing to do it for about 3 hours before you get sick of the smell and want to shower, so you spread it across two nights, and two weeks...

Which is just what Chris and I did :)





Step 2: Calculate how many bottles you'll need

You would have thought this step would come first, but here experience has taught me otherwise. Start by finding out how difficult it is to acquire good, solid, quality bottles, and then work backwards. This will tell you what kind of design to go with. For instance, I've noticed that the Northeast seems to be a fiend for large detergent bottles, while the Midwest prefers the smaller types. The South seems to not use detergent, so you don't find too many in their trash (oh, and I don't think all Southern states have recycle night trash collection either, which makes finding bottles even harder).

Anyway:

• Each gallon of displaced water is about 8 pounds (about)
• 2 grown guys plus non-floating part of the boat is about 400 pounds (adjust accordingly)
• 400 lbs / 8 lbs = 50 gallon bottles

1 detergent bottle is between 1.5 and 2 gallons, so you'd need about: 25-33 bottles

Here's the part that trips up mathematicians. Notice that this is only for break-even. If you meet break-even, as Chris and I discovered, you get a boat that usually is partially submerged on one side, or just sort of hovers there in the water, bobbing in and out.

Add another 10-20% bottle buoyancy, however, and you're actually capable of floating above the water most of the time.

The truth is, you never really know, so Chris and I grabbed tons of extras, and we chose the number based on how many we thought we'd need, and then brought extras just in case.



Step 3: Design ideal boat

For Chris and me, it was something like this:

Notice the punt-style main mast sail (forget how we thought it was going to attached to the base), the triangle shape out in front (forget that it would just steer sideways and not help thrust at all), and the outboard motor (for when we got tired of rowing).


Step 4: Reality sets in

A trip to Home Depot indicated a few problems with the plan: how to attach the mast to the platform?

Nevermind the outboard motor, since Chris actually had one lying around. We did notice, however, that it would require it's own ~25 bottles to float, not to mention the undercurrent would probably rip the bottles off the base, so we scrapped that idea. But only after debating about it furiously.

So instead, we got a few wood planks and 2x4's, and built a solid reinforced base (that's Chris with the drill):


Construction fencing makes a great way to secure the bottles to the underside:

You'll actually notice that there were some 1 gallon jugs in there... that's how we discovered that they're horrible sources of "robust buoyancy."

It was quite simple, actually - we used a staple gun to attach the orange fencing to the board, and that was pretty much it.



Step 5: Put "boat" in water

And, if religious, this would be the appropriate time to pray to an appropriate deity... actually, we also started to draw a crowd, since it was a weekend, and this was the New Haven shoreline. I'm pretty certain the New Haven shore crowd doesn't usually get a chance to see this type of work (stupidity?) in action...


That smug grim on my face is because someone just yelled out, "you're going to sink" and I'm thinking, "you're not on a homemade bottle raft, and I am, mwhahahahaha." Chris and I took turns on the "manual outboard engine location". We built a separate platform for the outboard engine, thinking at worst if it tore up the bottles underneath it, we'd still have the other section to be safe on. Seemed to make sense at the time.



Step 6: Get in trouble

We stayed on the raft for about 5? hours, and had no problems. In fact, these pictures were taken at night time, for proof - this is us looking back at the New Haven coast.




The one problem we had, was we made a serious tactical error. We brought a Weber grill on the boat too, thinking, sure, at some point we were going to get hungry and why not cook out on the boat?

Both Chris and I failed to anticipate what the view from land would look like with a fully lit Weber grill and charcoals starting light up. Apparently, someone called the police, thinking we were in danger and on fire and maybe trying to commit suicide in a blaze, when really we weren't, we were just hungry. The police drove up on that ramp in the second picture above, turned his siren on, fired a flare into the air, and called the mini-coast guard (do they exist?).

Anyway, we threw the Weber grill into the water to douse the fire, and rowed back into shore. The policeman said we were perhaps the dumbest guys he'd ever seen, but said it looked fun, and next time we should either not try the cook-out part, or maybe pre-cook everything and bring it out in a cooler.

The Life and Times of an Open Source Hardware Newbie

Hi! I’m Chris (Chris #2 it seems), and it’s been months since I’ve gotten to hang out with Matt. We live in different cities but met through mutual friends who are into DIY electronics and used to hang out all the time. During the past few months or so I accepted that he was just incredibly busy with whatever it was he was doing. Well, as it turns out, he’s become better friends with someone/something by the name of Arduino. :-)

After looking deeper into the details of Matt's hobby, I realized that I didn’t understand a word that was coming out of his mouth, so I tried to figure out whether my incomprehension was a result of stupidity, or sheer, bent up, jealous rage. It was both. At any rate, I found myself wanting to fit in and decided to sort out what the hurdles of adopting this new hobby would be. I also found myself facing a challenge, not having any kind of engineering background, or any experience dealing with electronics (you know, besides iPods and every other trendy consumer electronic device that 99% of the world owns).

Matt was curious as to whether or not someone so inexperienced, incompetent, and pedestrian (remember when we were friends?) could crawl their way into open source hardware and start understanding his passion. So I asked him how I could get started. Before I finished this sentence he blurted out, "Arduino Duemilanove", which I made him spell of course. I was told that they were about $30 and he was nice enough to tell me that I could get one here...

He left me with these two steps to begin with:

1) Buy an Arduino

2) Explore the official Arduino website here

In the mean time, I’m going to do some research on what an Arduino is, does, and what the community is talking about. I’m curious as to how many other people are interested in this hobby and how long it takes someone with no such background to become accustomed to the Arduino and the entire open source hardware community. That’s a perfect fit for me, because I have absolutely 0 background in computer programming, engineering, or anything related to Arduino stuff!

I’m excited and can’t wait to report my progress. I know that when I was an undergrad the best way I picked up new subjects and topics was to learn them in parallel with my friends taking the same courses. If anyone wants to tag along and has any questions for me, or Matt, or the other experts out there, please let me know so we can struggle together and feel sorry for each other when things don’t work - ha!

Thanks guys,

Chris D, #2, etc.

The First Meeting of the Open Source Economics Council

Thanks to everyone who came out for pizza last night at the Open Source Economics Council! It was really great to meet some new people and extremely interesting to have so many different angles on the topic, all around the same table. I really had no idea that the discussion would take the direction that it did, and to be honest, a little surprised at how heated it got!

Suffice to say I came away with more questions than answers it seems, and as I’m pulling together some of the notes I jotted down from our chat, I wanted to share a couple of the big ones:

• Since hardware is actually tangible and costs money to build, how do you deal with inventory risk that isn’t sold?
• If things are cheaper at higher quantities, and there are enough people who want one, how do you achieve scale without having a company?
• Open source is about collaborating in terms of time, and tools, and in the case of hardware, money. Time and tools are easily shared in the realm of open source software (through systems like Github), but what systems need to be built for open source hardware? How would they be structured?

A few other thoughts I had around this made me start organizing a “wish list” of a few of the things that came up as the big problems open source faces, like what the ideal solution would have to address. Maybe the “Principles of Open Source Hardware Economics” or something…if you’ve got a better name let me know!

Thinking from the standpoint of a community of engineers, the system should:

• Reduce margins and cost for the community
• Minimize the risk and opportunity cost of unsold inventory
• Provide incentives for Open Source projects that do not want to incur transaction cost of establishing a corporation
• Allow the build and distribution of low-quantity products (e.g. niche applications)
• Allow the build and distribution of non-scalable products (e.g. non-VC fundable) –these two would be the “scale issue”
• Align rewards and profits as closely as possible to those who contributed – that sense that of wanting my money to go to the right cause and the right people. John put it really nicely during the discussion, “It’s not about someone making money, but rather that the money being made is going to fund someone doing something, rather than someone doing nothing”. So I’m happy with whoever spent their time, knowledge and energy, to get some of those profits to keep going…but it’s a different feeling when I pay a whole bunch to support the investors behind the people who invested in the builder, because those folks didn’t actually build my gadget.

So ideally the system would:

• Minimize economic transaction costs to high-paid non-laborer economic types
• Reduce barriers to contribution
• Reward innovation and encourage new ideas
• Encourage project-level (not necessarily firm-level) competition

And it would be set up to attract people who:

• Participate because they are getting as much or more out as they put in
• Do it not just to make money and profit off of others for free
• Have rare, inimitable skills who volunteer their talents for recognition or fun
• Are willing to build a more sustainable hardware innovation system
• Are willing to teach others for the gratification of helping others learn new skills

From a structural standpoint, there are systems set up to support time and distribute collaboration, but there’s not really a system for sustainable funding. And since it is the open source economic council, I thought I'd close with some food for thought on funding.

Even now, when "sustainable open source" comes up, it focuses on sustaining a single project rather than the environment. Don't get me wrong, there are certainly ways of making money from open source hardware, but it still feels like all the business models are on a one-off basis, where I build something for someone funding it, and there has to be a secondary purpose for it to get off the ground. I’m starting to go down the path of an open source, community bank or foundation. Something that can sustainably fund open source products or projects and cycles earnings back into the community. I'm really excited and it definitely feels like we're all one step closer to figuring open source economics! Of course, if I learned anything from yesterday, this is just one angle, so if there's something I've missed, I'd love to hear it!

Aardvark Gadgets!

Catching up on last weeks blog activity... I couldn't help but put the pieces together!

1.) Chris uploaded an app for his Arduino
2.) Matt uploaded an app; he actually used his app for his TouchShield, and Chris' app for his Arduino
3.) Omar uploaded an app; he created an gadget file for the ide so you can merge these 2 apps into 1 file
4.) My Turn!


I first downloaded all the apps, starting with the Arduino Windows version.

Next I installed the Aardvark

Run! -> Next! -> Yeah, Yeah, Program Files! ... Next! -> Install! -> Finish!

All Programs... Drag new Arduino.exe to my desktop

Quadriple click Arduino.exe! (hehe, double click works too)

Open: ArduinoSlide.pde (a gadget that includes an Arduino and a Slide!)

Finally opened my first gadget file!!! (thanks Omar)

Next is where I add Chris' and Matt's code...

First Chris' Arduino Forwarder App...

I selected the Arduino picture in the gadget window on the left

Then I pasted Chris' Forwarder code into the code tab

Now Matt's App...
I selected the TouchShield Slide picture in the gadget window on the left
Then I pasted Matt's InputShield_Display code into the code tab

Uploaded my code to each device

Saved my gadget!

Illuminato, Part 2 - and the open source economics experiment

So the illuminato ran out a couple weeks ago, and it's somewhat more expensive than Matt and I ever planned, especially building in small quantities. Matt's old professor, who paid for the last batch, isn't going to be paying for it this time around, not to mention trying to raise money from friends family and former professors is about as easy as pulling teeth! I've been trying to figure out just how to raise the money to fund this open source board in the most open source way possible, so I asked around. I've gotten a lot of awesome suggestions, and the most common ones had something to do with seeing if individuals might be willing to chip in upfront. Maybe a few people will buy a couple extras. (By the way, I'm simply blown away by the business savvy I've heard from quite a few folks *ahem* Elwyn :-)

Besides the community, there's one other way to get inspiration - from someone who's recently returned from a cross country drive thinking about nothing but this stuff! After reading through Zen and the Art of Open Source Hardware, I talked with Matt over a whiteboard and lots of paper. The end result? My eyes are red (I imagine Matt's are too), I have a ton of loose, scribbled paper, and dry erase on my hands and face. I'm really not sure here, and maybe it would be nice to have a little chat about this in person. But I think I might just have an idea, and I'm going to spend this weekend drawing this out a little more neatly.

Well, there's this little pizza place right by me, in midtown Manhattan, and I'd love to chat with anyone who can join me for some pepperoni and the first session of the "Open Source Economic Council" (Sorry, I was watching the news when I came up with it, and I couldn't resist!)

Open Source Economic Council

Date: Tuesday, Feb 24
Time: 8 PM
Location (in NYC): Famous Ray's, 831 7th Ave (btw 53rd and 54th).

Pizza's on me. See you there!

A little bit of spaghetti...

You know, I've always been a huge proponent of open source software…to me the open source spirit is the spirit of the internet. I've been benefiting from open source software for years and I've learned a lot from looking at the source. The only thing is that I've always had to reconcile one problem: I'm a leech…I have never contributed to an open source project. Well, there was this one time….back in college…..

It was the Spring semester of my senior year, I was almost ready to graduate but I caught something…infectious…Hardware. I had spent 3.5 years avoiding anything silca related but I guess my will wasn't strong enough. Something about making a light flash on a circuit board was just so cool; I was hooked to the Arduino. I started attaching more light, and then more lights until I had attached all of the light that I could…and then came the accelerometer and well…you get the idea.

In the flurry of wires and LED's that I was tossing around I did poke around the Arduino source code (I am a CS major…after all)…I even made some changes and added a kind of packaging; simple but it was there…I needed it to keep track of the gadgets I was making and, being a poor college student, I would reuse the same parts over and over again so nothing stayed the same. I had such a hard time keeping track of things with so many open sketches and transferring things to the wrong board etc…that, in the spirit Larry Wall, I just created a tool to help me keep track of things. It was a simple file format that would load into the Arduino IDE and allow me to switch between things…nothing fancy but fully functional. I would've continued working on my little enhancement had I not graduated and become victim of the 9 to 5….

Flash forward to an Alumni two months ago where I ran into my old lab buddy Mike and my excitement when I found out he's still playing with Arduinos. After getting into a discussion about open source he asked me what ever happened to that edit I made of the Arduino IDE source. The source was on my old computer that was collecting dust in the basement and…well…long story short he convinced me that the community was in need of something like this and I figured this was my chance to stop being such a leech…so I dragged my computer out of storage and fired up my Java juices (and a pot of coffee)!

I was a little slow at first getting back into coding a Java app, but I took a strand of code here, a little bit over there…tossed in some of the updates that had been made since the last time I had coded and viola! The Aardvark Release. Why the Aardvark? Because I'm a sucker for alliteration and African noctournal mammals of the Orycteropus genus.

In the sprit of open source and social coding I've committed everything to gitHub. By the way, github is awesome, I can't even call it version control because it is just so cool to work with. Chris and I had a lot of fun collaborating together on this and I want to see more commits so we can do this flashy disco light thing so please if you've got an idea, go ahead and stick a fork in this angel hair :)

Head over to the App Exchange to get a copy!

And now for a little screen scrape action...

Gamepack with InputShield_Ellipses

Matt recently posted the InputShield_Forwarder for the Arduino/InputShield and the InputShield_Display App for use on the Slide/ExtenderShields.

Since then, I've been selfishly wanting to build my own creations off those apps, so I simply slotted my own code into Matt's main loop, and deleted his text display stuff.


Which morphed this App into a graphical display of the Joystick position. It also shows how to scale and translate analog values into more meaningful data. Sinced I mostly used ellipse's to draw the graphics, I called it InputShield_Ellipses!

Getting started with the GamePack in 3 steps

Taking a lesson from the Mark and Omar school of "this is how real programmers actually do things", Chris and I decided to spend some time hacking together this simple little set of apps to dramatically simplify how to get up and running and hacking the GamePack as soon as possible. It's also a bit embarrassing that it took this long to do. I'm starting to get the idea that this is the week of "catching up on the obvious stuff".

The general idea is that the GamePack is an Arduino, InputShield, and TouchShield (either Stealth or Slide), and this tutorial will get anyone up and running with a very simple app to start writing a simple game on the GamePack. It includes two programs: one program for the Arduino that polls the InputShield and sends a packet of information to the TouchShield, and another program for the TouchShield that displays the information on the screen.

Step 0

Build the GamePack by snapping the Arduino and Lithium Backpack to the back of a DoubleWide or DoubleTall ExtenderShield, and then place the InputShield and TouchShield on the top of the ExtenderShield. Wire up the Lithium Backpack to the TouchShield using two small wires so the circuit is battery powered and portable. Then use a USB cable to connect the Arduino to your computer.


Step 1

Download the InputShield forwarder app here. Open the application pde file with the Arduino IDE. If the GamePack is connected to the computer, go to the Tools->Board menu option and select "Arduino". In my case, I have a Diecimila, so I select "Arduino Diecimila". Then select from the Tools->Serial Port menu option the serial port the GamePack is connected to the computer via, which in my case is COM9.

Press the Play button in the Arduino IDE to compile the code, and then press the "Upload to IO Board" button to download the code to the Arduino module of the GamePack.

Now the Arduino has code that continuously polls the InputShield. The InputShield needs to be set to "Mode A" using the mode selector switch.


Step 2

Download the InputShield Display app here. This code runs on the TouchShield Slide and displays the coordinates of the Joystick, and the status of the buttons as simple text. Open the pde and source code with the Arduino IDE. Since this code runs on the TouchShield, go to the Tools->Board menu option and select the TouchShield option. In my case, I selected "TouchShield Slide".

Press the Play button to compile the code, press the reset button on the TouchShield, and then click the "Upload to IO Board" button to download the code to the TouchShield module of the GamePack.


Step 3

This shouldn't totally be necessary, but just in case it didn't work, reset the GamePack. If it's running on USB power (probably, if it just got programmed), I usually just unplug it and plug it back in. On the other hand, if it's running the Lithium Backpack battery, just flip the switch and it will reset the battery.


Step 4

Wiggle the joystick around, and press the buttons, and have fun :)




Step 5

Laugh at how mundane and simple this little app is, and hack up the TouchShield code to make it into a real game... and maybe email me too if you want to write it together!

In the meantime, I'm working on a mini version of Mario right now, which I'll publish just as soon as I get it in a basic working form...

TouchShield processing bubbles

I can't believe it took me this long to upload this little app, converted to the TouchShield Slide. It's the fun little Processing demo app where you touch your finger to the screen, and various sized bubbles are drawn in a concentric radius around your touch... the bubbles get bigger the further out you go.

This is made possible with Mark's new and improved super-fast (and I'll add, actually functional!) graphics library :)

I've uploaded the code to the app store here, but in the meantime here's the heart of the functionality (notice it's still copied line for line from the Processing demo book, since all the functions are ported!):


for(int i = 0; i <= width; i += 20) {
for(int j = 0; j <= width; j += 20) {
float size = dist(mouseX, mouseY, i, j);
size = size/max_distance * 15;
ellipse(i, j, size, size);
}
}


Oh yeah, and it occured to me that I've done a really bad job at uploaded all the quirky little source code snippets I've written for the TouchShield Slide over the past few months, so I think I'll do my best and try to release an app or two each day the next week!

Zen and the Art of Open Source Hardware - Finale

It’s been over 5 days since Chris and I came back from our cross country trip, and the radio silence only means one thing… have you ever had an idea dumb enough that it completely engulfs everything you do since, and then you don’t do anything else until it’s done? Well, that’s pretty much what happened. Chris and I had an idea on the last day, and got so wrapped up in it, it took this long to settle down long enough to write about it! So here goes…

The Open Source Economy

There’s been a lot of talk in newspapers, and even Slashdot about the potential for Open Source principles to aid the current economic crisis. Hype aside, one thing is sure; there are more than superficial overlaps between the Open Source system and the real economy.

How can this be? In any economy, the basic units of analysis are markets, exchanges, values, and products. In Open Source, though, almost every one of these “concepts” has an analogy...

So this means that the system of Open Source isn’t so different from the real economy – at least in theory. Both involve the production of a thing, or output, they involve coordinated effort on top of systems or exchanges, and there is an implicit or explicit value to things. So there’s a translation between both systems, probably a little like the chart above.

But what makes each system work? What is the “WD-40” of each system, that allows any analysis or meaningful production happen? In the real economy, some would argue it all comes down to money. There is some notion of economic value that all activities, behaviors, or contributions can be expressed. In the Open Source system, it’s not as clear. Some of the “conceptuals” would say that trust is the underlying unit, and that the whole system only works because people value trust, and because there is an exchange in trust. On the other hand, from a practical note, speaking from my own experience, Open Source Software feels a lot like time. When contributing to a project, people are making a conscious decision to spend time on one project over another. Projects take a lot of time to make and complete, whereas the economy takes a lot of money to operate.

And that brings us to Open Source Hardware. The problem is, OSHW requires a lot of time and it takes money too. It can’t work with only one, and not the other. If you throw a lot of time at making a project schematic, it doesn’t become a real thing unless you also throw money at it. Likewise, you can’t just throw money at building a project or paying someone to build it, without also taking the time to design it, architect it, and eventually code it and debug it.

Here are some theories that might need to be tested in order to really understand the differences between the Open Source Software time-based economy, and the Open Source Hardware time and money-based economy:

• Maybe Open Source Software works because people dramatically undervalue their time when contributed to causes
• Maybe Open Source Software can work but Hardware can’t because the same reasons why people might donate time are different when it comes to money
• Maybe the same reciprocity or “pay-it-forward” mentality of time doesn’t hold true with money?

Where do Time and Money Come From?

If Open Source Hardware takes time and money, where do they come from? Currently, time comes from individuals (like me) that have faith in the system, and believe that Open Source Hardware means something. So I spend my time hacking away at gadgets and projects making them work, just because.

Meanwhile, the money comes from a number of places. One place it comes from is companies and stores. Other times (like all the stuff at the liquidware store), it comes from individuals that pool their money together just for fun. It can also come from grants, donations, or institutional causes.

When money comes from individuals, it needs coordination mechanisms to make sure individuals are repaid, or get their money’s worth. When it comes from institutions, it often needs to support a cause or mission. And finally, when it comes from companies, it usually needs to make a profit. This last one is particularly nagging in the Open Source Hardware economy, because it suggests someone is making money off of Open Source. This tends to contradict the notion of the “free as in beer” ideas of Open Source. But is it necessary? Open Source Software can work without the presence of a profit-making corporate entity. Can the same be true for hardware?

Assuming for a second that it’s not true, and companies are required, then I’d put forth a simple framework for when it’s appropriate for someone, anywhere in the ecosystem, to make a profit from Open Source Hardware:

By this framework, profit-making is a good thing when it’s maximized and re-invested back to the community. On the other hand, profit-making is a “bad” thing (or “less good”) when it funds traditional business model reasons, like mitigating risk, distribution, portfolio, or scaling. Why? Because each of these business models involve taking advantage of the efforts of others to make profit. The profit doesn’t make its way back to the individuals who contributed, so it’s “less good” than a system that directly rewards and incents individuals and their time. This assumes that the end-state desired outcome is a system in which individuals are directly contributing to a shared community, and collecting as many of the benefits of their time as possible.


Clusters in an Open Source Economy?

While we’re talking about Open Source economics, I’m not taking anything for granted. Just because there are companies and stores in the real economy, doesn’t really mean you need them in the Open Source Hardware economy. To put it another way, if you were going to build an economy from scratch around Open Source ideals, what would it include?

I’ll start by describing what I imagine is the Open Source Hardware process. Like a chemical reaction, Open Source Software starts with people who contribute time, a “reaction” occurs, and the output is a set of source code that does something. Meanwhile, Open Source Hardware starts with people who contribute time, and money, a “reaction” occurs, and the output is a set of physical, tangible hardware products.

As groups of people contribute, eventually they coalesce into “clusters” in which there is a critical mass, center of gravity, and a formal “project” is created. Sometimes there is a single, large cluster, like Linux, Firefox or Wikipedia. The field of Open Source Hardware, however, is far from mass-centralized, and instead there are groups and clusters of mini projects. One could argue that today there is a central Open Source Hardware project, the “Arduino” platform, surrounded by a set of smaller communities. It might look something like this:

This “cluster”-based theory of Open Source Software and Hardware treats the Open Source Economy as a collection, or centralization of time and money. To have Open Source Software, you need clusters of time. To have Open Source Hardware, you need clusters of time and money.

Well, we all know where the time comes from – it comes from nights and weekends when you’re not working, and you decide to work or play on a project. You learn the project architecture, formulate an opinion, and decide to contribute to it. Actually, on a personal note, that summarizes my experiences with Open Source Software quite nicely!

But now that we want to do Open Source Hardware, I have to answer a more difficult set of questions:

• Where does the money come from?
• What is the best way to coordinate and centralize money?
• How can the money be best structured so that the community reaps the benefit?
• Can money be sourced from a distributed group of individuals or institutions, or does it have to come from one party?
• Does money always need to generate interest through profit?
• Are there other ways to sustain money in a community?
• Who is incented to contribute money, and why?
• What are good and bad reasons to contribute money to Open Source Hardware?
• Does money always have to be structured in a corporate form?
• Should Open Source Hardware have companies that make profit, or are there other ways?
• What are examples of successful production economies that didn’t involve profit-seeking corporations? Can they provide lessons or motivation for Open Source Hardware?

Clearly, this is far from over. I guess I should have expected it, but it left me with more questions than answers. At the minimum, however, I feel satisfied knowing that the questions I’m confronted with now are much more precise than the ones I started out with. I now know my next challenge: solving the Open Source Hardware financial structuring problem.

Paint Program for My Slide

I always liked finger painting... but now that I'm older making a mess with my fingers is kind of annoying... so I created a painting program on my TouchShield Slide!

6 Different Brush Sizes

The brush radius can vary from 1 pixel to 6 pixels.


7 Different Colors: Red, Green, Blue, Yellow, Orange, Magenta, and White


I am sharing my code for this project over on the app exchange...
I even made an icon for the app!

The top left corner has a picture of the app has a picture of the brush size and color that is selected.

In the top right corner of the app is a "clear" button to clear the screen.

10 things the arduino *can't* do...number #1

It's that time of the week again...Friday afternoon. Before heading out for the weekend, I logged into my Youtube account and discovered some videos from almost a year ago. And I realized almost every blog post on here has been about something that the Arduino can do. (Yes, there's quite a few things that fall into that category.)

On the lighter side, Chris D, a.k.a. Dungo, and myself, self-proclaimed n00bs to the Arduino made these videos about what the Arduino *can't* do. Chris and I thought really hard and came up with a list of ten things...here's number 1.

Hope you enjoy it!

Antipasto_cores commits MessageScroller

When Matt B. said github rocks, and everyone who is a fan of Linus Torvalds should use it, I was interested, but like Mike usually is, I was skeptical.

Fast forward a few months later, passing through some github maturity scenes, and I eating my own words, while being spoon fed by Curtis Morehead's oled_objects branch of the antipasto_cores code base.

Curtis made some some sophisticated updates to the TouchShield Stealth's Oled drivers, that conceptualize the screen as an object, well done! In fact, I had a difficult time photographing the app because of the super efficient text scrolling capability,


It sprinkles in some object orientated design to allow for console applications, such as the one above, that can consume text data. This could be especially interesting to someone who spends 25% of their time serial debugging messages, like me.

Antipasto Cores activity feeds are now active, so with a quick glance at liquidware.com, checkout how Matt B made some tricky web hacks to capture the github data stream with his "Latest Code on github" section.



Thanks Matt, but now everyone can see how I typecasted a (float) to an (int) on that release. Yea, yea, spotted, but I should have known better, whoops ;-)

Anyways, I just finished testing and merging Curtis's fork back into the TouchShield Stealth core. So you want to play with it, pull down the cores and drop them into the Arduino hardware/cores directory to test with some example code,

//*******************************
//*
//* MessageScroller Example
//* for the TouchShield Stealth
//* By: Curtis Morehead
//* 
//*******************************
#include "Oled.h"
#include "MessageScroller.h"
#include "colors.h"

MessageScroller scroller = MessageScroller(&Display, &BLUE, &BLACK);
int i = 0;

void setup()
{
  Display.Initialize();
}

void loop()
{
  if(i%250 == 0)
    scroller.AddFormattedText("This is line %d", i);
  i++;
}

Zen and the Art of Open Source Hardware - Day 4

Hi it’s Chris this time,… I’m posting this a day late because it took a while to edit together from the notes Matt and I have been taking. In the meantime, hello Utah, Arizona, New Mexico, Texas, and Oklahoma! Today, we decided to try out yet another format for the conversation, a bit like the turtle and the hare dialogs in the book, Godel, Escher, Bach. It’s still a bit rough, but it’s somewhat transcribed, and we handed off the computer back and forth at each gas station refuel. Unfortunately, since it's a day late, there are some ridiculous ideas we've had since this, but it wouldn't be right to just skip ahead, so here goes...

Chris: So how did you get started in open source hardware?

Matt: Back in the 90’s, I was in school studying electrical engineering, and learning computer architecture and VHDL, when I started getting a little adventurous, and wanted to make new cores and processor architectures on my own. Why? Just because. I pretty quickly learned that FPGAs are almost entirely proprietary, and the smallest thing requires a license for $10k’s. Then I stumbled onto opencores.org, and that was my first exposure to open source hardware... funny because back then no one even knew what an Arduino was, and yet these days open source hardware is almost synonymous with the Arduino. Anyway, I really like how Justin described the three waves of open source hardware... I think it really describes well how the major communities have come and grown, and each one stronger than the other… How about you, how’d you get started?

Chris: Actually, I’m a car guy, and so I’ve always gotten a kick out of trying the “hack” and increase the performance of an engine… whether for power or fuel efficiency. The problem is that the holy grail of engine modification and performance enhancements is the electronic fuel injection system. These systems let you tweak the fuel delivery, oxygen mixture, and compressions, but are very closed and proprietary. About 5 years ago, I was hacking away trying to make one myself from scratch, and I started flipping through Circuit Cellar magazines, studying schematic diagrams, and eventually learning how to make EFI controllers and enhance a mechanical system… and that’s where I learned about the MegaSquirt, and decided to build the LCDash as open source as possible.

Matt: What made Open Source hardware approachable for you?

Chris: That’s not an easy one… because it really wasn’t that approachable in the car world. The Arduino world is quite a bit different though. It’s approachable because the basic things work with very little effort. I’d probably assign 95% of the success of the Arduino platform to that silly little LED blinking program. So I guess it’d have to be the simplicity and low learning curve for me. What about you, what was the hardest part about open source?

Matt: Realizing it was real stuff. Sounds mundane, but that really took me a while to “click.” I’d also come from coding websites, software algorithms, and what some guys might call “computer science.” A lot of guys like computers, then go into computer science, and somewhere along the way I think they get a little misled into thinking that’s all there is to it. I think some guys just go out and build websites for the sake of websites, and they don’t actually do anything useful in the real world. That’s how I feel about a lot of those funny Web 2.0 sites out there… it really surprises me that people are trying to make them into companies. A lot of them would work much better as cool little hobby projects and things you build because you like to do it, not companies that only make money from ad-revenue! I guess the other thing is that you can be sloppy in source code, and you only really need to focus on the algorithm. Memory leaks, tables that don’t have closing tags, etc. don’t really mess anything up until things get really big, so you don’t have to be perfect. But physical stuff is like making art… there’s a role for a different type of craftsmanship in hardware design versus building a website. When I built the Illuminato, it hit me on the head all of a sudden. I guess the last thing is that for all the talk about collaboration and community, I was surprised that all the open source hardware projects tended to be just the creation of one guy. Like Dave Mellis and the Arduino. I still really haven’t found what I’d call a “distributed, collaborative” hardware development project, where a lot of people build a device together, sharing files and whatnot. But how would you have fixed that?

Chris: I think you’re definitely talking about the tools, and I’d agree. They’re miles and decades behind the software tools that have allowed open source to work. The biggest problem with the files (we discussed this yesterday) is that they save into a monolithic format, not a distributed one. That means it’s very difficult for one person to build a large project, upload it to a source code repository system, and have other people come in and tweak little sections of it. If you look at Linux, you’ve got these guys checking out modules and sections one at a time, and optimizing pieces. So a guy like Linus becomes the architect of the system. We don’t really have the tools to allow anyone in the open source hardware community to become architects. So everyone is just a circuit builder and schematic drawer, and there’s no division of roles. The real problem is that none of the PCB software developers seem to care much about this problem, since they’re perfectly content making licensing fees!

Matt: So what’s the real problem this tool or distributed file format is solving?

Chris: I’d call it “collaborative circuit building.” But no matter what you call it, I think it all comes down to allowing groups of people to build circuits together. Licenses, costs, prices, and all of that are really important, but not as important as building the infrastructure and tools first to allow people to do it in the first place. But speaking of expenses, who pays it? Who pays for open source hardware development?

Matt: I guess I do! Ha, just kidding. Grants, friends, former professors, people we’ve met along the way that have some spare money to throw at hardware projects. That’s where the money comes from. And I guess you could say those are the people paying for or funding open source hardware. Someone finds a really clever way to spin a grant proposal to include the development or purchase of some cool new tools, and some of those tools get custom built for the specific purpose they’re looking at. And then at the end of the development, they just give it out to the community. So I guess you could say grant funders and educational institutions are the ones really paying for open source hardware to work. But I think it’s also interesting to look at who makes money from open source hardware. The truth is, anyone makes money from open source when they’re getting more money than the total cost of their parts (e.g. they’re making a margin) or getting reimbursed for their time. Looking at open source hardware today, the folks actually making margin are the PCB manufacturers and assembly shops, and the online stores that are selling open source hardware devices. If you keep tracing it back the “open source value chain,” component manufacturers are also making money, and then I suppose you could even say the companies that are building fiber sheets for PCB’s are making money too. So plenty of companies in the production-to-selling process are making money, just like a traditional world.

Chris: So should open source hardware projects be sold with profit margins?

Matt: In open source software, the finished product is free (as in speech and as in beer), and a few companies like Redhat make money off of services and support, and others like Sun and IBM make money through association with the principles of open source. But in open source hardware you have a tangible product, and you get to decide what you’re gong to charge for it. Well, I think the cost-plus-margin way is the wrong way of thinking about it. I think open source hardware should be priced and sold like crafts and limited edition art pieces. You’re not really looking at the cost of the components, you’re looking at the labor, effort, and work someone put into a project, and you’re saying, “ok, I’d pay X for it.” And I’m buying more than just a thing, I’m buying what it stands for and what it means. You don’t buy art as the sum of the cost of the canvas and paint that went into it, and similarly I think that “pricing model” should be applied to open source hardware. Right now, the whole open source community seems to be stuck in a system of double marginalization. Someone builds something, they add a margin on top of it, someone else wants to resell it, so they add another margin on top. Anyone who’s actually buying open source hardware is paying margin on top of margin, and that’s just silly. There has to be other ways. How would you price it?

Chris: Well, I guess if we’re talking about the craft of making something, and comparing it to art, why not sell something at the price someone would want to pay, in a way that’s recognizing people’s collective efforts. You suggested pricing it like art, but I think that’s probably wrong too. You want to match up the people who contributed with the reimbursement and rewards. The problem with having the seller set the price is that if they make margin, how (if at all) does the profit get back to the group of people who contributed? Perhaps you want to recognize a number of things – people who put in the time to build something, and people who put in the money to make it. But above all, recognizing the value of time I think is important.

Matt: So what do you think the value of someone’s time is when they’re making open source hardware?

Chris: Yesterday when we were talking about the long tail idea, I was thinking, if someone spends time building something that benefits a lot of people, is their time worth more than someone spending time that only benefits a few. At the extreme, what is someone’s time worth if it only benefits one person, them? Isn’t that the idea that a lot of the guys hyping the long tail idea really mean? I guess you could say the opportunity cost is worth what they could have been making doing something else with their time. But I think most people (like me) have jobs, we’re happy in those jobs, and probably wouldn’t be doing something else in spare time just to make money… instead we’re doing something to have fun. I enjoy programming, so opportunity cost doesn’t really work either. I guess you could say the time value is worth the number of people that benefited from something, times the amount of time or money you saved them with your project. That works when you’re building productivity tools, but not with games and silly programs like your morse code pop song app. Those things don’t have financial value (sorry to say), aren’t saving people money, aren’t being used instead of making money, and so the opportunity cost or value issue comes right back. I think that’s the real problem… almost all of this work and stuff is getting made and built in non-work, non-financial, non-economic time. It’s all happening outside of institutions, outside of companies, or like you say, “beyond the boundary of the corporation”… so what’s the value of having an institution or company any more?

Matt: Well, I’ve read a few places that many of the people who actually work on “open source software” projects, like Linux, Open Office, and Eclipse, are actually full-time employees are real companies. They’re getting paid to do open source, especially by big companies. Thinking about why, you get into all kinds of strategy questions: is IBM funding open source as a way to unseat Microsoft’s OS in the high end server market, where they sell big mainframe computers (how would you even measure if that’s working)? Or perhaps it’s so that the total cost of ownership of IBM Linux-equipped machines is cheaper than HP servers running Windows? Is Sun funding Open Office to unseat Microsoft Office, in order to promote Java over Visual Basic as an enterprise programming language of choice (if so, seems a bit far fetched). So maybe it really is like sports; someone’s paying for it, and getting other types of benefits. Or maybe it’s like prime-time t.v. programs; everyone knows the television shows like The Office and Heros and 24 are just great filler in between the commercials, which are the thing that really make money (even when you include the effects of DVD sales of the full season, they don’t add up to even a commercial break’s worth of ad fees!). But this doesn’t feel right … this feels like every other “well-intentioned” movement; some company comes along and finds a way to use it for their advantage. Seems wrong to me.

Chris: I can just imagine that. Here I am, getting this mental image of thousands of distributed hackers programming away in their apartments late at night, when actually they’re commuting into work from 9-to-5, sitting in cubes like me and you during the day. I wonder how many truly lone, non-employed open source hackers there really are? I guess the biggest problem I can see is that full time coders are going to write more code than part time guys working nights and weekends. And a platform isn’t as strong if you have just a few guys coding and testing it. Anyway, I also wonder what it is about California, New York, Boston, the Netherlands, and England that have so many Open Source communities. Looking around Utah, Oklahoma, Indiana, I understand there are cities, but I wonder if they have critical mass to have physical communities?

...lunch, the topic being open source names, brands…

Chris: So what’s the value of open source and open source hardware, and is it a brand?

Matt: It seems like a project becomes a brand when many people have contributed to it. It seems a little funny that when assigning a name to a project it loses the person’s name that built or contributed to it. That’s why I feel funny calling an open source project by its project name. Regardless, some projects get popular and develop reputations, and then after the fact, contributors in the community also get those reputations by association. I wonder if that’s how large companies are thinking about it? People who run companies want to associate themselves with brands that have good reputations, and they gravitate to good open source projects.

Chris: So “Open Source hardware” is a brand, and that means it does have value because sharing and being open tells a lot about the motivation behind what finally gets sold. If something is open source hardware, it tells you it’s being built to be used, not marketed. It means someone’s not trying to up-sell you on features or functions that it doesn’t really do, hoping that you’ll be convinced into buying it. Also, open source hardware has another type of value, because it tells you something about what you can expect when using it. On the upside, you know that you’re going to be able to change it, edit it, read schematics, solder your own stuff onto it, and maybe even completely change what it’s supposed to do. On the downside, you know it’s probably not 100% fully tested and functional, there will likely be some rough edges, and you’re not really dealing with a warranty or service plan, or anything like that so if it breaks, the response is probably, “uh oh, can someone help me, please?” and not, “you’re a horrible company, I want my money back, and I’m suing you.”

Matt: There’s a whole other topic we haven’t even started talking about, about open source licenses, warranties, and what people’s rights are in a community and when they buy stuff from the community. Companies typically play the role of “limiting liability” in order to protect individuals in a company from getting sued into losing all of their personal assets when something they made breaks. I think some historians even trace some of the first “limited liability” clauses to U.S. railroad company grants (as opposed to the first companies, which I think were around the trade charters given to shipping expeditions). Anyway, the point is that companies usually protect individuals by letting them hide in a way behind a corporate liability shield. On the other hand, in the open source world, companies seem to be created for exactly the opposite reason – for helping to create liability for service, quality, support, etc. Makes me wonder whether a “company” is really the right organizing form for open source hardware. I’m not convinced! Maybe that’s why liquidware isn’t really a company, it feels much more like a group of random guys that each pitched in to pay for some part of the infrastructure… Mike pays for the credit card processing, Matt for the adwords, me for the Paypal integration, you bought soldering stations… what do you call a bunch of people pitching in their own money for the sake of it, with no expected return? Stupid, right? :-) On a serious note, there are many different organizing forms than corporations, so maybe that'll be the topic of more investigation tomorrow...?

...dinner on the run...

Chris: Well, at the end of every day, we’ve asked ourselves whether what we talked about has changed how we think about the meaning and practice of open source hardware. Has it?

Matt: Yes, I think it has, and it had a lot to do with our tools conversation. I’m starting to view “open source hardware” more as a verb instead of a noun or adjective because it requires a community of people sharing and contributing. That sounds a lot more like a collective set of actions rather than traits a product or project has. What about you?

Chris: Definitively, in fact, by “doing” open source hardware, it means that you’ve contributed to the development of a tool or platform. So I’d call open source hardware the process of contributing to building tools that constantly change. The reason you’d want to do this is because tools typically become outdated and obsolete, but if they’re open sourced, they can evolve with time. Anyways, this reminds me it’s probably time to contribute to the evolving definition of open source hardware on wikipedia, even if it means getting into edit wars :-)

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!