LiMo Platform And Mobile Linux
by Andrew Savory on Feb 09, 2010
- 983 views
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. ...
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.
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 0
- Downloads
- 0
- Comments
- 0
- Embed Views
- Views on SlideShare
- 980
- Total Views
- 983
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.
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.
Here’s four things you need to know about LiMo.
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.
Foundation is a relatively common legal structure for collaborative organisations.
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
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)
Shared costs, increasingly raising the bar of commodity layer.
Ultimately allows us to focus on points of differentiation such as user experience.
Maemo: Nokia.
Moblin: Intel.
Symbian: Nokia.
Can you name the key influencers in LiMo?
But Motorola’s Razr v8 and derivatives are LiMo R1 devices
Samsung Vodafone 360 H1 and M1 are LiMo R2 devices
Any questions so far?
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?
STOCK VANILLA LINUX “commodity” KERNEL
“commodity open source” unified within the middleware
Case studies, being more approachable, professional services companies all help
Identifiable events (FOSDEM, GUADEC) and point of contact / spokespeople
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
List of our packages later
But good general practice for all projects
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.
How we approach it
FSFE Legal Network linking doc
Member’s responsibility for upstream
FPL
Keep your house in order
ASF everything “safe”
Because of the nature of product development, it’s common (if not natural) to fork an open source package.
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.
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
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)
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
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?
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.
This can cause some confusion.
It will happen, but it takes time.
Meanwhile, we can take concrete action around something everyone understands: the code.
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
The interesting bit is the list of changes we’ve made - the diffs.
But little experience in working with open source
A few have made the jump - Nokia, with Maemo
A lot of us still need help
Ask us questions
Give us suggestions
Tell us when we get it wrong ... or right