BUG Community

Welcome! Log In

kgilmer's Blog

OpenMoko, Open Hardware, and Open Discussion

First let me say that we at Bug are big fans of OpenMoko.  Not only have we benefited from the work that has gone into the product, they have also been a role model for us in terms of how an open consumer electronics company should behave, specifically to developers and the FOSS community as a whole.

The recent news that OM would be pausing development on their next generation phone, and the departure of several developers was unfortunate to hear.  However it's not entirely unexpected, with the economy as it is. 

What I found very illuminating was a discussion on an OpenMoko mailing list regarding the possibility for the community to resume work on the next generation phone without the help of OpenMoko (the hardware company).  In this thread, after some initial "why can't we do it ourselves?" questions, Steve Mosher of OpenMoko.com very accurately and clearly states the complexities that face anyone (specifically in this case a FOSS community) when creating hardware products, and how fundamentally they differ from software.  Admittedly, we at Bug have faced many of these same challenges.  It's great to see this open and honest discussion about the problems and challenges that face OpenMoko and Open Hardware in general, and I highly recommend reading Steve's post.

I hope that OpenMoko's as yet undisclosed interim product is a success, and that success allows them to get back to building great open phones!

created on: 04/08/09

Post Comments

Add Your Comment!

Interesting,

I had never heard about OpenMoko - it seems like a great phone.


Thanks for bringing this up

Though Steve goes on to talk about how the waterfall model is the only possible development
model for hardware because of the cost of a new version. That may seem like the solution
if you look at it like software, where we iterate over new versions of the final product. But we learn
in school that the design process of large mechatronic systems is HIGHLY iterative, and mechanical
systems eclipse circuit boards in investment costs by an order of magnitude - you only get to build a
power plant once and it costs tens to hundreds of millions of dollars. The answer is to have a better
simulator and iterate over many designs in that. By the time Boeing starts cutting the first piece of
aluminum they have been through thousands of designs virtually.

Which brings me back to a question I have been mulling over lately - how can we have an open hardware
movement without open tools? Where are the professional level Computer Aided Engineering tools?
"The bottom line on software is this: the business of software is easy
to disrupt because the barriers to entry ( the cost of tools) is
comparatively low.

Now, lets look at hardware. If that same 15 year kid came to Paul
Otillini and said he had technology that would disrupt Intels business
what would paul do. He'd ask the kid who his investors were? ask what
EDA tools did he use? Synopsis? did he have a cycle accurate C-SIM of
the chip? Who was his fab? was he planning an ASIC flow or COT flow
for the chip, what tools did they use for floor planning, routing etc.
The cost of these tools and the cost of proving something in silicon
are in the millions of dollars. Hardware is hard. The barriers to entry
are huge, not only IP barriers but sheer cost.


So, Sean's basic point in those first two slides is that
entering/disrupting the software business is orders of magnitude
easier than entering the hardware business.

This of course is an extreme comparison, used however to make a
point. We should be on guard against notions and attitudes that
characterize the hardware business as easy. At OM we entered the
hardware business at the system level. Not designing chips of course,
but one level up from that: designing
hardware systems. Here too, however, you see costs and risks that
form barriers to entry. For example, the test lab we maintain for
testing phones has 5Million dollars of equipment. A prototype
run of an evaluation board can cost 50K USD. 20 phones: 50K.

I use this analogy. You write your code in a series of units.
you unit test them. Then you do your first integration.
You set up your make files and I charge you 50K to hit return. would you
hit the compile button?"

-Steve Mosher

» All comments
» Comments RSS

Powered by Community Engine

Top
Login
Close
Bottom