Welcome

[Gerald A]

Hi again,

On Sun, Apr 12, 2009 at 7:18 PM, Steve Mosher <steve at openmoko.com> wrote:

>
>
> 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.


I think it depends on the target market as to whether transparency makes
your job harder or not. To a bunch of Linux hackers, I don't think so. For
mass market phones, you are probably right, at least for now.


> 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.


The sourcing issue does a lot to put out the fires of "why did you *bleeps*
pick this crappy XYZ chip instead of the far superior, only 10 calories,
tastes great and has sex appeal ABC chip?" If you guys can
only get 6 ABC chips a month, I'm sure the cost of each phone will be on the
order of $10,000 bucks.


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 ew 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)


Everyone makes mistakes -- that's why we are human. :)
Good to admit them, learn from them, and move on.

> 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 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.

Ok, two things come to mind here: First, do you now know who the beach head
is, which specific consumers you are aiming at? And Second, if you have a
specific group picked, is there still flexibility to have community hardware
people scratch an itch? Or is that infeasible?

> The Key would be to pick a first beachhead for 2010. A a vehicle
> suited to that beachhead.
Plan B? :)

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.



> There is no problem talking about these details up front and openly.


Good to hear.

 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?


Ok, I didn't read the defective parts as getting installed, but rather being
annoying and crudding up the pre-build processes. I'm learning too.

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.


Well, this is brainstorming, and I'm not sure how practical what I'm saying
is. It would be neat, if it worked, of course.

Gerald.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/gta03/attachments/20090414/54907e78/attachment-0001.htm