Welcome

[Steve Mosher]

Gerald A wrote:
> Hi Werner,
> First, I'd like to thank you and  Steve for participating in this. Even
> being critical and to the point, we can know and get transparency then I
> think it's a huge step forward.

   You are welcome. I think of all the OM people perhaps werner, joerg 
and I, were the most passionately committed to getting the process 
right. On the issue of transparency since I'm marketing the pain of 
transparency always falls on my shoulders; that is, it makes my job
tough while it may make engineering more easy. That's not whining, 
that's just facts. Witness our recent decision to be transparent
about the GTA03. Finally I would like to make this distinction.

OPEN: we don't restrict your freedom. You are free to everything
       you are CAPABLE of doing.
TRANSPARENCY: we don't restrict the information we give you.

Now, you can be transparent but not open. Open but not transparent or
Open and transparent. And all shades of grey in between. In some cases
transparency isnt the best policy ( take HR) but I'm will to try more 
transparency than we have had in the past. For example, in showing how
difficult it is to source certain parts for example...as well as design 
issues.
> 
> On Sun, Apr 12, 2009 at 1:50 AM, Werner Almesberger <werner at openmoko.org>wrote:
> 
>> Steve Mosher wrote:
>>> or more generally what is the next Open
>>> source/open hardware phone that the community can build?.
>> I think "can" is the key word here. A lot of the discussion
>> I've seen so far reminds me of what we did with GTA01: blissfully
>> ignorant of what it means to mass-produce something, we treated it
>> as if all it took was to make an engineering prototype. Once that
>> one "worked", we'd be okay, right ?
>>
>> Unfortunately, a lot more is needed to make a real product. It
>> starts with finding parts that are actually available throughout
>> the whole product lifecycle [1], that are available at a tolerable
>> price in mass quantities [2], and that are supported by the vendor
>> [3].
> 
> 
> Now, I'm a software guy, so take this with a grain of salt. But why can't we
> have two "streams", like big projects? The current/testing stuff could be
> community designed. Things that get moved to "stable/release" would have the
> OM seal of approval.

At the beginning of a project you can have multiple streams. It's best 
to start with an idea of the target market or target customer. Let me do 
a little post mortum here on the Neo1973 and the FR. The penetration 
strategy was as follows: developer--->Mass market. The weapons of choice
Neo1973---->FR. Now that sounds pretty straight forward. When I joined
on that message and strategy was already communicated and already in 
place. But it flies in the face of all of my experience with launching
new technologies ( I consider open source on a mobile phone to be 
suffienctly new) The typical path for a new technology is this:
Gadget freak--->early adopter--->CHASM--->first beachhead--->mass market.
( if you want to read about this in detail go get crossing the Chasm,
   kinda my bible)
More simply the Neo1973 is more properly designated as a gadget and the 
volumes we got were gadget like volumes. It was pretty hard to do 
serious development on it as it lacked all the features that a mass 
market device would have on it. The FR was intended for the mass market, 
but it clearly only has traction in the early adopter market. in other 
words  its still for developers only. Now comes the CHASM. the chasm
is that void you hit AFTER early success with gadget freaks and 
Developers. with FR the chasm is clearly defined: The early
adopters are willing to live with some rough edges ( bugs) AND the
length in time the chasm will last is the time it takes to finish the
Software and hardware. I would say 18 months from launch. That is,
we should have targeted the FR squarely at developers and expected
and planned for 18 months of development before it was ready for the
FIRST BEACHHEAD. ( more on that later)
This blindness ( I'll take responsibility, since I'm the CHASM guru)
to the fact that we would face a chasm manefested itself in several
ways:

   1. Not understanding the complexity of smart phone stack.
   2. Over estimating the capabilities of the community
   3. Not  re-positioning the product before launch.
   4. Not getting rid of glamo.
   5. FOCUSING on UI rather than
       a) tools
       b) documentation
       c) The stack below FSO
    At CES of 08 when I first used the FR. I got hella pissed because of 
the software issues. And I lloked at two paths. Ship with a linux kernel 
only ( focus our effort at FSP and below) or Try to do a portion of the
complete stack ( back to basics). Had I gone back to CHASM theory it 
would have told me to focus on the early adopters... and let them do 
distributions. Instead we recamped on the software side.

The other thing is our target markets were no well defined.We really 
didnt think about the first beach head. Our target market should have
been: kernel guys, middleware guys, UI developers, And some app 
developers. Instead it wasnt this shraply focused. And the goals
should have been to get stuff done and upstream. And we didnt define the 
first beach head well. was it?

  1. Linux desktop developers
  2. Industrial
  3. B2B
  4. Linus users
  5. VARs
  6. System Integrators
  7. Embedded computing developers.

We just said the first beach head was "consumers" well which consumers?
men, women, old, young, FOSS lovers, WHO? WHERE?  Without that detail
our distribution plans are just ad hoc.

So where does that leave us. It leaves us in the chasm. And we will be 
in that chasm until the end of 2009. The FR shipped in July of 08. It 
shipped to early adopters, who suffer to make something out of it. 
Improving the HW and SW for what I would guess is 18 months. One year
into the project we have a version of the HW that is very solid ( except
for glamo stuff) and software is improving.. rhapsodically however.
The Key would be to pick a first beachhead for 2010. A a vehicle suited 
to that beachhead.







> 
> In this way, a couple smart hardware hackers can put together a phone with a
> built in itch-scratching device. Wow, neat. OM can look at it, and evaluate
> it's market/chip needs/etc, and decide whether it's a viable thing to take
> to market. It would be good if OM could also indicate why a design isn't
> chosen (can't get 5000 nail-like finger extensions) or what they would
> require to achieve critical success (need to have a potential to sell 10,000
> units).
  Agreed. typically these exercises are all done before project go ahead.
> 
> A lot of the problems Openmoko had to deal with weren't even
>> publicly visible. E.g., Sean must have spent months negotiating
>> with LCM vendors.
> 
> 
> This is painful, I agree. And unfortunately we're still too much of a niche
> to do anything about this. Maybe this can be talked about,
> without too much detail? "Trying to source a suitable XYZ controller". It
> should also talk about the challenges, because I've seen at least a dozen
> suggestions for alternate chips, all well meaning, and probably chips you
> did evaluate, but couldn't source in quantity and timeframes needed.
   There is no problem talking about these details up front and openly.
> 
> 
>> And once you have the parts, you need to find a factory that can
>> actually build the device. Some parts had yield rates as low as
>> 50%. Quite obviously, while this may be okay for an engineering
>> prototype, you'll have a hard time being profitable if you have to
>> bin half of your hardware.
> 
> 
>  That depends on part price point, and device price point. Now, I'm not a
> biz guy either, but if the parts are only $0.10, and you are circular
> binning half of them, $0.20 isn't a huge impact. Different story if the part
> cost is $50, of course. It's a factor that many don't see, though.
  Ah, the problem is this. You solder 150 dollars worth of parts onto 
the board. The 10 cent part causes a failure. Comes the question can you 
rework it? you are not just binning a 10 cent part you are potentially 
binning the whole phone. PVT production verifiction test is all about 
getting the yeild to very high #s.  like 95% plus. It has to do with who 
owns the yeild. I give the factory orders to build X. they say its 150
dollars. I buy 100, then build it.  50 work. Who owns the 50 dead 
phones? do I pay for just 50 phones? or 100? does the factory eat the 
loss or do I?
> 
> And that means that you have to find the bad apples in the first
>> place. In GTA01, we just proudly presented the factory with the
>> bringup and testing process process we had cooked up in
>> engineering and expected them to use this. In fact, they did as
>> they were told. So the factory workers plugged in debug board
>> cables and then manually ran the devirginator. If it failed, they
>> did it again. (In GTA02, things were a little smoother.)
> 
> 
> I think this is a great anecdote. It shows the line between producing
> something on a grand scale and making one. And it's a good bit of light that
> is shined down on things, and I think that clarity makes it easier to see
> how things go. It also shows you learned, and improved the process. I think
> it's a lesson we have to pay attention to.
> 
> 
>> There's a lot more. The bottom line is that it's hard to
>> mass-produce something and that the experience one gets from making some
>> prototypes or small "hobbyist" runs doesn't really prepare for industrial
>> production. It's very easy to overlook this difficulty but reality will
>> catch up when things enter the production stage. Naturally, that is a really
>> bad time for "surprises".
> 
> 
> This is where things bounce over from hobby to business, IMHO. If a hobbyist
> comes up with a phone that can also function as the key for your car, that
> might be interesting. If some car company then has $10K to twiddle with it,
> can it be turned into a "product"? Does that figure have to be an order of
> magnitude bigger? Are OM the right people to make such a product? I don't
> know the answer to any of these questions, but hopefully we can think about
> them, and maybe come up with some answers.
Those are tough. See the "beach head" concept.
> 
> [3] E.g., consider the ridiculous amounts of time we had and still
>>    have to sink into AR6k, Calypso, both with deficiencies in
>>    vendor support, and to a lesser extent GPS and the CPU itself.
>>
> 
> It's easy to be an armchair critic, but harder to be a real-world producer,
> no doubt. And here is where compromises in design come back to roost,
> unfortunately. While we'd all like everything to be open, open embedded
> components might not be available in quantities and timeframes you guys
> need, and that I understand. But, it also compounds your support issues,
> because now you guys aren't able to get community software support in
> critical areas where you would be leveraging the real power of the open
> source community. (Let's not even talk about field upgrades of firmware and
> the like).
> 
> I'd love to know more about the mystery acronyms and the process of building
> an engineering prototype into a phone. And there is much more negotiation
> and compromise built into the process then I think anyone initially
> realizes.

  Sure what mystery acronyms?
> 
> Thanks again,
> Gerald.
>