Slashdotted
Steve Mosher
steve at openmoko.com
Sun Apr 5 23:21:36 CEST 2009
Good comments All.
Let me inline some answers/explanations.
Lothar Behrens wrote:
> Hi,
>
> I am mostly reading and sometime writing here. If it was useful or
> useless - I don't know. But anyway.
>
> Let me arse around with some stupid ideas :-)
>
> What is a open phone?
>
> Is it only open source software or is it also open hardware?
>
> If software could be developed virtually at any place and from any
> person, why don't we do the same for
> hardware?
>
> Ok I cannot buy expensive equipment to test hardware that I may have
> developed, but I virtually could
> develop hardware. But many developers at one subject could spend money
> for a rent to let one of the
> team do outstanding tests.
At the begining of Sean's presentation you will see two slides:
1. a picture of Steve Ballmer ( the evil empire)
2. A picture of paul Otilinni ( intel)
And the point sean made about this was as follows; If a 15 year old
kid tells ballmer that he has developed a technology that will disrupt
microsofts business, Ballmer would do well to listen to him. Why?
because with a computer and a compiler it is possible to disrupt their
business or at least make there lives uncomfortable. Long ago back in
1994 before MS had any 3D api in windows there were three small UK
companies that had 3D apis for the desktop: argonaut; Rendermorphics;
and Criterion ( i worked there). These were really very small companies
and what we did was keep gamers in DOS, while MS wanted to move gaming
to windows. We disrupted their plans to move important apps into DOS.
So they paid attention to us. I remember sitting with Alex st John
and eric engstrom as they discussed what was originally called the
"manhatten project" later to be directX. And the phrase disruptive
technologies came up over and over again. One guy even had a folder on
his desktop labeled disruptive technologies. In the end, MS
aquired rendermorphics and it became Direct3D The point: in the
software world, a kid and an idea is potentially a powerful force. The
history of this is covered in this book:
Drummond, Michael (November 2000). Renegades of the Empire: How Three
Software Warriors Started a Revolution Behind the Walls of Fortress
Microsoft. California: Three Rivers Press. ISBN 978-0609807453. Covers
the early years of DirectX development within Microsoft, including the
acquisition of RenderMorphics.
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?
We've all sat there and said, just compile it, see if works. That's
easy in software. In Sean's presentation you'll see a slide.
"gcc GTA02v5 doesnt work" what that means is this. There are perhaps
some unconcious attitudes people have carried over from the software
world that will jump up and bite them when they start to work in the
hardware world. I'll use another metaphor. Building hardware requires
a "waterfall" design process, at least in my experience. In the software
world, outside of DOD and NASA, we'd be hard pressed to find projects
that followed a strict waterfall model.
In a waterfall model you start with requirements. And you don't write
a line of code until requirements are 100% done and complete and signed
off. Once the requirements are done. They don't change. Then, and only
then you get to do design. You are still not writing any code. when
design is 100% complete, you move to implementation. If you're not
familiar with this approach I can tell you it's a PITA. But it has its
advantages: a requirements defect found late in the game ( in
verification for example ) can cost 50-200X more to fix than if it was
fixed in the requirements phase. This holds especially true for embedded
software.
So what's the result if you don't use a waterfall model in
hardware development. Whats the cost if you find a requirements defect
or a design defect ( glamo? )when you do that prototype run? 50K
minimum, plus a redesign. Take the appendix out--perform a glamoectomy?
ask Werner about the design implications of that on WIFI. And
see my comments below about design and diving into peanut butter.
That means this: if you are designing hardware or doing hardware system
integration you would be well advised to follow a waterfall model. Any
other approach is prone to excessive delays and costly recamps. Just
read the list and see the number of people who are suggesting
implementations for a new GTA03 design. The rush to implementation-- use
this processor.. no use that processor, camera or no camera, resistive
or capacitive, keyboard or touch.-- ALL signs to me of a lack of
appreciation for the complexity and cost involved in doing hardware. I
got a hammer your problem must be a nail. I'll give you
another example. During the course of many discussion about GTA03 and
GTA04 both here and inside OM, both before and after the demise of GTA03
I see a pattern of discussion and problem solving that is, in my mind,
part of the problem. Those discussions go like this: "what if we take the
GTA03 and stick it in the 02 case?" which leads to "but where will the
camera go?" which leads to "do we really need a camera?" and so time
and energy is spent on this "solution" In the end, marketing looks at
that and says "who took the fucking camera out!" that's not an actual
example, but you get the idea.
The bottom line is this. To do a GTA03 right means starting with
requirements. 100% complete requirements. set in stone... or quick
setting cement. We had a couple of sayings in the jet fighter business.
Design is like diving into a swimming pool of peanut butter. You better
pick your landing zone right because there not much ability to swim
around after you hit. And also, this: "engineers almost never make
mistakes, the guys who set requirements do."
>
> Isn't it possible to also develop hardware collaboratively?
In one sense this is trivally true. hardware development is
inherently collaborative. But I suppose you mean is it possible
to do it in an open fashion. It maybe. But if the requirements process
and design process is not rigorous and well defined you end up
with expensive implementation problems. And if you don't have team
consensus, then it's very problematic. Forking software is easy.
Forking hardware is forking hard. The best example I can use is
forking ASIC design. You can do a big chip with lots of functionality
and then fork off 'defeatured' versions, but that forking needs to
be designed in.and it may come with a cost. the same holds true
for modular hardware designs. what's easy with lego blocks aint so
trivial when it comes to EE design.
>
> There are many hobby projects around in the net. These are really not
> at a level as OpenMoko or in
> general a device such as a mobile phone, but what is if we could get
> preproduced components such
> as the gsm 'plugin board'?
The OM designs all used "modules" for GSM and modules for things like
WIFI and BT as opposed to "down" designs or chips on PCBs. The diffculty
is not in finding components or modules and system level design is
fairly straight forward. The real difficulties come in areas like RF
design ( a black art of sorts) and in the marriage of mechanical and EE.
>
> I mean, if I am a crack in developing gsm stuff, but don't like to buy
> a complete phone for it, I probably buy
> the gsm module, say, with an interface connectable anyhow to a PC.
3G dongle
>
> What I also think about, is why are there only PDF schematics available?
Well, we are looking at making the gerbers available under a licencing
program. Stay tuned.
>
> I have only heared about the dash derivat of openmoko device. Is it
> because there is only a PDF available?
No, we designed DASH electronics using Our existing design. As Sean
points out in his presentation, this project proved to be a distraction
from our main goals in that time period. Why? here's a solution for
Dash, just take the existing design and make a few changes and recompile
the hardware!
>
> If it is possible to delegate hardware development tasks to the
> comunity why isn't it done yet?
I'm in the process of exploring this with a new list. However, you
need to understand the process:
1. requirements: the community can help here.
2. Design: the community can help here:
3. Implementation: Build EVT boards. This is where you need money and
infrastructure. So, if the community wanted to Build and buy EVT
boards ( I actually suggested this to Sean) then that could happen.
But an EVT board costs about 2 grand. I suppose if we had 20+ volunteers
who wanted to do this, it could be done. But remember EVT boards often
end up not working. Build 20, get 15.
I'm not saying that it's impossible, but everyone who gets involved
needs to know the mountain in front of them.
And we havent even discussed ID. ID could be developed by the community.
In fact, we had planned a design contest for alternative cases for the
GTA03. With volunteer efforts you could probably make it through a first
pass at ID and mech. here again samples are costly. early samples are
done on CNC machines, later rapid prototypes (25K) and hard tooling
is well over 100K.
>
> So when also open up the real circuit 'source code' - the real CAD
> files, would it give the real goal - the open mobile phone - a real
> push?
I'm looking into that. There is no fundamental objection to that. the
terms and conditions are what I need to examine. Also, many people
question the importance of gerbers. If you just want to copy the design
as is and send those files out to have a PCB built, then having the
gerbers saves you the time of reverse engineering from the schematics
or reverse engineering from the actual board ( seen that done) but
gerbers dont give you a theory of operations and design changes to a
design you dont understand can have knock on effects: see the glamoectomy.
>
> Then if there are some results that have a chance to become a real
> 'next' phone, a company like openmoko could
> think about producing some prototypes. So the company has a reduced
> cost.
without looking at actual numbers I would say 20% of the cost is
in requirements and design and 80% in implementation, verification,
production, test, and maintennce. Again, we are thinking down some
similar paths, so your comments are welcomed.
>
> There is one really good electronics project: The internal debug board.
Ya I love werners stuff. Now, for a while, the GTA03 was going to have
an internal debug board. The words flew kinda hot and heavy on that one.
less than 50% of all buyers get a debug board. Should we include
internal debug capability on every GTA03? I won't revisit that debate here.
>
> This is only one sample that there are hardware developers out there.
> Give them more food.
That's what were are going to try to do.
>
> My education in 1987 till 1990, was electronics engineering. I do not
> any more practice in that area. So I stuck in some conflict
> not to start any electronics projects, because I have the glue the
> project will be a one man show and keep a hobby project. But
> if there would be a collerative project I could join, I propably
> would. And may it only getting more practice in laying out PCB boards
> whose schematics other developers have created.
Ok.. here comes a question. What layout tools? are there open source
layout tools ( one hopes) and if not then what tool do we pick?
Essentially, you are pitching the idea I'm going to try to get going.
I'll make an announcement about it shortly, but my plate is pretty full
and I can only volunteer a couple hours a day to help organize and guide it.
>
> If that would be possible, then it would be a real open phone :-)
>
> End of arsing around. Is there a potential to create a hardware
> development comunity?
I think so. no harm in trying.
>
> To avoid that each individual will start its own variant we could
> using a vote system before any direction is done, say wich formfactor is
> used, for sample.
The voting approach will be discussed. Basically I dont believe in
letting idiots vote. You dont want me voting on your layout and
convincing everyone with my superb rhetoric that your 8 layer design
can be accomplished in 2 layers.. you get my drift. The community will
have to have SME ( subject matter experts) They will have to have some
undemocratic powers. my view at least.
>
> Sean: This would propably help continue GTA3 development. The risk to
> produce it, would only invest some inspections of a new design
> and doing integration tests. And even this could be donated.
I asked sean the same. We are going to set up a mailing list at
openmoko.org to get this started.
>
> Dont let a great idea die. Delegate hardware development activities if
> possible. We are a comunity.
>
> Lothar
>
> Am 05.04.2009 um 11:18 schrieb Johny Tenfinger:
>
>> It seems like "plan B" doesn't share anything with phones and...
>> Linux ;(
>>
>> 2009/4/5, David Reyes Samblas Martinez <david at tuxbrain.com>:
>>> only add that replies are quite unfair to a any free project whatever
>>> it succeed or not.
>>>
>>> 2009/4/5 David Reyes Samblas Martinez <david at tuxbrain.com>:
>>>> Yes very sad wrong titular "No More OpenMoko Phone " and very
>>>> discorageus comentaries :(
>>>>
>>>> 2009/4/5 robert lazarski <robertlazarski at gmail.com>:
>>>>> http://mobile.slashdot.org/article.pl?sid=09/04/04/228240&art_pos=2
>>>>>
>>>>> Not pretty. As someone who has been lurking on this list for 1 1/2
>>>>> years, patiently waiting to buy a phone but trying to avoid buzz
>>>>> fix
>>>>> parties if I could help it, I suppose its not surprising. On the
>>>>> positive side, I'll stick around to see what happens with plan b
>>>>> - if
>>>>> that is there's anyone left to develop it and its not vapor. I like
>>>>> the idea of Freerunner, just not its execution. I'd like to
>>>>> surprised
>>>>> though and see a turn around. And yes, I'll probably buy one that
>>>>> ships without hardware problems.
>>>>>
>>>>> - R
>>>>>
>>>>> _______________________________________________
>>>>> Openmoko community mailing list
>>>>> community at lists.openmoko.org
>>>>> http://lists.openmoko.org/mailman/listinfo/community
>>>>>
>>>>
>>>>
>>>> --
>>>> David Reyes Samblas Martinez
>>>> http://www.tuxbrain.com
>>>> Open ultraportable & embedded solutions
>>>> Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino
>>>> Hey, watch out!!! There's a linux in your pocket!!!
>>>>
>>>
>>>
>>> --
>>> David Reyes Samblas Martinez
>>> http://www.tuxbrain.com
>>> Open ultraportable & embedded solutions
>>> Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino
>>> Hey, watch out!!! There's a linux in your pocket!!!
>>>
>>> _______________________________________________
>>> Openmoko community mailing list
>>> community at lists.openmoko.org
>>> http://lists.openmoko.org/mailman/listinfo/community
>>>
>> _______________________________________________
>> Openmoko community mailing list
>> community at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
> Lothar Behrens
> Heinrich-Scheufelen-Platz 2
> 73252 Lenningen
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
More information about the community
mailing list
