Slashdotted

[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 <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
>