steve at openmoko.com
Mon Apr 13 02:50:01 CEST 2009
Werner Almesberger wrote:
> Gerald A wrote:
>> The current/testing stuff could be
>> community designed. Things that get moved to "stable/release" would
>> have the OM seal of approval.
> Yes, I think that would be a good model. You can often distribute
> prototype development for subsystems, and the cost of entry would
> be relatively small in many cases. E.g., development of the
> acceleration meter subsystem could have been done completely
> outside Openmoko and not connected to any specific product. You
> risk not getting your prototype chosen for the real product, but
> the loss would be relatively small.
It might make sense Werner to map out the various stages of
development. I'll take a crack at it.. And then a rough schedule
rough task list, decision points, when we need $, how much etc.
1. Target market selection ( who is the customer)
2. MRD ( what are their needs)
3. Engineering Spec. ( designs a-n that meet the MRD)
4. Business plan review. (budgets and ROI)
5. Operations review. ( can we produce it)
6. Continue or return to step 1,2,3,4 depending on failure mode.
ha I just turned it into software. GTA03 was stuck in an endless loop
7. archetecture and implementation spec
8. theory of operations.
> Things get more difficult with those parts that you can't just buy
> online, e.g., CPU, telephony, LCM, battery, etc. A highly visible
> "community" project may actually have a strong enough reputation
> that some companies may be interested in cooperating even if they
> would normally not give you the time of the day unless you're a
> Fortune 500 company.
> Openmoko actually benefited from this effect: it was often given
> better treatment than a company of this size could normally hope
> to get.
>> In this way, a couple smart hardware hackers can put together a phone with a
>> built in itch-scratching device.
> Ah, but now you're talking about integration. That's where you
> can't distribute so well anymore. Even connecting the prototypes
> can be hard. I think you would basically have to get the people
> together in the same room for a week or two, along with all the
> equipment needed for such a task. That way, everyone can see the
> same problem when something goes wrong. No chasing of bug #1024
> around the planet ;-)
There are key points were you want everyone together.
> I've been in projects (EU-funded research) where we did this sort
> of integration, although in a less hardware-centric way. You need
> a site hosting a common testbed that everyone involved can travel
> to with relative ease, a rather generous travel budget, and more
> time than even the pessimists will tell you you need ;-)
generous travel budget my ass. take the bus from argentina! haha.
yup your right on all this.
>> Maybe this can be talked about, without too much detail?
> I wouldn't be afraid of going into detail. I think that's where
> Steve's and my approach differ a bit :) I often find that I only
> know the right questions after having studied some part in detail,
> and perhaps even having made a prototype.
Ya werner and I are light years apart when it comes to detail.
I'm very top down and willing to let some details be a bit fuzzy
when starting down the path. Werner is rather bottoms ups, or rather
he like to have all the details known before starting down a path.
Is that about right werner? This, coupled with my impatience, makes
for spirited discussions between us, but our mutual rspect for each
other keeps the discussion civil. Plus werner plays great tunes.
> In electronics, you often can't just adjust the few parameters
> you don't like in a part that's great otherwise. Instead, you can
> only pick a very different part where other parameters don't fit.
> The tricky bit is picking the one where the parameters you don't
> like don't cause major trouble.
>> 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.
> Ah, but eventually you'll put those 50% bad $0.10 parts into your
> $2000 prototype :-) So if one component is that badly out of whack,
> you have to do careful input testing, which means coming up with a
> repeatable test process, and so on. In the best case, you can manage
> the risk, but you'll probably miss the resources you have to put
> into it elsewhere.
In the prototype phase and EVT my philosophy is throw money at the
problem. if you have it to throw.
>> 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.
> I'd rather hope for a more conservative design - do one thing but do
> it right. Otherwise, those fancy features just end up taking up too
> much time. There's always the possibility to add a much larger
> feature set in follow-on products.
We are in violent agreement. I'll violate my own terms of service
and suggest these possible paths forward ( some near and dear to werner
and I) And werner if you can state in a few words were those projects
stand in development.. and a short engineering eval ( keep your nose out
of marketing for now or I swear I will pick up my compiler again)
The next Phone:
1. GTA02 cost down
2. GTA02 Glamoectomy - G
3. GTA02 -G+E Glamoecyomy, new Edge +E
4. GTA02 -G+E+P add 6410
then options of camera, 3g etc etc etc.
you get the idea, and of course the list contains a fresh design, new
ID, new everything. Long ass list. I'd say for a COMMUNITY project
we would stick with the 02 case. or make the minor mods that tully
is looking at ( I have an idea on the camera ) anyways, its pretty
safe to say that OM continues to look at 1-3 and the community
would best serve people if they look at 4..N
>> 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 think early access to GTA02 wasn't done properly. We should have
> involved external testers and perhaps even developers earlier. The
> lack of testing then led to surprises like #1024, uSD vs. GPS, buzz,
> In GTA01, we did in fact try to do this testing right and sent out
> quite a number of freebies. But since the software wasn't nearly
> ready for any use, only very few people could actually do something
> with the device, and as far as I recall, there was no feedback.
> Of course, in a way, GTA01 was the early access to GTA02. But the
> software situation didn't really improve until later.
> - Werner
More information about the Gta03