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 <[email protected]>: >>>> only add that replies are quite unfair to a any free project whatever >>>> it succeed or not. >>>> >>>> 2009/4/5 David Reyes Samblas Martinez <[email protected]>: >>>>> Yes very sad wrong titular "No More OpenMoko Phone " and very >>>>> discorageus comentaries :( >>>>> >>>>> 2009/4/5 robert lazarski <[email protected]>: >>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>> [email protected] >>>> http://lists.openmoko.org/mailman/listinfo/community >>>> >>> _______________________________________________ >>> Openmoko community mailing list >>> [email protected] >>> 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 >> [email protected] >> http://lists.openmoko.org/mailman/listinfo/community > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
