LiMo Platform And Mobile Linux

2,221 views

Published on

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 presentation introduced the LiMo platform, talked 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.

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,221
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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’m not here to do a marketing presentation. I do genuinely think it’s important that you know about LiMo.
    Here’s four things you need to know about LiMo.
  • Before I tell you about LiMo - I’d like to conduct a straw poll.
    Let’s see who knows about us.
    Don’t feel bad - before I was approached for the job in 2008, I’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’ll come back to talking about the platform. But for now: it’s a big chunk of code to make mobile devices work.
    Yes, we’re open. We don’t publish our source code, it’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’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’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’s talk a bit about the platform itself, our code.
  • This is the GNOME Mobile stack
  • This is the LiMo stack. Includes all the “stuff” you’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’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 “commodity” KERNEL
    “commodity open source” 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’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’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’s responsibility for upstream
    FPL
  • Every time you create a new license, god kills a kitten.

    Keep your house in order

    ASF everything “safe”
  • Forking.
    Because of the nature of product development, it’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’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’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 “corporate” 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’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’t tell you how we’ve used the code.
    The interesting bit is the list of changes we’ve made - the diffs.
  • We’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
  • LiMo Platform And Mobile Linux

    1. LiMo Platform and Mobile Linux FOSDEM 2010
    2. Hi, I’m Andrew. asavory@apache.org twitter.com/savs
    3. Who, or what, is LiMo?
    4. How many people have heard of LiMo? How many people know what LiMo is?
    5. LiMo is a Foundation
    6. 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, ...
    7. LiMo is a platform (the first truly open*, hardware-independent, Linux-based operating system for mobile devices) * open as in governance
    8. 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
    9. LiMo is a diverse cross- section of the mobile ecosystem
    10. 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
    11. Shipping matters
    12. 45 handsets and counting
    13. The LiMo Platform
    14. User interface Increasing commoditisation LiMo “middleware” Linux kernel Some Implications of Software Commoditisation http://osdir.com/Article204.phtml
    15. Challenges
    16. FLOSS FTW! Open or Closed?
    17. De bi a n GNU/L i n u x f o r Mo bi le s v3. 5
    18. 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
    19. 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
    20. !"#$%&'%(#)*+,%-.,/%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!
    21. The “F” word
    22. “[...] 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
    23. 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
    24. 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”
    25. 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
    26. How to engage?
    27. ... 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 ...
    28. “We don’t have an official agreement that needs to be signed.” (But we can put one together if you need one.)
    29. The Source Code
    30. diff noun informal short for difference . verb [ trans. ] Computing compare (files) in order to determine how or whether they differ.
    31. $ du -sh upstream_diff_dir 86M upstream_diff_dir
    32. 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
    33. Working together
    34. PLEASE HELP!
    35. Thank you.

    ×