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.
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
18. User interface
Increasing commoditisation
LiMo “middleware”
Linux kernel
Some Implications of Software Commoditisation
http://osdir.com/Article204.phtml
21. De bi a n GNU/L i n u x
f o r Mo bi le s v3. 5
22. 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
23. 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
27. “[...] 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
28. 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
29. 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”
30. 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
32. ... 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 ...
33. “We don’t have an official agreement
that needs to be signed.”
(But we can put one together if you need one.)
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