Slashdotted

[Steve Mosher]

thats the funny thing about inboxes and bills. If you ignore them
they dont go away, they just get bigger. There's a bunch of jokes here I 
refuse to make.

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