> Nice posts Steve! This is what a community oriented company works like!
> Frequent, on-time, interesting and well-written emails from the inside!
>
> Keep it up!
>
> - Gunnar
>
> Steve Mosher wrote:
>> 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@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@tuxbrain.com>:
>>>>>> Yes very sad wrong titular "No More OpenMoko Phone " and very
>>>>>> discorageus comentaries :(
>>>>>>
>>>>>> 2009/4/5 robert lazarski <robertlazarski@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@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@lists.openmoko.org
>>>>>
http://lists.openmoko.org/mailman/listinfo/community
>>>>>
>>>> _______________________________________________
>>>> Openmoko community mailing list
>>>>
community@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@lists.openmoko.org
>>>
http://lists.openmoko.org/mailman/listinfo/community
>> _______________________________________________
>> Openmoko community mailing list
>>
community@lists.openmoko.org
>>
http://lists.openmoko.org/mailman/listinfo/community
>
