Open Source Hardware Panel

A couple Fridays ago was an informal panel discussion of things related to the Open Source Hardware movement and included some big names from the community.

I think it’s important to understand the tone of the panel: there was a declared drinking game that you had to drink whenever anyone said “community”. It was a light-hearted event that generated some excellent discussion. Early on the in evening Bre stated:

Open source hardware is not about the hardware, it’s about the infrastructure to participate.

I’ve had very little (arguably no) direct involvement in OSHW (open source hardware) and this declaration just seemed incredibly profound to me and really underlines the difference in communities between OSHW and FOSS (free and open source software).

There was a fair bit of discussion comparing the two communities, and of course given the crowd, there was a strong bias towards how the OSHW community operates. After learning more of the philosophy of OSHW, I’m inclined to prefer their approach over FOSS’s.

It was said that a lot of the differences come down to atoms vs. bits. It allows for business models to be more obvious because there’s a physical product with a more explicit cost while software isn’t tied to the physical. This also allows software to be a religion in ways that hardware cannot.

Another difference is that the next TODO of FOSS is documentation while the next TODO of OSHW is the consumer product. There are probably those that disagree with this statement, but I found it to be valid and to point out what I feel is a hugely discriminatory factor in FOSS. Overall, FOSS is poorly documented. It’s just not a community priority. Of course there are exceptions, but there is a large contingent of FOSS that seems to pride itself on steep learning curves and insider knowledge. This makes it very difficult for “outsiders” to join. In particular, it makes it more difficult for individuals who don’t exhibit the stereotypical white male nerd traits to participate. OSHW seems much more conscious of inclusion and group contribution.

My limited experience with the OSHW community has been through publications like Make Magazine, Maker Faire and the London Hackspace. All of these are male dominated spaces, so I didn’t expect the gender parity of the OSHW panel. FOSS panels would kill for this kind of gender representation. I find hackspaces (or at least the one in London) to be incredibly similar to FOSS demographics. I’ve even seen it drive away men from Big-C Creative industries because of the huge embrace of nerd culture.

My assumptions of the gender dynamics of OSHW fall apart when I actually think about them. I can much more easily name female contributors to the hardware world than software. Off the top of my head: Leah Buechley, Limore Fried, Becky Stern and now can add the panelists listed above.

I think once you’re inside the engineering club to some degree, in the process of assimilating it can be easy to forget how to be inclusive to those without engineering backgrounds. While at the ITP Camp, and especially by attending the sessions taught by Tom Igoe, I’ve certainly come to appreciate the tools that have been developed for those without computer science or electrical engineering backgrounds, in particular Processing and Arduino. I previously was frustrated with the platforms as I thought it dumbed-down the content excessively and didn’t ensure that proper engineering concepts were taught. However, I now appreciate that they get people writing code and working with microcontrollers without requiring entry into the exclusive clubhouse that is engineering. Learning the technical bits can come later. Finding an initial passion for creating and engineering needs to fostered first.

Sneak Peek at Android + Arduino + Processing

I’ve fallen very behind in posting about the sessions I’ve been attending at ITP Camp, but the one I attended last night has so much exciting potential, it’s skipping the queue of posts of previous sessions. The session description and info can be found here.

A couple months ago Google announced their Open Accessory Developement Kit. While everyone was really excited that they decided to use Arduino in the platform, there were some concerns about some of the engineering decisions that were made. The good folks involved with the development of Processing care about low barriers to entry for programming and feel that the workflow of Eclipse with the ADK could be a bit more user-friendly.

Processing for Android is already released and it is indeed very easy to get something running on an Android device. The exciting new development is in the photo below. This is an Arduino Mega ADK for Android. Only a couple dozen currently exist and as Tom Igoe is helping with the development, he has a box of them at ITP. They will become less exclusive very soon as they go on sale 4 July.

Arduino Mega ADK boark

Once everything is released, developers/artists/designers/people can used the Arduino environment and Processing to created objects that interact with the physical world and are run by Android devices including all the connectivity that they offer. Super amazing stuff.


  • Processing 1.5 or greater
  • Arduino Environment 1.0-beta1 or greater
  • Android ADK 2.3.3 (need API 7 to set up Processing and API 10 for Arduino)
  • Not yet released Arduino ADKLib for Processing
  • Android device
  • Arduino Mega ADK for Android
    • On a side note, starting in Arduino 1.0, Arduino sketches will no longer have .pde as the extension but will begin sporting the .ino extension. This means no more confusion between Processing and Arduino sketches. It is important to know that all .pde sketches from previous Arduino environments (including the examples) will have their extensions automatically changed to .ino. So older versions of Arduino will not recognize the new extension and it will appear that your examples and sketches have vanished. Changing the extension back to .pde will solve that, but reports are that Arduino 1.0 has been running sketches from older versions without any problems.

Entrepreneurship at ITP

The first two sessions that I attended at the ITP Camp were focused on entrepreneurship within creative industries, though from two very different angles. The first was lead by Lawrence Lenihan, a venture capitalist and Adjunct Professor at NYU, and the second by Tarikh Korula, an ITP alumnus and founder of Uncommon Projects, and Doug Barnes, a lawyer and friend of Tarikh’s. The two sessions were different in several ways, most obviously because the first was focused on product-drived industry and the second was focused on service-driven consultancy.

Read, FIRE!, Aim – product-driven business development. The slides were a subset of teaches at NYU. The slides he used for the session can be found here.

Here’s a summary of some of his main points:

  • Don’t write business plans, write business presentations. It’s not worth the time and effort to write a full 40+ page document that will quickly be out of date. It’s better to put energy into communicating what your business does.
  • Form your business around easing a pain. It’s better if it’s a pain that you are passionate about easing. Use tools like Google to see if people are looking for what you want to sell.
  • Figure out how much it costs to acquire a customer.
  • Know the difference between entrepreneurial opportunities and venture capital opportunities. Just because your business is not attractive to a VC doesn’t mean it isn’t a worthwhile pursuit.

Entrepreneurship for Creatives – consultancy businesses. It focused on concrete details, particularly in contract negotiation that design consultants should be familiar with along with other general advice on striking out on your own. It was an excellent session that was well attended; here’s just a few highlights from the evening:

  • Scale is a huge challenge for consultancies. The time to money ratio makes it difficult to grow as you can only work so many hours.
  • Someone in your business needs to be able to handle sales. The whole thing fails if no one is a salesperson.
  • You don’t have to do business the stereotypical white guy way.
  • Pick two: cheap, fast, good. The clearer you are at communicating this with clients, the happier everyone will be with the end result.
  • Contracts do not need to be written down and certainly don’t need to be full of opaque legal jibberish. But writing things down as a matter of record (for instance in e-mail exchanges) is good practice.
  • Educate yourself about IP. Your lawyer can’t tell you what your business model and IP model should be. Only you can make that decision.
  • When allocating IP, pay attention to what you get to retain. What do you really need to own? What does the client really need to own? Be sure that you’re only agreeing to sell things that you own and can afford to sell.
  • Decide what IP you need to own in order for your business to exist and grow, and then let everything else that is unimportant go.
  • When you’re about to blow an estimate on a project, tell the client. Being up front and communicating keeps everything civil. As a service provider, it is your responsibility to be clear with the client.
  • Questions about incorporating and forming legal structures become important when there are more than one of you (e.g. parters, employees).
  • In the US, generally tax and accountancy issues increase as you move from sole proprietor to corporation.
  • Can set up contracts with mixed rates: fixed rate for certain assumptions; hourly rate when those assumptions fail.

Other sources of information that were recommended were Fred Wilson’s blog and the presentation I’ve embedded below.

2011/03 Mike Monteiro | F*ck You. Pay Me. from SanFrancisco/CreativeMornings on Vimeo.

Both session leaders recommended the book Getting Real by 37signals.

These were the first entrepreneurial events/talks that I’ve attended in the US. I didn’t really have much interest in the area until I started my PhD, so I’ve attended business development events in the UK. The thing that really stood out for me during these sessions was just how American-centric they were. In the session with the VC I asked how some of the topics he was talking about translated to Europe, particularly the UK. He responded that he didn’t know and wasn’t interested in knowing. He was only interested in US markets and companies. It was too hard to fire someone in France. While the American-centrism was less blatant in the consultancy session, there was a curious lack of acknowledgement of anything other than the US system. (But oh did the talks of how much money you need as a buffer make me so appreciative of the NHS. Estimates of $400+ a month for healthcare.)

Both talks were focused on New York, as one would expect given our geographic location, but I found it curious that they lacked any discussion of any other place in the world or even just the US. The exception was a side note in the VC talk that countries such as Brazil and China will soon blow up as the next big thing.

In both sessions there was a lot of discussion of the current bubble, though the difference in tenses used was quite interesting. The VC viewpoint was that the bubble is going to crash in the next 18 months and is already approximating the end of the dotcom bubble (Ashton Kutcher was noted as one of the significant signs). In contrast, the consultancy talk believed the bubble is still on the up, though of course acknowledged that it will one day end.

1-in-1: Bee #

1-in-1 is a like a mini hack day, but I find it refreshing that it is without prizes or even formal presentations. The goal is to complete a whole project in one day. You’re advised to not stretch too far or try to learn some huge new skill set. This is the full list of what everyone is working on today.

I am starting on a new project that I wanted to do since I learned about Sing-a-ma-jigs, a singing children’s toy. They aren’t very big in the UK, so when I was back in the US for Thanksgiving last year, we bought a couple (the red and purple in the photo, I found the white one at Goodwill yesterday).

The Choir

Their big draw is that they sing with each other and harmonize. We were then very sad to find that they don’t actually communicate with each other. Some mildly clever music theory (arpeggios from the same key) are used to ensure that multiple toys sound good together. It does result in a lot of very satisfying perfect cadences.

What I would like to do at the ITP Camp is develop toys that do actually communicate with each to spontaneous create harmony. I haven’t worked out the details yet, but the first step is to mimic the original toy with my own prototype that can be improved upon. So today, I am building a bee #, a singing bee. Below is the Bee in all his glory before he finds his voice.

Bee Before

So first, breakfast was consumed. It involved a square bagel.

Sing-a-ma-jig at Breakfast

Then I began working out a simple prototype circuit. I’m using an Arduino and basically building off this tutorial. I wanted to use the Adafruit Waveshield, but I did a poor job preparing and didn’t realize the opamp and dac were missing from the kit. This is the circuit.

Prototype Development

Simple Trigger Circuit

I then began performing a delicate surgery on Bee. I cut out a hole in his face slightly smaller than the speaker.

Bee Before Speaker

Then I crocheted a single crochet chain around the opening by cutting little holes around the edge and picking up stitches.

Bee in Progress

I ended up threading yarn into the crochet to create a drawstring to tighten the opening.

Bee with Speaker

When I went to Goodwill yesterday to find a stuffed toy that I could cut up, I found the white sing-a-ma-jig. I was initially very happy that I had a trio, but when I got it home with my other two, it didn’t harmonize. It sounded awful with them. It also operated slightly differently – it started in the song mode when first turned on, unlike the other two which start in the harmony mode. Today I recorded each one individually and used Sonic Visualiser to analyze the audio. I figured out the keys for each one and it’s now very clear why they don’t work together: the red and purple are in D Flat Major and the white one in is B Major.

So I now know the key my Bee needs to be in to harmonize with each sing-a-ma-jig, and unlike the sing-a-ma-jigs, it’s flexible and can change.

The code is available here.

Bee # from Becky Stewart on Vimeo.

ITP Camp Kickoff

This past Wednesday marked the beginning of the ITP Summer Camp 2011. The ITP is a graduate program at NYU that’s been around for 30 years. It’s a little hard to define, but it’s at the intersection of art, design, and technology and has an excellent alumni network.

The camp has been going for a couple years and it’s meant to be in the style of an un-conference like bar camps and hack days. The idea is for around 50 people to gather and hang out in the same physical space for a month. The space is the 4th floor of a building off Broadway near Washington Square Park in Manhattan, so you can’t really argue with the location. It comes equipped with things like 3D printers and soldering irons and, even more importantly, it comes with staff to train and assist with using that equipment.

The more structured part of the camp occurs in the evenings and weekends as most people are doing some kind of day job. (I’m working in the Department of Music a block over during the day.) The evenings and weekends are filled with sessions lead by ITP staff and camp participants. I’m particularly excited to attend Tom Igoe’s sessions on Basics of Physical Computing using Arduino Part 1, 2, 3, and 4. The full schedule (which is still being added to) can be found here.

I’m going to try and keep up with blogging my experience here, but this is 30 days long, we’re on the 3rd day of it and I’m only just writing the first post.