> 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@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@tuxbrain.com>:
> >>>>>> Yes very sad wrong titular "No More OpenMoko Phone " and very
> >>>>>> discorageus comentaries :(
> >>>>>>
> >>>>>> 2009/4/5 robert lazarski <robertlazarski@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
>
> _______________________________________________
> Openmoko community mailing list
>
community@lists.openmoko.org
>
http://lists.openmoko.org/mailman/listinfo/community
