That's the point - I was away from home the last week only and kinda shocked found the om-community and debian-user-german folders with 320 mails each when I came back which is nothing compared to your 1800 mails... :)
-- Marcel Am Monday 06 April 2009 01:08:24 schrieb Steve Mosher: > thanks. During march I got so effin buried in other stuff that my > community posting went to hell. I sat there looking at my community > inbox grow and grow. And I thought "I rather open my cell phone bill > than plow through 1800 community mails" but in the end you pay your cell > phone bill and plow through those mails. As long as I keep the inbox > empty every day, its a joy to read and respond. > > Gunnar AAstrand Grimnes wrote: > > 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 _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
