LiMo is a mobile industry consortium that aims to develop a collaborative open source mobile platform. It has 52 member companies and uses an open governance model where members can contribute code under various open source licenses. The goal is to create a common platform where members and non-members can build applications and differentiation occurs at the application and services layer, not the operating system layer. The first release of the LiMo platform focuses on core functionality like telephony, multimedia, and networking. Challenges include the newness of the collaborative development model and ensuring reciprocal sharing of innovations between members and the open source community.
This presentation was for the Cambridge Wireless “Open Source - free lunch?” Software SIG event on 25th February 2009. The event aimed to explore the world of mobile open source software development and to challenge the arising issues from this debate.
This document provides an overview of the major open source software platforms for mobile devices in 2009. It discusses Symbian, Android, ChromeOS, LiMo, Moblin, and Maemo. For each, it describes the key companies and devices supporting the platform as well as the foundational open source tools and technologies used, such as WebKit, GTK, and Qt. It predicts that Android, Symbian and Maemo will be the three strongest open source alternatives for mobile devices going forward.
Importance Of The Maemo Community Randall ArnoldAshley Walker
The document discusses the Maemo community and development experience for mobile developers. It provides an overview of the history and growth of the Maemo community from small beginnings in 2005 focused on "hacking" to a larger, more organized community today that demands more support from Nokia. It describes improvements in the relationship between Nokia's corporate interests and the Maemo developer community, including Nokia supporting "hacker editions" of operating systems. The document outlines the current ideal dynamics and provides examples of positive changes in 2009 like Nokia sponsoring summit attendees and presenting a general roadmap. It also describes the development options and processes for the Maemo platform.
The document discusses the rise of Android as an open source mobile platform. It notes that Android has gained significant support from device makers and mobile carriers. However, it also notes potential issues like platform fragmentation and the difficulty for third parties to make money developing apps. The document considers whether Android adoption could be limited and what alternatives may exist, like Moblin, Maemo, or sticking with existing platforms like Symbian. It raises the question of whether Android will truly see widespread use or be limited in its role as a platform.
The GPL: What It Means (And What It Doesn't) - WC UdaipurNancy Thanki
The GNU General Public License (GPL) is a free (as in freedom) software license that is used by many open source projects, including WordPress. While many of us are probably familiar with the GPL, there are also a number of misconceptions. It’s important, as WordPress professionals, for us to be able to talk about the GPL with our clients and coworkers -- both in terms of what the GPL says and also what it doesn't say. The GPL is based on some extremely powerful ideas, and it is a shame that they are sometimes misunderstood. If you feel like maybe you could use a refresher or some ideas about how to explain the GPL to people you are working with, this talk is for you.
Stefano Fornari - Come creare e far crescere un progetto ed una community ope...Better Software
Creare un software open source è molto di più che rendere scaricabile del codice sorgente. E' creare e alimentare una comunità fatta di utenti prima che di sviluppatori, che assieme contribuiscono a far progredire il prodotto innescando un circolo virtuoso tra le esigenze della comunità e quelle di un'azienda commerciale.
The document discusses Android's potential impact on netbooks. It provides an overview of Android as an open source operating system and ecosystem. Several examples are given of netbooks already running Android, including models from HP, Acer, and Lemote. Customized versions of Android have been developed by companies like ThunderSoft to optimize the user interface for netbooks. The document concludes that while Android's impact may be greater in Asia initially, tablets are expected to drive more usage in the US.
This presentation was for the Cambridge Wireless “Open Source - free lunch?” Software SIG event on 25th February 2009. The event aimed to explore the world of mobile open source software development and to challenge the arising issues from this debate.
This document provides an overview of the major open source software platforms for mobile devices in 2009. It discusses Symbian, Android, ChromeOS, LiMo, Moblin, and Maemo. For each, it describes the key companies and devices supporting the platform as well as the foundational open source tools and technologies used, such as WebKit, GTK, and Qt. It predicts that Android, Symbian and Maemo will be the three strongest open source alternatives for mobile devices going forward.
Importance Of The Maemo Community Randall ArnoldAshley Walker
The document discusses the Maemo community and development experience for mobile developers. It provides an overview of the history and growth of the Maemo community from small beginnings in 2005 focused on "hacking" to a larger, more organized community today that demands more support from Nokia. It describes improvements in the relationship between Nokia's corporate interests and the Maemo developer community, including Nokia supporting "hacker editions" of operating systems. The document outlines the current ideal dynamics and provides examples of positive changes in 2009 like Nokia sponsoring summit attendees and presenting a general roadmap. It also describes the development options and processes for the Maemo platform.
The document discusses the rise of Android as an open source mobile platform. It notes that Android has gained significant support from device makers and mobile carriers. However, it also notes potential issues like platform fragmentation and the difficulty for third parties to make money developing apps. The document considers whether Android adoption could be limited and what alternatives may exist, like Moblin, Maemo, or sticking with existing platforms like Symbian. It raises the question of whether Android will truly see widespread use or be limited in its role as a platform.
The GPL: What It Means (And What It Doesn't) - WC UdaipurNancy Thanki
The GNU General Public License (GPL) is a free (as in freedom) software license that is used by many open source projects, including WordPress. While many of us are probably familiar with the GPL, there are also a number of misconceptions. It’s important, as WordPress professionals, for us to be able to talk about the GPL with our clients and coworkers -- both in terms of what the GPL says and also what it doesn't say. The GPL is based on some extremely powerful ideas, and it is a shame that they are sometimes misunderstood. If you feel like maybe you could use a refresher or some ideas about how to explain the GPL to people you are working with, this talk is for you.
Stefano Fornari - Come creare e far crescere un progetto ed una community ope...Better Software
Creare un software open source è molto di più che rendere scaricabile del codice sorgente. E' creare e alimentare una comunità fatta di utenti prima che di sviluppatori, che assieme contribuiscono a far progredire il prodotto innescando un circolo virtuoso tra le esigenze della comunità e quelle di un'azienda commerciale.
The document discusses Android's potential impact on netbooks. It provides an overview of Android as an open source operating system and ecosystem. Several examples are given of netbooks already running Android, including models from HP, Acer, and Lemote. Customized versions of Android have been developed by companies like ThunderSoft to optimize the user interface for netbooks. The document concludes that while Android's impact may be greater in Asia initially, tablets are expected to drive more usage in the US.
The Importance of IVI, GENIVI and Open Sourcegenivialliance
Session given at ConnectedCars on November 13, 2012 by John Lehmann, Embedded Automotive Solutions, Mentor Graphics, and Board Member of the GENIVI Alliance, “The Importance of IVI, GENIVI, and Open Source”.
1) Mobile Linux Landscape is dominated by a competition between Android and MeeGo operating systems for smartphones.
2) MeeGo is a new open source software platform created by merging the Maemo and Moblin operating systems.
3) Nokia plans to release its first MeeGo-based smartphone in the second half of 2010 in an effort to combine its platform projects with Intel and establish an ecosystem play.
The document discusses Qt licensing options. Developers have a choice between the commercial Qt license from Nokia, which allows keeping all code private but restricts mixing licenses, or the LGPL license from the Free Software Foundation, which has some restrictions like requiring app code to remain private and dynamically linked to Qt. The document provides five factors to consider when choosing a license: external distribution needs, the target audience, modification plans, static vs dynamic linking, and calls to proprietary components.
Mobile Developer's Guide To The Galaxy 12th EditionMarco Tabor
This document provides an overview of the mobile development landscape including key platforms, technologies, and strategies. It discusses the major mobile operating systems including Android, iOS, Windows Phone, BlackBerry 10, and others. It also covers different approaches to building mobile services such as native apps, web apps, and hybrid apps. The document aims to introduce mobile developers to the complex universe of the mobile industry.
Android is an open-source, Linux-based operating system for mobile devices like smartphones and tablets. It was developed by Android Inc, which was acquired by Google in 2005. Google releases Android code under the Apache license and maintains it through the Android Open Source Project. Key features include support for apps, the Linux kernel, and an open governance model.
Meego Italian Day 2011 – Andrea Grandi - Qt: l’infrastruttura di programmazione multipiattaforma.
Panoramica di Qt: libreria multipiattaforma per lo sviluppo di programmi con interfaccia grafica tramite l’uso di widget. Perchè usarla? Quali sono i vantaggi? Che linguaggio di programmazione utilizza? E sotto che licenza viene rilasciata? Insomma, tutto quello che abbiamo sempre voluto sapere su Qt, ma non abbiamo mai osato chiedere. Inoltre qualche nozione teorica su Qt Quick e QML.
Andrea Grandi è studente di Informatica presso l’Università di Firenze e ha lavorato per qualche anno come sviluppatore di software. Dal 2007 fa parte della community di Maemo, in cui si impegna attivamente per aiutare i nuovi utenti, organizzare eventi e sviluppare applicazioni; recentemente è stato eletto membro del Maemo Community Council. Ha iniziato da alcuni anni a lavorare con Qt/C++ per creare programmi destinati ai dispositivi Maemo sino ad accumulare un’esperienza tale da essere nominato Nokia Qt Ambassador. Inoltre è socio fondatore del Pistoia Linux User Group.
http://www.meegoit.com/2011
Tizen Overview and Architecture - Seokjae Jeong (Samsung) - Korea Linux Forum...Ryo Jin
The document discusses Tizen's application framework which provides capabilities for launching applications via actions, URIs and MIME types, managing the life cycle and system events of applications, installing and uninstalling applications, and maintaining a history of launched applications. It also notes that the framework allows launching different types of applications such as moving from a web application to a native application.
Android is an open source operating system developed by Google and the Open Handset Alliance. It allows device manufacturers and developers to modify and distribute the software. There is a large community of developers creating apps that extend the functionality of Android devices, primarily written in Java. By 2012 there were over 700,000 apps available on Android with over 25 billion downloads from the Google Play store.
Android and Tizen are two popular mobile operating systems. Android was developed by Google and is based on the Linux kernel, designed for touchscreen devices like smartphones and tablets. It uses touch gestures for input and has versions for TVs, cars, and watches. Tizen is also Linux-based and supported by Samsung, Intel and others. It aims to provide an alternative to existing mobile platforms and supports multiple device types like smartphones, tablets and smart TVs. Both have open source components but ultimately ship with proprietary software required for services. Android dominates the smartphone market while Tizen sees more use in Samsung devices.
This slidedeck is the first presentation in a series of presentations on legal issues on open source licensing by Karen Copenhaver of Choate Hall and Mark Radcliffe of DLA Piper. To view the webinars, please go to http://www.blackducksoftware.com/files/legal-webinar-series.html. You may also want to visit my blog which frequently deals with open source legal issues http://lawandlifesiliconvalley.com/blog/
1. The document discusses Bosch Software Innovations and the Internet of Things and Services (IoTS). It provides an overview of Bosch as a company, their work on open source software and communities, and their vision for an open ecosystem approach to connected mobility, energy, cities, and more through an IoTS platform.
2. Bosch is working to build an "Internet Application Platform" to enable IoTS applications in an open but private manner. The platform will incorporate open source components and work with partner companies while protecting user privacy and not harvesting personal data.
3. One of the biggest challenges for traditional industries becoming part of the IoTS is adapting to its dynamic, multi-sided nature based
MeeGo is an open-source, Linux-based operating system maintained by the Linux Foundation that merges Intel's Moblin and Nokia's Maemo projects. It is designed to run on various device types including netbooks, smartphones, in-vehicle infotainment systems, connected TVs, and tablets. MeeGo allows for flexible customization of the user interface and applications across different device categories and manufacturers while providing an advanced feature set and development tools to developers.
MeeGo is an open source software platform for a broad range of computing devices including netbooks, desktops, tablets, smart TVs, and handheld devices. It provides a common set of APIs and user experiences across devices, including customization, pre-integrated apps and services, full internet access, rich media, and 3D animation. MeeGo is developed with an open, merit-based and transparent process under the Linux Foundation and allows OEMs, service providers and developers to differentiate while avoiding fragmentation.
Android is an open-source, Linux-based operating system designed primarily for smartphones and tablets. Initially created by Android Inc., which was later acquired by Google, Android was unveiled in 2007. It has the largest worldwide market share of any mobile operating system. Key aspects include being open-source, having a large developer community creating applications, and allowing device manufacturers to customize Android for their devices.
Developers Guide To The Galaxy 8th editionMarco Tabor
Completely updated and extended edition of this non-commercial overview on mobile technologies and development approaches. Helpful for developers and decision makers without technical background.
This document provides an overview of the mobile development landscape. It discusses the major mobile platforms including Android, iOS, Windows Phone, BlackBerry 10, and emerging platforms like Tizen and Firefox OS. It notes that while Android and iOS dominate globally, regional and local markets can vary significantly. The document also covers different app types like native, web, and hybrid apps. It emphasizes that the mobile space is constantly changing and developers need to stay up to date on the latest platforms and trends.
This document provides an overview of open source software. It discusses the advantages of open source like access to source code, ability to fix bugs and customize. It also discusses licensing models like GPL and BSD and how companies use open source software. It provides examples of open source projects like Red Hat, JBoss, Mobicents which provides telecom middleware. It encourages participation and contribution to open source.
Myths and realities of open source for FP7 projects: why OSS is important for the economy, benefits, drawbacks. Presented at the IST Internet of Services collaboration meeting 2011, in the FLOSS working group session. Data derived from previous Transfersummit presentation:
http://www.slideshare.net/cdaffara/transfersummit2011
Android is an open-source, Linux-based operating system leading the global smartphone market. It is developed by Google and the Open Handset Alliance and consists of a kernel based on Linux, along with basic applications and APIs written in C/C++. Key features include support for multi-touch, Bluetooth, storage, connectivity and a web browser based on WebKit. It allows third-party apps written in Java and supports multiple languages.
Android is an open-source, Linux-based operating system primarily used for mobile devices. It was developed by Android Inc, which was acquired by Google in 2005. The Android platform is maintained by the Open Handset Alliance, a consortium of technology companies, and the Android Open Source Project community. Key features of Android include support for apps, connectivity, messaging, storage, web browsing, and media playback.
Business Models of Opensource and Free SoftwareFabernovel
This first research paper, distributed under the Creative Commons license, helps us to think about the open source business and faberNovel Consulting’s contribution to this community. Voluntarily educational, “Business models of open source software and free software" offers a common reference, a “tool box" to communicate about these models and to understand and adapt them.
Speaker trung huynh opensource business modelAiTi Education
Open source and free software business models can be profitable and sustainable over time. Some common business models include:
1) The service model, where companies commercialize services related to open source software without tying them to a specific product.
2) The distribution with value added model, where companies sell a standard open source product along with value-added services like support.
3) The double license model, where software has an open source license for general use but a more restricted proprietary license for advanced functionalities or commercial use.
4) The mutualization model, where companies develop a basic open source product and then build custom modules on demand from users. These business models allow open source companies to thrive while
The Importance of IVI, GENIVI and Open Sourcegenivialliance
Session given at ConnectedCars on November 13, 2012 by John Lehmann, Embedded Automotive Solutions, Mentor Graphics, and Board Member of the GENIVI Alliance, “The Importance of IVI, GENIVI, and Open Source”.
1) Mobile Linux Landscape is dominated by a competition between Android and MeeGo operating systems for smartphones.
2) MeeGo is a new open source software platform created by merging the Maemo and Moblin operating systems.
3) Nokia plans to release its first MeeGo-based smartphone in the second half of 2010 in an effort to combine its platform projects with Intel and establish an ecosystem play.
The document discusses Qt licensing options. Developers have a choice between the commercial Qt license from Nokia, which allows keeping all code private but restricts mixing licenses, or the LGPL license from the Free Software Foundation, which has some restrictions like requiring app code to remain private and dynamically linked to Qt. The document provides five factors to consider when choosing a license: external distribution needs, the target audience, modification plans, static vs dynamic linking, and calls to proprietary components.
Mobile Developer's Guide To The Galaxy 12th EditionMarco Tabor
This document provides an overview of the mobile development landscape including key platforms, technologies, and strategies. It discusses the major mobile operating systems including Android, iOS, Windows Phone, BlackBerry 10, and others. It also covers different approaches to building mobile services such as native apps, web apps, and hybrid apps. The document aims to introduce mobile developers to the complex universe of the mobile industry.
Android is an open-source, Linux-based operating system for mobile devices like smartphones and tablets. It was developed by Android Inc, which was acquired by Google in 2005. Google releases Android code under the Apache license and maintains it through the Android Open Source Project. Key features include support for apps, the Linux kernel, and an open governance model.
Meego Italian Day 2011 – Andrea Grandi - Qt: l’infrastruttura di programmazione multipiattaforma.
Panoramica di Qt: libreria multipiattaforma per lo sviluppo di programmi con interfaccia grafica tramite l’uso di widget. Perchè usarla? Quali sono i vantaggi? Che linguaggio di programmazione utilizza? E sotto che licenza viene rilasciata? Insomma, tutto quello che abbiamo sempre voluto sapere su Qt, ma non abbiamo mai osato chiedere. Inoltre qualche nozione teorica su Qt Quick e QML.
Andrea Grandi è studente di Informatica presso l’Università di Firenze e ha lavorato per qualche anno come sviluppatore di software. Dal 2007 fa parte della community di Maemo, in cui si impegna attivamente per aiutare i nuovi utenti, organizzare eventi e sviluppare applicazioni; recentemente è stato eletto membro del Maemo Community Council. Ha iniziato da alcuni anni a lavorare con Qt/C++ per creare programmi destinati ai dispositivi Maemo sino ad accumulare un’esperienza tale da essere nominato Nokia Qt Ambassador. Inoltre è socio fondatore del Pistoia Linux User Group.
http://www.meegoit.com/2011
Tizen Overview and Architecture - Seokjae Jeong (Samsung) - Korea Linux Forum...Ryo Jin
The document discusses Tizen's application framework which provides capabilities for launching applications via actions, URIs and MIME types, managing the life cycle and system events of applications, installing and uninstalling applications, and maintaining a history of launched applications. It also notes that the framework allows launching different types of applications such as moving from a web application to a native application.
Android is an open source operating system developed by Google and the Open Handset Alliance. It allows device manufacturers and developers to modify and distribute the software. There is a large community of developers creating apps that extend the functionality of Android devices, primarily written in Java. By 2012 there were over 700,000 apps available on Android with over 25 billion downloads from the Google Play store.
Android and Tizen are two popular mobile operating systems. Android was developed by Google and is based on the Linux kernel, designed for touchscreen devices like smartphones and tablets. It uses touch gestures for input and has versions for TVs, cars, and watches. Tizen is also Linux-based and supported by Samsung, Intel and others. It aims to provide an alternative to existing mobile platforms and supports multiple device types like smartphones, tablets and smart TVs. Both have open source components but ultimately ship with proprietary software required for services. Android dominates the smartphone market while Tizen sees more use in Samsung devices.
This slidedeck is the first presentation in a series of presentations on legal issues on open source licensing by Karen Copenhaver of Choate Hall and Mark Radcliffe of DLA Piper. To view the webinars, please go to http://www.blackducksoftware.com/files/legal-webinar-series.html. You may also want to visit my blog which frequently deals with open source legal issues http://lawandlifesiliconvalley.com/blog/
1. The document discusses Bosch Software Innovations and the Internet of Things and Services (IoTS). It provides an overview of Bosch as a company, their work on open source software and communities, and their vision for an open ecosystem approach to connected mobility, energy, cities, and more through an IoTS platform.
2. Bosch is working to build an "Internet Application Platform" to enable IoTS applications in an open but private manner. The platform will incorporate open source components and work with partner companies while protecting user privacy and not harvesting personal data.
3. One of the biggest challenges for traditional industries becoming part of the IoTS is adapting to its dynamic, multi-sided nature based
MeeGo is an open-source, Linux-based operating system maintained by the Linux Foundation that merges Intel's Moblin and Nokia's Maemo projects. It is designed to run on various device types including netbooks, smartphones, in-vehicle infotainment systems, connected TVs, and tablets. MeeGo allows for flexible customization of the user interface and applications across different device categories and manufacturers while providing an advanced feature set and development tools to developers.
MeeGo is an open source software platform for a broad range of computing devices including netbooks, desktops, tablets, smart TVs, and handheld devices. It provides a common set of APIs and user experiences across devices, including customization, pre-integrated apps and services, full internet access, rich media, and 3D animation. MeeGo is developed with an open, merit-based and transparent process under the Linux Foundation and allows OEMs, service providers and developers to differentiate while avoiding fragmentation.
Android is an open-source, Linux-based operating system designed primarily for smartphones and tablets. Initially created by Android Inc., which was later acquired by Google, Android was unveiled in 2007. It has the largest worldwide market share of any mobile operating system. Key aspects include being open-source, having a large developer community creating applications, and allowing device manufacturers to customize Android for their devices.
Developers Guide To The Galaxy 8th editionMarco Tabor
Completely updated and extended edition of this non-commercial overview on mobile technologies and development approaches. Helpful for developers and decision makers without technical background.
This document provides an overview of the mobile development landscape. It discusses the major mobile platforms including Android, iOS, Windows Phone, BlackBerry 10, and emerging platforms like Tizen and Firefox OS. It notes that while Android and iOS dominate globally, regional and local markets can vary significantly. The document also covers different app types like native, web, and hybrid apps. It emphasizes that the mobile space is constantly changing and developers need to stay up to date on the latest platforms and trends.
This document provides an overview of open source software. It discusses the advantages of open source like access to source code, ability to fix bugs and customize. It also discusses licensing models like GPL and BSD and how companies use open source software. It provides examples of open source projects like Red Hat, JBoss, Mobicents which provides telecom middleware. It encourages participation and contribution to open source.
Myths and realities of open source for FP7 projects: why OSS is important for the economy, benefits, drawbacks. Presented at the IST Internet of Services collaboration meeting 2011, in the FLOSS working group session. Data derived from previous Transfersummit presentation:
http://www.slideshare.net/cdaffara/transfersummit2011
Android is an open-source, Linux-based operating system leading the global smartphone market. It is developed by Google and the Open Handset Alliance and consists of a kernel based on Linux, along with basic applications and APIs written in C/C++. Key features include support for multi-touch, Bluetooth, storage, connectivity and a web browser based on WebKit. It allows third-party apps written in Java and supports multiple languages.
Android is an open-source, Linux-based operating system primarily used for mobile devices. It was developed by Android Inc, which was acquired by Google in 2005. The Android platform is maintained by the Open Handset Alliance, a consortium of technology companies, and the Android Open Source Project community. Key features of Android include support for apps, connectivity, messaging, storage, web browsing, and media playback.
Business Models of Opensource and Free SoftwareFabernovel
This first research paper, distributed under the Creative Commons license, helps us to think about the open source business and faberNovel Consulting’s contribution to this community. Voluntarily educational, “Business models of open source software and free software" offers a common reference, a “tool box" to communicate about these models and to understand and adapt them.
Speaker trung huynh opensource business modelAiTi Education
Open source and free software business models can be profitable and sustainable over time. Some common business models include:
1) The service model, where companies commercialize services related to open source software without tying them to a specific product.
2) The distribution with value added model, where companies sell a standard open source product along with value-added services like support.
3) The double license model, where software has an open source license for general use but a more restricted proprietary license for advanced functionalities or commercial use.
4) The mutualization model, where companies develop a basic open source product and then build custom modules on demand from users. These business models allow open source companies to thrive while
Eclipse is an open source software development platform and framework. It was originally developed by IBM in 2001 and is now managed by the independent Eclipse Foundation. The Eclipse platform consists of modular projects and an ecosystem of third-party plugins. It has over 100 member organizations and 50 million downloads. Eclipse uses the OSGi framework specification and brings visibility to OSGi, while OSGi benefits from Eclipse's large user and developer community.
General Introduction of FOSS4G and OSGeoSANGHEE SHIN
This document provides an overview of open source GIS and OSGeo. It discusses what open source software is, the benefits it provides, and key open source GIS projects. Open source GIS projects are developed collaboratively and provide alternatives to proprietary GIS software. OSGeo is an organization that supports open source geospatial software development and promotes its use. Real-world examples show how governments and organizations have implemented open source GIS solutions using projects like PostGIS, GeoServer, and OpenLayers.
This document discusses the Open Platform for the Engineering of Critical Embedded Systems (OPEES) project. The main objectives of OPEES are to ensure long-term availability of open source tools for critical systems and support them for the entire lifecycle of very long-lived products, which can last up to 78 years. OPEES aims to build a sustainable ecosystem around these technologies by federating industrial users and service providers. This will help avoid vendor lock-in and allow common platforms to be shared. OPEES will implement additional features like community management, ecosystem development focused on industrial users, and processes for long-term support and maturity assessment of tools. The OPEES project involves 35 members from 5 European countries working to
The document summarizes a debate on open source versus proprietary software. It discusses definitions of open source software, popular open source licenses, and advantages of open source such as customizability, security, and lower costs. Open source is gaining adoption in government and enterprise due to benefits like avoiding vendor lock-in, lower costs, and higher quality from community contributions. Surveys find increasing enterprise adoption rates, with over 50% of new software to be open source in the next 5 years. Microsoft is also increasingly supporting open source.
Eric Fesler discusses using open source software. He explains that open source ensures certain software freedoms like free redistribution and access to source code. Fesler recommends choosing open source by defining needs, identifying options from directories like SourceForge, and doing a detailed review of aspects like community support and licensing. He advises working with open source by selecting best of breed components, managing version compatibility, and standardizing libraries.
Tim willoughby open source-in-local-governmentOpenSourceLGMA
The document discusses open source software (OSS) and its potential use and benefits for local governments. Some key points:
- OSS refers to software where the source code is openly available and can be modified. This is in contrast to proprietary software which restricts access to source code.
- OSS offers potential benefits for governments including reduced costs, increased stability and security, and greater control over software. It also allows for customization and integration with other open standards.
- The document outlines some open source vs closed source software types and provides examples of horizontal and vertical software where OSS could be applicable for governments.
- It acknowledges challenges to greater OSS adoption including lack of support, integration issues
This document provides an overview and update on the Symphony Software Foundation. It discusses the Foundation's guiding principles for an open source ecosystem, including openness, developer focus, inclusivity, and transparency. It outlines the roles of the Foundation, Symphony LLC, and community members. It also summarizes progress made, such as the first member meeting and elected member leads. Working groups are discussed as a way to foster adoption and industry convergence. The contribution process and different classes of projects under the Foundation umbrella are also summarized. Finally, initiatives to enable member contributions through a seamless developer experience, open source compliance, meritocratic influence, and awareness/visibility are outlined.
Open source masterclass - Life in the Apache IncubatorJukka Zitting
The document discusses life in the Apache incubator, which helps new projects develop their own collaborative communities under Apache Foundation guidance. It covers the incubator introduction and charter, entering the incubator by submitting a proposal, conducting IP reviews and releases, growing a diverse community, self-evaluating progress regularly, and ultimately graduating a project from the incubator.
This technical research report discusses open source software. It defines open source software and discusses its advantages and disadvantages. It also covers open source software licensing structures, support options for open source software, and defines computer and information security. The report was submitted by a student in partial fulfillment of requirements for an information technology course.
The document discusses open source software, including its growing adoption and various business models. It covers open source licenses and their different levels of permissiveness. Some key points include:
- By 2011, 80% of commercial software will contain open source code according to a Gartner study.
- There are over 300,000 open source projects on SourceForge alone.
- Major companies like IBM, Apple, and Microsoft contribute to and use open source software.
- Licenses like the GPL require all derivative works to remain open source, while licenses like the MPL allow proprietary works to use open source code.
- Businesses can make money from open source in various ways like support, services, complementary proprietary products
The document provides an overview of an upcoming workshop on the Hibachi Eclipse project. It discusses the goals of introducing Eclipse and Hibachi, providing background on Eclipse and an overview of the Hibachi project including its goals, current status, and future direction.
Open source is a program in which the source code is available to the general public for use and/or modification from its original design free of cost.
Open source software are the once whose licenses are not restrictive and if gives us the freedom to use the program for any purpose, modify it and distribute it for further use without having to pay for it.
An introduction to Symphony Softwar Foundation, community, projects, open source and open standards focused initiatives for innovation in financial services and fintech.
For more information check out:
Website: http://symphony.foundation
Wiki: https://symphonyoss.atlassian.net/wiki/
Github: https://github.com/symphonyoss/
OSGi Architecture for Mobile Device Software - Peter Kriens, aQutemfrancis
The document proposes an architecture called the Mobile Expert Group (MEG) that extends the OSGi Service Platform for use in mobile devices. It aims to provide a simple application model similar to MIDLets, standardized device management, and deployment capabilities. The key components of the MEG architecture include bundles, application containers for different types of applications, a device administration model based on OMA Device Management, and a deployment administration system to manage dependencies and installation of bundles. The architecture integrates native, Java ME, and OSGi applications and aims to standardize application lifecycles and device management across diverse mobile platforms.
"Integrating Open Source into Your Business" by Adam Jollans @ eLiberatica 2008eLiberatica
This is a presentation held at eLiberatica 2008.
http://www.eliberatica.ro/2008/
One of the biggest events of its kind in Eastern Europe, eLiberatica brings community leaders from around the world to discuss about the hottest topics in FLOSS movement, demonstrating the advantages of adopting, using and developing Open Source and Free Software solutions.
The eLiberatica organizational committee together with our speakers and guests, have graciously allowed media representatives and all attendees to photograph, videotape and otherwise record their sessions, on the condition that the photos, videos and recordings are licensed under the Creative Commons Share-Alike 3.0 License.
Similar to Collaborative Development for the future of Mobile (20)
Simply having a mobile strategy is no longer enough. Marketers need a mobile strategy that understands, targets and engages their most valuable mobile customers: the mobile elite.
This presentation explains how consumers are using devices today and how to identify the most profitable mobile segments.
Based on findings from the 2014 5th Adobe Mobile Consumer Survey, which had over 3,000 global responses from mobile users, this presentation will give valuable insights into:
• Preferred mobile channels and spending habits
• How to deliver and optimise targeted, engaging mobile experiences
• How to personalise in real time through the use of geo-location
This presentation will guide your formation of a high-value mobile strategy.
AdaptTo 2013: Slinging multichannel content the BrowserMap way / Device Detec...Andrew Savory
Sling selectors provide a powerful and flexible way to decide what content to deliver and how to present it. BrowserMap provides client-side device capability detection. By combining Sling and BrowserMap, you can quickly and easily build multichannel publishing solutions, adapting your content delivery to the capabilities of the device visiting your site. In this session we looked at how and why you should build this, and provide hints and tips on best practice.
Andrew Savory, Adobe
Conrad Woeltge, CEO & Owner, CW & Friends
The document discusses how to build mobile apps using CQ Mobile and leverage existing CQ investments. It presents PhoneGap as a way to create apps using HTML, CSS and JavaScript across multiple platforms. It also demonstrates how to reuse content from CQ using Content Sync and build custom mobile experiences while reusing the CQ backend infrastructure and content.
This talk was presented at CQCON 2013 in Basel.
Learn how to master development workflows combining the power of CQ with Apache Maven and Git. Sometimes it can be hard to get up and running with other developers' Adobe CQ projects. Where is the code? How can you build it once you have it? How do you get it into CQ? What do you do with it once it's there? Anyone should be able to quickly and easily perform a git clone of a CQ project, followed by doing a Maven build and install, and then immediately be able to try it out and work on it within CQ. This session will show developers how they can structure their projects so that they are buildable "out of the box". We will provide hints and tips on how to structure your application in git, and explain which maven plugins to use in a range of circumstances.
See the CQCON website http://www.cqcon.eu/2013/en/speakers/andrew-savory.html or the online version of the presentation at http://www.andrewsavory.com/presentations/CQCon_2013_CQ_Maven_Methods/index.html
The source of the presentation is in github at https://github.com/savs/CQCon_2013_CQ_Maven_Methods
Lucene and Solr are open-source search engines developed by the Apache Software Foundation (ASF). Lucene was created in 1999 and donated to ASF in 2001. Solr was created in 2004 and donated to ASF in 2006. Both projects have large user communities and are maintained through a collaborative process within ASF. ASF provides organizational support for many open-source projects through a meritocratic process.
This presentation was for a workshop at the Institutional Web Management Workshop in 2005: http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2005/sessions/savory/
From the abstract:
Dealing with external agencies for your web needs can be a frustrating experience - for you, as well as for them. Whether you're dealing with institutional IT services or a third-party company, there are many common problems that can occur.
This workshop will take a look at the issues involved in getting the job done, including:
* how to efficiently specify your work
* how to pick an external company
* how to check on and measure progress
* how to sign off and quantify achievements
* liaising between external companies and internal IT services
* dealing with ongoing support and maintenance
These slides were for a presentation at the Apache Cocoon GetTogether in 2005.
From http://web.archive.org/web/20051221213534/www.cocoongt.org/speakers/andrew.html here is the synopsis:
New frameworks such as Ruby on Rails are teaching the old dogs some new tricks. With the maxims of "write less code", "don't repeat yourself" and " convention over configuration", programming has become fun again. What can the Cocoon framework learn from this?
Consider the lilies: most Java/XML developers fight with configuration and project building tools, and while they do XML situps, our Rails colleagues utter nice Zen-like 'umms' as their framework gently guesses at their thoughts.
This session will point out the ways in which we can learn from our competitors and make life easier for our users. It will also introduce Racoon: all the fun of Rails, on Cocoon.
Andrew gave a presentation on GNOME, Linux mobile stacks, and engaging with open source communities. He discussed the growth of the mobile market and importance of open platforms. GNOME's role in providing tools for developers on mobile was covered. Finally, he compared GNOME and Qt frameworks, emphasizing the need for fair evaluation of open source options. Developers should find accessible SDKs to get involved in building for open platforms.
The mobile landscape has changed quite dramatically over the past few years, with the emergence of new mobile platforms and a significant shift toward open source in mobile technologies. What are the key economic drivers for this shift, and what are the lessons that can be learnt from the mobile industry's adoption of open source?
This talk draws on Andrew's experiences as Open Source Manager for the LiMo Foundation. It looks at how and why open source has become commonplace in mobile platform development, and the advantages and pitfalls of using open source.
This workshop introduced the power of XML and XSLT to delegates. It used an innovative solution of Apache Cocoon on a single server and form-based file upload to allow delegates to quickly and simply see the effect of applying XSL transformations on their markup.
Before leaving university and starting Luminas Limited, the directors were all involved in running student union-backed web sites. While doing this, they obtained a unique perspective on what students want from a university site. In this talk, they present some ideas from this experience that you may not have considered before.
Mobile distributions and upstream challengesAndrew Savory
The document discusses the challenges faced by developers in building Linux-based mobile distributions. It notes the lack of widespread adoption of Linux phones over recent years. It then lists several past and present mobile Linux projects. Key upstream challenges mentioned are determining the latest software releases and licenses, obtaining reference hardware, resolving package management differences, and setting up cross-compilation and virtual hosting environments. The presentation raises questions around the future direction of mobile Linux development.
This document discusses open source in mobile platforms. It begins with a brief history of open source from 1983 to the present. It then discusses the 3 main economic drivers for open source in mobile today: reduced cost of software acquisition, access to innovation, and reduced ownership costs. It notes that maintenance is the biggest cost for community open source software. The document discusses strategies for mobile open source projects like merging with upstream projects, contributions from large companies, and reuse of code between projects. It emphasizes that working with open source requires sophisticated supply chain management rather than just technical skills. The future will see convergence of platforms and developers building for multiple platforms.
The document discusses openness in mobile applications and operating different platforms' level of openness based on criteria like source code accessibility, discoverability, sharing, shopping, deploying, paying, and supported languages. It assigns a score to platforms like iPhone, Android and Palm based on these criteria, with iPhone scoring the lowest at 6.5 and Palm scoring the highest at 14.5. While iPhone limits openness, it now dominates the market with over 50 million customers, 125,000 developers and 100,000 available apps on its App Store, with over 2 billion downloads.
Building Production Ready Search Pipelines with Spark and MilvusZilliz
Spark is the widely used ETL tool for processing, indexing and ingesting data to serving stack for search. Milvus is the production-ready open-source vector database. In this talk we will show how to use Spark to process unstructured data to extract vector representations, and push the vectors to Milvus vector database for search serving.
Project Management Semester Long Project - Acuityjpupo2018
Acuity is an innovative learning app designed to transform the way you engage with knowledge. Powered by AI technology, Acuity takes complex topics and distills them into concise, interactive summaries that are easy to read & understand. Whether you're exploring the depths of quantum mechanics or seeking insight into historical events, Acuity provides the key information you need without the burden of lengthy texts.
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
AI 101: An Introduction to the Basics and Impact of Artificial IntelligenceIndexBug
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Digital Marketing Trends in 2024 | Guide for Staying AheadWask
https://www.wask.co/ebooks/digital-marketing-trends-in-2024
Feeling lost in the digital marketing whirlwind of 2024? Technology is changing, consumer habits are evolving, and staying ahead of the curve feels like a never-ending pursuit. This e-book is your compass. Dive into actionable insights to handle the complexities of modern marketing. From hyper-personalization to the power of user-generated content, learn how to build long-term relationships with your audience and unlock the secrets to success in the ever-shifting digital landscape.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
HCL Notes and Domino License Cost Reduction in the World of DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-and-domino-license-cost-reduction-in-the-world-of-dlau/
The introduction of DLAU and the CCB & CCX licensing model caused quite a stir in the HCL community. As a Notes and Domino customer, you may have faced challenges with unexpected user counts and license costs. You probably have questions on how this new licensing approach works and how to benefit from it. Most importantly, you likely have budget constraints and want to save money where possible. Don’t worry, we can help with all of this!
We’ll show you how to fix common misconfigurations that cause higher-than-expected user counts, and how to identify accounts which you can deactivate to save money. There are also frequent patterns that can cause unnecessary cost, like using a person document instead of a mail-in for shared mailboxes. We’ll provide examples and solutions for those as well. And naturally we’ll explain the new licensing model.
Join HCL Ambassador Marc Thomas in this webinar with a special guest appearance from Franz Walder. It will give you the tools and know-how to stay on top of what is going on with Domino licensing. You will be able lower your cost through an optimized configuration and keep it low going forward.
These topics will be covered
- Reducing license cost by finding and fixing misconfigurations and superfluous accounts
- How do CCB and CCX licenses really work?
- Understanding the DLAU tool and how to best utilize it
- Tips for common problem areas, like team mailboxes, functional/test users, etc
- Practical examples and best practices to implement right away
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
27. What makes LiMo especially attractive for
Mozilla is that it’s all about code,
where previous efforts around mobile Linux have been
more focused on developing standards.
- Jay Sullivan, Mozilla
39. Content
Applications
User Interface
LiMo Platform Middleware
Limited scope for competitive
differentiation but high strategic
Operating System importance due to potential to be
used as a control point within a
wider business agenda and very high
switching costs
40. Content
Applications
User Interface
User Interface As selected by the handset maker /
network operator
LiMo Platform Middleware
Limited scope for competitive
differentiation but high strategic
Operating System importance due to potential to be
used as a control point within a
wider business agenda and very high
switching costs
41. Content
Applications Applications
As selected by the mobile consumer
User Interface
User Interface As selected by the handset maker /
network operator
LiMo Platform Middleware
Limited scope for competitive
differentiation but high strategic
Operating System importance due to potential to be
used as a control point within a
wider business agenda and very high
switching costs
42. Content Content
As selected by the mobile consumer
Applications Applications
As selected by the mobile consumer
User Interface
User Interface As selected by the handset maker /
network operator
LiMo Platform Middleware
Limited scope for competitive
differentiation but high strategic
Operating System importance due to potential to be
used as a control point within a
wider business agenda and very high
switching costs
69. Common Non-Common
Foundation
Member
Public License
Projects
(Common Capable)
70. Common Non-Common
Foundation
Member
Public License
Projects
(Common Capable)
Open Source
Open Source License
Projects
71. Common Non-Common
Foundation
Member
Public License
Projects
(Common Capable)
Open Source
Open Source License
Projects
72. Common Non-Common
Foundation Foundation
Member Member
Public License Public License
Projects Projects
(Common Capable) (Non-Common Capable)
Open Source
Open Source License
Projects
73. Common Non-Common
Foundation Foundation
Member Member
Public License Public License
Projects Projects
(Common Capable) (Non-Common Capable)
Open Source Member
Open Source License Proprietary License
Projects Projects
74. Common Non-Common
Foundation Foundation
Member Member
Public License Public License
Projects Projects
(Common Capable) (Non-Common Capable)
Open Source Member
Open Source License Proprietary License
Projects Projects
75. Common Non-Common
Foundation Foundation
Member Member
Public License Public License
Projects Projects
(Common Capable) (Non-Common Capable)
Open Source Member
Open Source License Proprietary License
Projects Projects
76. Common Modules
Framework
Core, hardware independent and geographic-market
independent functionality
for a certain type or class of Modules
Non-Common Modules
Plugin Plugin Plugin
Proprietary license Open Source license FPL
77. Common Modules
Framework
Core, hardware independent and geographic-market
independent functionality
for a certain type or class of Modules
Non-Common Modules
Plugin Plugin Plugin
Proprietary license Open Source license FPL
86. Common Non-Common
Foundation Foundation
Public License Public License
(Common Capable) (Non-Common Capable)
Open Source License Proprietary License
87. Common Non-Common
Foundation Foundation
Public License Public License
(Common Capable) (Non-Common Capable)
Open Source License Proprietary License
Full patent non-assert
including commercial
distribution to non-members
88. Common Non-Common
Foundation Foundation
Public License Public License
(Common Capable) (Non-Common Capable)
Open Source License Proprietary License
Full patent non-assert Patent non-assert
including commercial limited to distribution
distribution to non-members between members
89. Common Non-Common
Foundation Foundation
Public License Public License
(Common Capable) (Non-Common Capable)
Open Source License Proprietary License
Full patent non-assert Patent non-assert
including commercial limited to distribution
distribution to non-members between members
Industry Standards and pooled patents are excluded from the scope of the IPR policy
90. Common Non-Common
Foundation Foundation
Public License Public License
(Common Capable) (Non-Common Capable)
Open Source License Proprietary License
Full patent non-assert Patent non-assert
including commercial limited to distribution
distribution to non-members between members
Industry Standards and pooled patents are excluded from the scope of the IPR policy
Combinations are excluded from the scope of the IPR policy
118. As the development community looks at
how best to bring new applications to the marketplace,
they should check out LiMo and Linux Mobile first.
- Kyle Malady, Vice President of Network for Verizon
119. As the development community looks at
how best to bring new applications to the marketplace,
they should check out LiMo and Linux Mobile first.
- Kyle Malady, Vice President of Network for Verizon
131. Conclusion
• An industry-driven initiative
• An innovative IPR model tailored to foster
collaboration at the code level
• Based on Open Source principles
Good afternoon, thank you for inviting me here to speak today about the LiMo Foundation.
My name is Andrew Savory, I’m the Open Source Manager for the LiMo Foundation, I joined at the start of October.
I hope I can give you an insight into what LiMo is, and why it’s essential to the future of mobile.
You might ask what does an Open Source Manager do:
- educate our members on the benefits of open source
- keep track of our open source usage, and of other relevent open source projects (e.g. Gnome Mobile)
- ensure our compliance with open source licenses
- encourage our members to give back to open source to get the virtuous cycle of OS usage
- talk to the world about LiMo, the future of mobile, and Open Source.
I’d like to start by looking at the mobile world a couple of years ago, to answer the question:
Why does the world need LiMo?
Two years is a long time ago in this industry: for example it was before iPhone (announced MacWorld Jan 2007), and before Android (announced Nov 2007).
References:
http://www.techcrunch.com/2007/01/09/macworld-announcements-real-time/
http://gigaom.com/2007/11/05/google-launches-mobile-phone-platform-android/
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
For many years there has been extensive mobile platform proliferation.
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
But it’s more complicated than just dozens of platforms with dozens of versions.
There are also many different network operators. Each operator usually insists on their own customisation requirements for phones on their networks.
This allows them to tie products into specific features of their network, or to help them manage the support of handsets deployed on their network.
So you don’t just have to test across a dozen platforms - you also have to test across a dozen networks too.
Developing for every platform and for every operator quickyl leads to increasingly unmanageable complexity.
Suddenly from 7 operating systems and 7 operators you have nearly 50 targets to manage.
Obviously this is not sustainable for anyone - neither operators, manufacturers, nor developers.
Wouldn’t it be great if all the handset manufacturers, network operators and software developers got together to work on reducing this fragmentation?
If we had convergence around a few common platforms, we would significantly reduce the burden of development, maintenance and support.
That’s exactly what happened.
In 2007, a number of mobile industry leaders got together try to solve this problem
Motorola, NEC, NTT DoCoMo, Panasonic, Samsung, Vodafone and Orange founded LiMo, with the idea of developing a mobile platform drawing on the expertise and experience of members and pooling resources around a common set of code.
The initial founders were soon joined by more core members, including the most prominent names in the mobile industry, ranging from hardware manufacturers, software vendors to network operators.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
So, what exactly is LiMo? I briefly outlined a common goal, to reduce diversity, but now it’s time to look in more detail at what the foundation is.
Firstly, what LiMo is not:
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
Firstly, what LiMo is not:
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
Firstly, what LiMo is not:
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
Firstly, what LiMo is not:
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
And that is what LiMo is.
In just two years it has grown to be a safe haven for collaborative mobile development, sharing best practice and experience to provide a common mobile platform.
Beyond that, what are the aims and aspirations of LiMo, the goals, the roadmap for the future?
So, LiMo’s goals.
Other than solving the problem of platform proliferation, what else is LiMo about?
I’d like to outline those goals now for you.
Goal #1: provide a competitive platform
This is not just about collaboration to reduce fragmentation, it’s about taking the experience of our members and combining it with key open source components to create a truly competitive platform:
“middleware best of breed”
How do we do this?
We make it a competitive platform by going beyond specifications.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
We make it a competitive platform by going beyond specifications.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
We make it a competitive platform by going beyond specifications.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
We make it a competitive platform by going beyond specifications.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
LiMo is also about proven technology.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
based on published roadmap
FIXME References to published roadmap?
http://www.limofoundation.org/images/stories/pdf/limo%20foundation%20overview%20-%20may08-ext.pdf
LiMo is about Copyleft.
Fixes and modifications within the platform are shared in order to avoid fragmentation.
Very strong copyleft at the platform and API level, with an obligation of each Member to contribute back just before the commercialisation.
We are not open source: whilst we would love to be completely open source, pragmatism dictates that to get the widest engagement and contribution of existing code, a hybrid model is required. We do however have a policy of using open source where suitable and of actively contributing back to open source projects and being good citizens within the open source communities.
LiMo is also about the commercial success of our members.
We expect that commercial innovations on top of the platform may be retained.
Because LiMo is not a complete stack but instead is focussed on middleware, it does not specify for example the user interface.
This provides a solid platform upon which members can build differentiation.
Which takes us to goal number 2.
Goal #2 is to be free from business model conflicts.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
Goal #2 is to be free from business model conflicts.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
Goal #2 is to be free from business model conflicts.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
Goal #2 is to be free from business model conflicts.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Let’s look at LiMo graphically.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
Goal #3 of LiMo is Open Governance.
A successful community requires a clear set of rules and boundaries to work within, and so we have an open, inclusive and published governance structure.
We have shared leadership and shared decision making: no one dictator to determine the route the platform should take. Discussion is based on technical merit and experience.
We also aim to provide a safe and empowering IP safe harbour: everyone can contribute without fear of reprisals through patent lawsuits etc.
How does LiMo governance compare with other mobile initiatives?
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
How does LiMo governance compare with other mobile initiatives?
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
How does LiMo governance compare with other mobile initiatives?
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
How does LiMo governance compare with other mobile initiatives?
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
How does LiMo governance compare with other mobile initiatives?
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
collectively developed platform
FIXME redo graphic
As part of our open governance, we are an open organisation.
Any company or person can join LiMo, as a Core or an Associate member.
Any Member can contribute to the platform, have access to minutes of all meetings, and participate in our various elections.
As part of our open governance, we provide open access to source code.
All our source code contributed under the FPL is available to any company agreeing with the terms of our IP safe harbour.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Architectural and technical decisions are made collectively according to the process defined in our bylaws.
I’d like to explain the process to you now.
This diagram exemplifies the contribution process for our members.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
This diagram exemplifies the contribution process for our members.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
This diagram exemplifies the contribution process for our members.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
This diagram exemplifies the contribution process for our members.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
This diagram exemplifies the contribution process for our members.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
Another goal of LiMo is to adopt a collaborative approach to development - inclusive of all licensing models.
Finding the right licensing model is a balancing act, managing the commercial concerns of traditionally very closed businesses with the need for collaborative development.
As previously mentioned when talking about Copyleft, LiMo is not completely open source.
But we do:
- use a lot of open source software
- with strong interaction with open source communities
- define a development and licensing model based on open source best practise
- “collaborative source development”
- copyleft license within the foundation
- inclusive of other licensing models above the level of commodity
I’d like to explain how this works now.
Finding the right licensing model is a balancing act, managing the commercial concerns of traditionally very closed businesses with the need for collaborative development.
As previously mentioned when talking about Copyleft, LiMo is not completely open source.
But we do:
- use a lot of open source software
- with strong interaction with open source communities
- define a development and licensing model based on open source best practise
- “collaborative source development”
- copyleft license within the foundation
- inclusive of other licensing models above the level of commodity
I’d like to explain how this works now.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
There are two sets of code within LiMo:
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
The intention of common modules is to contain core, hardware-independent and geographic-market independent functionality.
Non-common modules are typically platform-specific or geographic-specific.
Depending on market selection, a plugin may enrich the functionality of a Framework and become Common Code.
Another Goal of Limo: an IP Safe Harbour.
LiMo provides a balanced but strong IP safe harbour for development, intended to foster collaboration and innovation whilst respecting the rights of members.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Foster collaboration and sharing of source code: any member can inspect freely the core of the platform, can share source code, without any risk of being sued for patent infringement from another member
Build a common and shared software platform offered to all members at a competitive price (mutualisation of the costs through membership fees rather than royalties)
So any member can create their own innovative products on the top of the platform without losing control of their innovation
I’d like to show you how the various IPR and license policies are managed now.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
What’s the state of play: where is LiMo since the start in 2007?
Our 4th Goal: to have strong industry backing.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Our 4th Goal: to have strong industry backing.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Our 4th Goal: to have strong industry backing.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Our 4th Goal: to have strong industry backing.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Our 4th Goal: to have strong industry backing.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
We have already had the first release - this is a reference release of the API
accompanied by those 23 handsets on the market with type 1 compliance.
http://www.limofoundation.org/en/technical-documents.html
We have already had the first release - this is a reference release of the API
accompanied by those 23 handsets on the market with type 1 compliance.
http://www.limofoundation.org/en/technical-documents.html
This diagram illustrates the scope of the LiMo platform.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
23 type 1 handsets available today, from Motorola, NEC, Panasonic, Aplix, LG, Purple Labs
ref: http://www.limofoundation.org/en/limo-handsets.html
SDKs will be available.
Members will be releasing SDKs that will allow you to create applications on their handsets by Mobile World Congress in March 2009.
Later in 2009 we anticipate SDKs that allow a higher degree of application portability.
SDKs will be available for building applications natively (GTK, Linux, C)
Also SDKs for Web and Java.
Reference:
http://www.engadgetmobile.com/2008/03/31/limo-platform-release-1-gets-loosed-r2-to-come-later-this-year/
Challenges for developers:
- differentiation means there’s not one common interface across all handsets
- but only apple guarantee this, and they have small market share
- even android may be fragmented
- requires knowledge of linux software stack
- but existing desktop skills transferable
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
There are lots of other platforms out there
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo is solidly grounded in Open Source principles
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
leverages existing standards and open source projects to accelerate the development and acceptance of the Platform.
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
What unusual technologies can be found in LiMo phones?
- none
It’s the linux desktop software stack
Platforms, SDKs are work in progress
Full development environments will be available early 2009
Industry-driven initiative: representing most of the players of the mobile industry, broad support from all sectors
Innovate IPR model: collaborative source development approach. Inclusive of all licensing models.
Open Source principles: code as a commodity with open access to source and with patent / copyright protection for developers.