Re: [SVHMPC] linux phone standard
Hi all! As one being loosely involved in the LiPS thing I probably should comment on it a little (but please do not take this official ;) First to what I/we have been doing with LiPS... It is now almost two years ago that we, i.e. members of the GPE project http://gpe.linuxtogo.org have been approached by Orange/FT (founding member of LiPS) if we would like to help them with a LiPS testbed implmentation, probably based on parts of GPE. Of course this was a nice offer so we accepted and have since then visited Beijing quite some times ;) What we learned there are several interesting lessons: 1. Yes, an engineer could make any device work nicely given enough resources, which include money and time. The latter two are getting more and more short within any company. 2. As an "outsider" of the mobile phone industry it is very hard to learn and understand about the requirements of especially network operators. In order to get accepted by more than just an interested group of geeks you have to create a device that behaves like operators expect it to behave - as one example I would mention DM here - for the ones who know, this is a huge pile of functionality that is tremendously hard to implement if you do not have internal knowledge from an operator (DM = Device Management, which means remote device management including reconfiguration etc. through operator network). Another yet to mention example is IMS :( 3. Since development cycles get shorter and shorter in the industry and systems get more and more complex you cannot always reimplement and reengineer everything. You have to reuse as much as possible. Look at the (again) growing success of Symbian Series40 and Series60. This is, apart from high licensing costs, a very appealing system for manufacturers since 80-90% of the software work is already done and tested. By specifying low- and toplevel APIs and a basic understanding of the architecture you can save I would guess around 30-40% development effort. If you then even have parts of the implementation available developed in an open source fashion you can save even more by reusing that code. And since those snippets share the "same" APIs even code from different sources, be it free or commercial, can be reused. 4. LiPS is also about avoiding fragmentation. In the recent years we have seen multiple approaches to bascially solve the same problems, be it on system level (like power management and general device hardware handling) or GUI stuff. It is a pity to see so much effort wasted for ever newly started projects that will finally end in the bin. Nokia has done an excellent job at creating a good and clean architecture built upon standard open source building blocks. This also lead to the formation of GMAE (http://www.gnome.org/mobile/) which also strongly inspires LiPS. So with LiPS we pick up those stadards, take into account the requirements of mobile phones and create a specification. It will not completely avoid fragmentation but it will hopefully help to offer a choice for new developers: Go with a broad mainstream or be a genious and do your own ;) 5. No code... well, LiPS is about the specification not about implementation. There will probably at some point be a reference implementation but ATM there is simply none. It is not that LiPS does want to share a hidden sourcecode, there is simply none - apart from maybe some internal test-code which is not worth mentioning. The thing with industry standardisation bodys is also that *if* they put something out and label it "reference implementation" then it has to be 100% certified. At the very moment there is no defined process for such validation yet. Focus was on getting the specs out of the door as soon as possible - which happened now. If you want to have a peek at LiPS and code I would suggest to have a look at GPE Phone Edition, which is the project inspired from GPE and the result of our work with Orange/FT: http://gpephone.linuxtogo.org The implementation cannot be called LiPS compliant because this term is not defined (yet) but we *aim* at being LiPS compliant. 6. LiPS is open source friendly. I think LiPS is the first industry consortium that explicitely edorses and even enforces open source community collaboration! First of all all LiPS specification, as already done, are freely available and will ever be. Anyone interested can use those freely too (though using the name of LiPS might be tight to some strings...). LiPS will also continue and extend to work directly with the open source community in order to forward commercial requirements from operators, developers and manufacturers into the community but also to feedback community input into the industry. So it is a two way channel (look for something like this at e.g. LiMo). Uhh...geee, long text already - I guess I stop here ;) If someone has more specific questions concerning LiPS, please feel free to reply here (on mailinglist) or reply to me perosnally by mail. I think
Re: [SVHMPC] linux phone standard
Really well put, Matt. I agree with your analysis, and like you, for the past 24 hours have been trying to figure out why this doesn't seem like such a big deal. You have nicely expressed my feelings. Michael On Tue, 12 Jun 2007, Matthew S. Hamrick wrote: Well... I used to work for PalmSource, one of the LiPS founding members. I've been trying to find something nice to say about LiPS for the last 24 hours and the best I can come up with is, "It's not Microsoft." But yeah... my impression has always been that some of the companies involved (PalmSource) always believed that the value of their offering was based in the software. I would argue that the value of PalmOS is not in PalmOS itself, but in the community of users and developers that surrounded it. Motorola is used to dealing with proprietary mobile OSes and is only slowly coming to internalize some of the benefits of open source. So... my take on this is... the guys involved have a mental model of how successful products are built, and it involves dealing with "the" software group. These businesses have processes based on a risk model that puts the software group in a distant location from the hardware group. In my experience, companies that pay dogmatic attention to API standards outside of customer requirements don't last long (Posix and Win32 being possible exceptions.) Companies that pay close attention to customer requirements spend more of their time solving their customer's problems than going to meetings to discuss which options of which API calls will be supported. LiPS was formed by a group of software companies who, when given a kernel, a process model, a framebuffer device driver or two, and GTK, couldn't figure out how to make a compelling product, much less a platform. The LiPS guys will tell you that in order to create a development community, you've got to have a consistent API for developers to work with. I've always argued that given a compiler, an emulator, prototype hardware, a JTAG connector and enough stock options and coffee, skilled engineers can make anything work. What is difficult is for small, innovative companies to release their products in a market dominated by a few powerful players with long buying cycles. This is not to say that LiPS is irrelevant, just that as an ISV, I just don't see why it's that interesting. -Just my $0.02 -Cheers! -Matt H. On Jun 12, 2007, at 8:22 AM, Paul A. Lambert wrote: On Jun 12, 2007, at 6:53 AM, mtd wrote: > hello, > > it seems that LiPS group tries to make linux phone specifications. > > http://arstechnica.com/news.ars/post/20070611-linux-phone-standards- > group-to-publish-specifications.html Yes .. the "specifications" are now available: http:// www.lipsforum.org/index.php?option=content&task=view&id=54 These are largely overviews, some doxygen output, and some header files. No code. You need to be a member to get the code :-( API standards are difficult to enforce, but could be useful to help align some of the most basic services for a phone (like the phone book). These specifications will be used for industry developed 'closed' phones. The 'open' community will need to produce similar parallel work not as APIs, but as code :-) The LiPS documents could server as an interesting starting point for some designs. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SVHMPC] linux phone standard
Well... I used to work for PalmSource, one of the LiPS founding members. I've been trying to find something nice to say about LiPS for the last 24 hours and the best I can come up with is, "It's not Microsoft." But yeah... my impression has always been that some of the companies involved (PalmSource) always believed that the value of their offering was based in the software. I would argue that the value of PalmOS is not in PalmOS itself, but in the community of users and developers that surrounded it. Motorola is used to dealing with proprietary mobile OSes and is only slowly coming to internalize some of the benefits of open source. So... my take on this is... the guys involved have a mental model of how successful products are built, and it involves dealing with "the" software group. These businesses have processes based on a risk model that puts the software group in a distant location from the hardware group. In my experience, companies that pay dogmatic attention to API standards outside of customer requirements don't last long (Posix and Win32 being possible exceptions.) Companies that pay close attention to customer requirements spend more of their time solving their customer's problems than going to meetings to discuss which options of which API calls will be supported. LiPS was formed by a group of software companies who, when given a kernel, a process model, a framebuffer device driver or two, and GTK, couldn't figure out how to make a compelling product, much less a platform. The LiPS guys will tell you that in order to create a development community, you've got to have a consistent API for developers to work with. I've always argued that given a compiler, an emulator, prototype hardware, a JTAG connector and enough stock options and coffee, skilled engineers can make anything work. What is difficult is for small, innovative companies to release their products in a market dominated by a few powerful players with long buying cycles. This is not to say that LiPS is irrelevant, just that as an ISV, I just don't see why it's that interesting. -Just my $0.02 -Cheers! -Matt H. On Jun 12, 2007, at 8:22 AM, Paul A. Lambert wrote: On Jun 12, 2007, at 6:53 AM, mtd wrote: hello, it seems that LiPS group tries to make linux phone specifications. http://arstechnica.com/news.ars/post/20070611-linux-phone-standards- group-to-publish-specifications.html Yes .. the "specifications" are now available: http:// www.lipsforum.org/index.php?option=content&task=view&id=54 These are largely overviews, some doxygen output, and some header files. No code. You need to be a member to get the code :-( API standards are difficult to enforce, but could be useful to help align some of the most basic services for a phone (like the phone book). These specifications will be used for industry developed 'closed' phones. The 'open' community will need to produce similar parallel work not as APIs, but as code :-) The LiPS documents could server as an interesting starting point for some designs. Paul -- Martin Tomasek ___ SVHMPC mailing list [EMAIL PROTECTED] http://telefono.revejo.org/mailman/listinfo/ svhmpc_telefono.revejo.org Paul A. Lambert CTO, PicoMobile Networks, Inc. 256 Gibraltar Drive, Suite 108 Sunnyvale, CA, 94089 cell: +1-650-787-9141 ___ SVHMPC mailing list [EMAIL PROTECTED] http://telefono.revejo.org/mailman/listinfo/svhmpc_telefono.revejo.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
