[SVHMPC] linux phone standard

Tue Jun 19 13:57:47 CEST 2007

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, so far, LiPS is something good for all of us. Let's see what
happens whan first commercial adopters hit the scene.

Thanks!
Cheers
  nils

Matthew S. Hamrick schrieb:
> 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
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--