Quim suggested I move this discussion here from meego-community, so here goes --- I'll adapt it a bit based on what I learned in the community thread, so it won't be a *complete* repeat for those on both lists.
There seems to be a fair bit of buzz right now (http://www.engadget.com/2010/03/05/entelligence-will-android-fragmentation-destroy-the-platform/ and http://mediamemo.allthingsd.com/20100305/an-apple-app-star-explains-why-he-wont-work-with-android/ for example) around how much fragmentation is damaging the android community. I'd like to explore what we can do to avoid the same problems with MeeGo. >From the discussion on m-community, it seems like the QT Mobility APIs will go a long way towards ensuring that all common device functionality is accessible through the same API - this avoids at least one aspect of fragmentation (e.g. having to use a nokia api for orientation on phone A, and an LG api for orientation on phone B). The part of the android problem I'd like to avoid is this - a lot of the new devices that are being released by small asian companies are running Android 1.6 or even 1.5 - and they don't all have a clear pathway to move to the latest version of Android. Is there anything we can do to increase the likelihood that if someone buys a cheap ARM tablet from China with MeeGo on it, that they can easily upgrade to a newer community supported version of MeeGo? Are there constraints that can be put upon closed source binary drivers for instance, that would make it easier to be able to move to a newer version of MeeGo without a vendor's support? If all MeeGo users have a relatively simple path to move to the most recent MeeGo version - it could greatly reduce the number of platforms app developers need to develop and test against. Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
