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 <da...@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 <da...@tuxbrain.com>: >>>> Yes very sad wrong titular "No More OpenMoko Phone " and very >>>> discorageus comentaries :( >>>> >>>> 2009/4/5 robert lazarski <robertlazar...@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