1 / 50

MeeGo Seminar

ananda
Download Presentation

MeeGo Seminar

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. MeeGo Seminar

    2. Outline Maemo and Moblin Merger MeeGo Reference Uxs Community Roadmap and Release Management Ecosystem Success MeeGo and Upstream Governance Compliance

    3. MeeGo Project Announcement

    4. Feb 15, 2010: MeeGo Announcement at MWC Kai stam (EVP Devices, Nokia) and Renee James (SVP and GM SSG, Intel)

    5. Feb 15, 2010 Announcement Intel and Nokia announced a new collaborative project MeeGo on Feb 15th at Mobile World Congress The agreement includes joining the efforts behind existing open source projects, Moblin and Maemo, into a single open source project MeeGo MeeGo unifies Moblin and Maemo to provide next generation of open source software platform for the client devices The agreement a rationale evolution step to combine identical platform projects of the two biggest Linux investors with similar visions

    6. Intel-Nokia partnership gives birth to MeeGo

    7. Moblin & Maemo: A lot in common 2 large companies with a strong believe in the open source development model and collaboration with open source community Very similar software stack architecture Use majority of the same open source components Working with upstream projects Driven as true open source projects Aim for same technical end result (on different device types supporting different HW architectures): faster boot, better power usage, better memory usage, high performance, small footprint images, full internet/browser experience ...

    8. Gains of Merger 1/2 Unify the efforts of the Moblin and Maemo communities and enable a next generation open source Linux-platform suited for a variety of client devices. A single platform reduces fragmentation and complexity for OEMs and operators. Bring together the best technologies making MeeGo more appealing to a wider customer and ecosystem partners base.

    9. Gains of Merger 2/2 Expands the market opportunities on a wide range of devices: handsets, netbooks, tablets, connected-tvs, IVI systems. MeeGo unifies developers providing a wealth of application and services innovation for customers to build on.

    10. MeeGo Guiding Principles Freedom for innovation Openness Community involvement Work with upstream projects

    11. What is MeeGo? A true Linux-based open source platform that offers a full client Linux open source software stack including: The core OS up to UI libraries and tools Reference user experience and applications Standard set of APIs across client devices Flexibility to support proprietary add-ons Capability to run on multiple computing devices, including handsets, netbooks, tablets, connected TVs and in-vehicle infotainment systems.

    12. MeeGo reference architecture

    13. MeeGo component-level architecture

    14. MeeGo application development environment

    15. MeeGo developer infrastructure

    16. MeeGo Reference User Experiences (UXs)

    17. MeeGo Reference UXs A reference UX experience is UX implementation intended to both illustrate the capabilities of the MeeGo platform and (optionally) be the starting point for product development MeeGo Reference UXs Netbook (May 25, 2010) Includes a netbook user interface and a set of reference applications. Built using the Netbook UI framework, a netbook-specific UI framework Based on Moblin 2.x Netbook UI Framework and reference UX Handset (expected end of June 2010) Includes a handset user interface and a set of reference applications. Built using a handset specific UI framework built on top of the MeeGo UI toolkit Based on Maemo6 UI Framework Other Reference UXs (planned)

    18. MeeGo Core OS Day 1 March 31 Day 1 is the when we opened the development of the merged OS This was the first public showing of MeeGo Supported IA and Tis OMAP3 (N900) Included: Core OS Build Tools Dev environment Multi-architecture support

    19. MeeGo user experience for netbook

    20. Netbook UX

    21. MeeGo 1.0 released in May Netbook user experience Supported by multiple OS vendors Core OS for multi-architecture

    22. MeeGo Handset Day 1 June 30 Handset Day 1 is the opening of the Handset stack and reference UX development Supports IA Moorestown (Aava) and TI OMAP3 (Nokia N900) Includes (in addition to 1.0): MeeGo Touch Framework Qt Telephony Messaging Handset application suite Development environment Sensors support Usage context data management Etc...

    23. Handset UX (released June 30, 2010)

    26. Tablet UX

    27. Roadmap and Release Engineering

    28. Basics MeeGo releases will occur every 6 months. Each release cycle will follow the same basic pattern (described later). Each release will contain the MeeGo core and the existing set of MeeGo categories. MeeGo releases started with version 1.0 (may 2010). Currently the numbers have no specific meaning, other than that a bigger number means a newer release. Release content specifications (features) are available in Bugzilla inbugs.meego.com, as well as in Release Trunk and Release branch inbuild.meego.com. Releases and builds with related release notes, images, etc., are published inrepo.meego.com.

    29. Roadmap

    30. MeeGo Road Mapping & Requirement Management

    31. MeeGo Ecosystem

    32. Overall MeeGo Platform Ecosystem OSVs provide Complete Stable Image Final integration / validation Technical support / debug Custom patches / updates Additional documentation Sustaining engineering OSV charge for the following based on OEM needs: Integration of close source components; Moblin provides all open sources software and several closed source components are required to complete a distribution for an OEM platform. Some examples are closed source codecs as well as closed source drivers for components used in the OEM platform. These closed source components may be made available by the OEMs, however, the OSV has to ensure these components are integrated in the distribution. Customizing the UI per OEM requirements; Moblin provides a rich application and UI framework based on Clutter technology; however, the reference distribution on moblin.org would include a basic reference UI; OEMs would prefer to customize the UI to deliver a rich end-user experience that can be made possible with the moblin UI framework and OSV can provide this service. Develop additional middleware or applications per OEM requirements; these could be either or both open source applications modified/optimized to work with the rest of the stack in the distribution Integration and validation of all Moblin and non-Moblin components on OEMs platform; The validation of the Moblin reference stack will be typically done on Intel customer reference boards and not necessarily on specific OEM platform; in order to make sure the Moblin distro put together by the OSVs is qualified on the OEM platform, the OSV and/or the OEM need to do complete validation on the final platform. OSVs also may localize for geographic markets, coordinate upstream community activities, ensure legal compliance, and manage file and security updates. Last but not the least is the on-going support to an OEM on all associated software services ranging from bug-fixes, enhancements and software refreshes for subsequent platforms. OSVs provide Complete Stable Image Final integration / validation Technical support / debug Custom patches / updates Additional documentation Sustaining engineering OSV charge for the following based on OEM needs: Integration of close source components; Moblin provides all open sources software and several closed source components are required to complete a distribution for an OEM platform. Some examples are closed source codecs as well as closed source drivers for components used in the OEM platform. These closed source components may be made available by the OEMs, however, the OSV has to ensure these components are integrated in the distribution. Customizing the UI per OEM requirements; Moblin provides a rich application and UI framework based on Clutter technology; however, the reference distribution on moblin.org would include a basic reference UI; OEMs would prefer to customize the UI to deliver a rich end-user experience that can be made possible with the moblin UI framework and OSV can provide this service. Develop additional middleware or applications per OEM requirements; these could be either or both open source applications modified/optimized to work with the rest of the stack in the distribution Integration and validation of all Moblin and non-Moblin components on OEMs platform; The validation of the Moblin reference stack will be typically done on Intel customer reference boards and not necessarily on specific OEM platform; in order to make sure the Moblin distro put together by the OSVs is qualified on the OEM platform, the OSV and/or the OEM need to do complete validation on the final platform. OSVs also may localize for geographic markets, coordinate upstream community activities, ensure legal compliance, and manage file and security updates. Last but not the least is the on-going support to an OEM on all associated software services ranging from bug-fixes, enhancements and software refreshes for subsequent platforms.

    33. Developer value proposition Prospect of high volume installed base of leading devices Qt Cross-platform development framework expands business opportunities across markets Leading SDK with Qt Creator IDE One set of API:s for application and service development Choice of App Stores to reach the market Backed up by Nokia and Intel developer support programs

    34. Success Factors

    35. What makes MeeGo unique? Broad industry support and adoption in all categories Great UX Great OS Multi-category Multi-HW Active community Open governance model Close relation with upstream projects A partnership project Compliance program Successful app store story Ability to provide areas for differentiation and support for proprietary add-ons

    36. MeeGo and Upstream

    37. MeeGo Compliance Program

    38. Multiple app stores, multiple device types

    39. GENIVI will be using MeeGo for their reference system. MeeGo and Automotive

    40. Everyone is a winner

    41. MeeGo Governance

    42. High level 1 Technical Steering Group (TSG) 1 MeeGo core team 5 MeeGo Verticals: Handset, Tablet, Connected-TV, IVI and Netbook Each vertical has 1 working group (WG) and 1 project team (PT) also called implementation or execution team

    43. MeeGo Organization Structure

    44. MeeGo Verticals There are 5 device categories: Each device category has its own working group (WG). Each device category working group has its own project team that is responsible for execution. The project and product managers in the project team of any given WG also participate in the activities of WG and act as coordinators between WG governance and execution teams.

    45. Working methods Follow the same working methods as the master MeeGo project Mailing lists IRC meetings F2F during MeeGo events Wiki style collaboration (working on requirements and gaps) Document decisions along with any outstanding issues, which may be used as the basis for further discussion Meetings WG meetings (to be decided by the WG) Bi-weekly meeting between WG chairs / TSG / Linux Foundation F2F meetings aligned with Linux Foundation and/or MeeGo events Example MeeGo Community WG: http://wiki.meego.com/Community_working_group

    46. MeeGo Compliance

    47. 2 Sides of Compliance: Apps & Systems

    48. MeeGo Compliance: Basic Principles (1/2) Developers of MeeGo products (apps, systems, devices, etc.) interested in using the MeeGo trademark must apply for compliance and will be granted permission to use the MeeGo mark by the Linux Foundation upon successfully demonstrating compliance. Compliance is based on published MeeGo Compliance Specifications of common public API/ABI guaranteed to be provided by all MeeGo systems of the target segment (defined by MeeGo releases and profiles). MeeGo Core Stack compliance + 1 (or more) profile compliance is required Each MeeGo profile will have its own compliance specification. All MeeGo profiles are based on the MeeGo Core Stack. Compliance is verified separately for apps and systems against a specific version of MeeGo specification/release. Apps to be MeeGo certified should declare which profiles they require from the system. Systems to be MeeGo certified should declare which profiles they support.

    49. MeeGo Compliance: Basic Principles (2/2) Compliance is verified using automated tools to enforce technical consistency of MeeGo applications and systems. The tools execute based on the MeeGo Compliance Specifications (as defined by the MeeGo Core Stack and each MeeGo Profile). ISV (App) Verification Tools: Check that particular app depends only on allowed interface elements and interacts with the system correctly. OSV Verification Tools: Check that particular system provides all required interface elements and that their functionality is ok.

More Related