Slashdotted

[Gunnar AAstrand Grimnes]

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 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
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community