-
LiMo Platform and Mobile Linux
FOSDEM 2010
-
Hi, I’m Andrew.
asavory@apache.org
twitter.com/savs
-
Who, or what, is LiMo?
-
How many people have heard
of LiMo? How many people know what LiMo is?
-
LiMo is a Foundation
-
Foundations are good Neutral third
party Central location for code, resources Protection for legal issues Apache Software Foundation, Eclipse Foundation, Free Software Foundation, GNOME Foundation, Linux Foundation, Mozilla Foundation, Symbian Foundation, ...
-
LiMo is a platform (the
first truly open*, hardware-independent, Linux-based operating system for mobile devices) * open as in governance
-
Platforms are good The operating
system stack is a commodity layer* Reduce development and maintenance costs Decrease time to market / increase innovation Maemo on Debian, o2 Joggler on Moblin, Moblin on Fedora/SUSE/Ubuntu/Mandriva/... * i.e. becoming more alike / less differentiated, standardised; able to run on multiple hardware; the point of differentiation moving up the stack
-
LiMo is a diverse cross-
section of the mobile ecosystem
-
Diversity is good A key
metric of a healthy (open source) community Represent everyone’s views, not just “the driver” Must be coupled with clear and open governance LiMo members include chipset companies, handset manufacturers, network operators, software companies
-
Shipping matters
-
45 handsets and counting
-
The LiMo Platform
-
User interface Increasing commoditisation LiMo
“middleware” Linux kernel Some Implications of Software Commoditisation http://osdir.com/Article204.phtml
-
Challenges
-
FLOSS
FTW!
Open
or
Closed?
-
De bi a n GNU/L
i n u x f o r Mo bi le s v3. 5
-
Help us! Definitive project website
Readily identify the license(s) the code is under Easily downloadable source code As HTTP resource, including many years of archives! Bonus, nice to have: Roadmap, release history, links to issue tracker and SCM repository, up-to-date listing on ohloh.net
-
Crazy things we do* *
... but wish we didn’t have to Data-mine repositories and catalogues for useful stats e.g. GTK = $30m for us to build from scratch Automated pulls from upstream projects Read through every source file to check licensing
-
!"#$%&'%(#)*+,%-.,/%0&123,%!"3,/#,# ! !"#$"%&'(#)*"#+' ! ,-.'*/01'234456&&777085"$+89#:"08#;&%):"$+"+&;5%</010535='
! >$?'5"#@)++)*"'A+BC%"'D5"$'E89#:"'%):"$+"&:85?#);34'7B)*"#&59C%):'F8@B)$'$84):"'B+'B55#8*"F'C?'43"'.EG' ! H88%+' ! .,-.*/''234456&&7770;$908#;&%):"$+"+&8%F<%):"$+"+&%)C#B#?034@%='B$F'/0I''234456&&777085"$+89#:"08#;&%):"$+"+&%;5%< Compliance is hard work... /0I0535=' ! ,-.*/'27)43'8#'7)43894'+5":)J):'"K:"54)8$=L',-.*M'27)43',GG'N9$4)@"'"K:"54)8$=' 234456&&7770J+J08#;&%):"$+)$;&%):"$+"+&;::<"K:"54)8$034@%=' ! O:%)5+"'-9C%):'.):"$+"'*I01'234456&&777085"$+89#:"08#;&%):"$+"+&":%)5+"<I010535 = ! >$?'5"#@)++)*"'A+BC%"'D5"$'E89#:"'%):"$+"&:85?#);34'7B)*"#&59C%):'F8@B)$'$84):"'B+'B55#8*"F'C?'43"'.EG' ! P)FF%"7B#"' ! .,-.'*"#+)8$'/01'B$F'*"#+)8$'/0I')J'43"'G8$4#)C948#':8$J)#@+')$'43"'P8F9%"'>55%):B4)8$'Q8#@')4+':8@5%)B$:"'7)43'43"' R$4";#B4)$;&.)$S)$;'#9%"+'B+'F"+:#)C"F')$'+":4)8$'RT'8J'43"'D5"$ E89#:"'58%):?' ! ,-.'*/01')J'43"'G8$4#)C948#':8$J)#@+')$'43"'P8F9%"'>55%):B4)8$'Q8#@')4+':8@5%)B$:"'7)43'43"'R$4";#B4)$;&.)$S)$;'#9%"+' B+'F"+:#)C"F')$'+":4)8$'RT'8J'43"'D5"$'E89#:"'58%):?' ! >5B:3"'/01'234456&&777085"$+89#:"08#;&%):"$+"+&B5B:3"/010535=' ! H3"'>:BF"@):'Q#""'.):"$+"'*"#+)8$'/0I'234456&&777085"$+89#:"<F"J)$)4)8$08#;&%):"$+"+&BJ%</0I034@%=' ! P8U)%%B'-9C%):'.):"$+"'I0I'234456&&777085"$+89#:"08#;&%):"$+"+&@8U)%%BI0I0535=' ! O:%)5+"'-9C%):'.):"$+"'*I01'234456&&777085"$+89#:"08#;&%):"$+"+&":%)5+"<I010535 = ! >$?'5"#@)++)*"'A+BC%"'D5"$'E89#:"'%):"$+"&:85?#);34'7B)*"#&59C%):'F8@B)$'$84):"'B+'B55#8*"F'C?'43"'.EG' ! Q89$FB4)8$'>-R' ! >$?'5"#@)++)*"'A+BC%"'D5"$'E89#:"'%):"$+"&:85?#);34'7B)*"#&59C%):'F8@B)$'$84):"'B+'B55#8*"F'C?'43"'.EG' !"#$%&'()*+ ,--.*/&0" 1"2345)&"3 !67189:7;8</*= 16>*/806*16?79<;867*87;:>7</* @?>@6A:A*67/B* ... please don’t make it harder!
-
The “F” word
-
“[...] this whole thing stinks
of people not liking Forking. Forking is important and not a bad thing at all. From my perspective, forking is why the Linux kernel is as good as it is.” - Chris DiBona “[...] the ability to fork is important, it keeps everyone honest, but actual doing a fork is a sign of failure on someone's part” - Greg Kroah-Hartman
-
Where an open mobile platform
is already using key open source projects of Mobile critical importance, there is direct economic value in Open Source constructive engagement with Economic Analysis the corresponding open source communities. LiMo Foundation White Paper August 2009 ™ ™ White Paper 1
-
The four merge strategies •
Here we define merge as bringing upstream open source changes back into internal code lines, and contribute as the process of offering internal feature enhancements and bug fixes back to the relevant open source community • Merge Never: Develop in isolation and never resync with upstream development • $40 million/283 FTEs per year • Merge Late Contribute Late: Acknowledge technical debt and resync at end • $20 million/141 FTEs per year • Merge Early Contribute Later: Continuous resync with upstream, commit later • $10 million/70 FTEs per year • Merge Early Contribute Early: Continuous resync with upstream and commit • $3.3 million/24 FTEs per year • In increasing order of potential for long-term cost reduction BUT with a catch: • Also increasing sophistication in organisation of integration infrastructure • Or “investment in absorptive capacity”
-
Software Supply Chain Management Cost
of upstream resync Closer integration with upstream innovation Community open source development codeline Greater sophistication required to manage MN integration activity MLCL With ME, the Resync vendor’s internal MECL (merge) dev branch is OSS with MECE Contribute upstream upstream later Time Product development cycle approx 2 years Software selection decision Product shipment made at this point made at this point
-
How to engage?
-
... build the business case
for structured / bilateral engagement with Open Source projects ... ... use a simple Memorandum of Understanding, our Industry Liaison Partner Agreement, and a Letter of Intent ...
-
“We don’t have an official
agreement that needs to be signed.” (But we can put one together if you need one.)
-
The Source Code
-
diff noun informal short for
difference . verb [ trans. ] Computing compare (files) in order to determine how or whether they differ.
-
$ du -sh upstream_diff_dir 86M
upstream_diff_dir
-
alsa-lib-1.0.16.diff gstreamer-0.10.22.diff libXdmcp-1.0.2.diff atk-1.24.0.diff gtk+-2.14.4.diff
libXext-1.0.99.1.diff bigreqsproto-1.0.2.diff inputproto-1.9.99.6.diff libXfixes-4.0.3.diff bluez-libs-3.36.diff ipkg-0.99.163.diff libXfont-1.3.3.diff bluez-utils-3.36.diff kbproto-1.0.3.diff libXft-2.1.13.diff cairo-1.8.0.diff libexif-0.6.16.diff libXi-1.2.99.1.diff compositeproto-0.4.diff libfontenc-1.0.4.diff libXinerama-1.0.3.diff damageproto-1.1.0.diff libICE-1.0.4.diff libxkbfile-1.0.5.diff dbus-1.2.3.diff libogg-1.1.3.diff libxml2-2.6.26.diff dbus-glib-0.74.diff liboil-0.3.14.diff libXmu-1.0.4.diff fixesproto-4.0.diff libselinux-2.0.71.diff libXpm-3.5.7.diff fontcacheproto-0.1.2.diff libsepol-2.0.37.diff libXrandr-1.2.3.diff fontconfig-2.6.0.diff libSM-1.1.0.diff libXrender-0.9.4.diff fontsproto-2.0.2.diff libtheora-1.0.diff libXres-1.0.3.diff freetype-2.3.7.diff libvorbis-1.2.0.diff libXt-1.0.5.diff GConf-dbus-2.16.0.diff libX11-1.1.99.2.diff libXtst-1.0.3.diff glib-2.18.2.diff libXau-1.0.4.diff libXv-1.0.4.diff gst-plugins-bad-0.10.0.diff libXcomposite-0.4.0.diff metacity-2.25.89.diff gst-plugins-base-0.10.22.diff libXcursor-1.1.9.diff ncurses-5.6.diff gst-plugins-good-0.10.13.diff libXdamage-1.1.1.diff tiff-3.8.2.diff
-
Working together
-
PLEASE HELP!
-
Thank you.
15:00-16:00 on Saturday, in room Lameere
LiMo are building an open mobile middleware platform upon the Linux kernel, drawing from the best of open source and using many common components found in GNOME Mobile.
The big challenge for mobile companies working with open source is how to be graceful in our interaction with upstream projects and how to ensure a reciprocal flow of innovation that benefits everyone.
This session will introduce the LiMo platform, talk about the challenges of building for mobile devices, and how we want to work with open source projects to make them more mobile in the future.
Introductions.
Two things you need to know: how to get in touch with me (flames, patches, feedback) and how to find out more.
My job: open source manager for LiMo Foundation.
I&#x2019;m not here to do a marketing presentation. I do genuinely think it&#x2019;s important that you know about LiMo.
Here&#x2019;s four things you need to know about LiMo.
Before I tell you about LiMo - I&#x2019;d like to conduct a straw poll.
Let&#x2019;s see who knows about us.
Don&#x2019;t feel bad - before I was approached for the job in 2008, I&#x2019;d not paid much attention to LiMo.
The LiMo Foundation is a US non-profit foundation.
Foundation is a relatively common legal structure for collaborative organisations.
Why do so many people choose a Foundation structure?
Offers benefits for everyone: developers, companies, communities.
Neutral: important so companies can feel safe contributing (not directly aiding a competitor)
Central: helps developers get engaged, pool resources (provide framework for hosting etc)
Protection: for (IPR etc) and from (legal action)
Many well-known foundations
side effect: 12 staff, no traditional engineers
We&#x2019;ll come back to talking about the platform. But for now: it&#x2019;s a big chunk of code to make mobile devices work.
Yes, we&#x2019;re open. We don&#x2019;t publish our source code, it&#x2019;s not all open source, but anyone can become a member ($20k associate, I take cash)
Why does everyone want to create a platform?
Shared costs, increasingly raising the bar of commodity layer.
Ultimately allows us to focus on points of differentiation such as user experience.
This may look like marketing, but it&#x2019;s actually important from a developer point of view as well.
Look at other mobile platforms out there. In each one, you can name a dominant player or someone with influence.
Maemo: Nokia.
Moblin: Intel.
Symbian: Nokia.
Can you name the key influencers in LiMo?
Finally, LiMo is behind many handsets, and has history of Linux handsets through our members dating back to 2002. No point having a platform if no-one uses it.
Majority of devices are in Eastern markets (Japan, NEC & Panasonic shipping on NTT DoCoMo)
But Motorola&#x2019;s Razr v8 and derivatives are LiMo R1 devices
Samsung Vodafone 360 H1 and M1 are LiMo R2 devices
Now you know all the important facts about the Foundation itself.
Any questions so far?
Let&#x2019;s talk a bit about the platform itself, our code.
This is the GNOME Mobile stack
This is the LiMo stack. Includes all the &#x201C;stuff&#x201D; you&#x2019;d expect to need on a mobile device. location, ui, multimedia, camera, web runtime, telephony stack, database, bluetooth.
Compare LiMo and GNOME Mobile.
These are the GNOME Mobile components of the LiMo stack.
It&#x2019;s difficult to build a mobile stack and NOT use open source components, and NOT have it look like GNOME mobile.
(This is great news for GNOME)
Where is the SOURCE CODE?
LiMo is in the middle
STOCK VANILLA LINUX &#x201C;commodity&#x201D; KERNEL
&#x201C;commodity open source&#x201D; unified within the middleware
What were the difficulties in building this stack?
There is still discussion about whether to use open source software or not
Case studies, being more approachable, professional services companies all help
Identifiable events (FOSDEM, GUADEC) and point of contact / spokespeople
If we want to use FLOSS, how can we get hold of it?
It&#x2019;s hard being a downstream aggregator.
We have several hundred packages that make up our platform
A large number of those are open source
Keeping track of what we use is hard
There are things individual projects can do to make our lives easier
List of our packages later
But good general practice for all projects
Why do we need you to do those things?
The big challenge for us is knowing what we&#x2019;ve got (the bill of materials) and how we use it.
This makes us do crazy things.
License proliferation is a SERIOUS problem for downstream users.
How we approach it
FSFE Legal Network linking doc
Member&#x2019;s responsibility for upstream
FPL
Every time you create a new license, god kills a kitten.
Keep your house in order
ASF everything &#x201C;safe&#x201D;
Forking.
Because of the nature of product development, it&#x2019;s common (if not natural) to fork an open source package.
Is forking good or bad?
Distributed version control e.g. GIT suggests lowering barrier to commit is important
Nothing that we can do to change this reality.
What we need to do is make clear the commercial reality of forking
and what we can do to mitigate the consequences.
Commercial reality is that people don&#x2019;t care about forking unless they understand how it hurts them.
This white paper gives hard numbers for the cost of forking.
Find Mal and speak to him.
Unleveraged potential cost of $6m for GTK within 2 years
Unleveraged potential cost of $44m for WebKit within 2 years
MERGING UPSTREAM IS IMPORTANT
In the paper we look at four different ways of merging
Why is forking important?
Why is open source economics important?
Eventually the open source community will WANT modifications to make their way back upstream
When this happens has massive implications on the cost (and therefore likelihood)
You would think mobile phone ecosystem would be good at software supply chain
They are NOT
Low priority
Produce a product, go to market, move on to next codebase
Merge early / commit early is hard (we should focus on making it easier)
Merge late / commit late is most likely (quietly deprecate and help to move to MECE)
This all leads to how organisations like LiMo Foundation engage with open source projects
So we have a platform
There&#x2019;s lots of open source in it
Lots of open source projects
How does a commercially-driven organisation like LiMo work with open source projects?
The &#x201C;corporate&#x201D; way of working goes like this.
You email a suggestion to work with an open source organisation.
A year later you have a management meeting.
You agree a course of action.
You get this course of action signed off by an executive committee.
You draft the appropriate framework legal documents, and send them off to the relevant open source project, and ask them to send back their legal documentation for review.
The open source community responds.
This can cause some confusion.
At this point, questions get asked, strategies get reviewed, and confusion sets in.
It will happen, but it takes time.
Meanwhile, we can take concrete action around something everyone understands: the code.
We&#x2019;re not open
But we want to be more open about the open source code we use
Simplest and politest way we can engage
Talk at technical level
In December 2009 we published a list of all the open source components in the platform.
The list gives you an insight, but doesn&#x2019;t tell you how we&#x2019;ve used the code.
The interesting bit is the list of changes we&#x2019;ve made - the diffs.
We&#x2019;ve got quite a lot of patches to work through
Where do we start?
Many manufacturers have years of experience in building code and devices
But little experience in working with open source
A few have made the jump - Nokia, with Maemo
A lot of us still need help
Help us to help our members
Ask us questions
Give us suggestions
Tell us when we get it wrong ... or right