[MeeGo-dev] Avoiding Fragmentation
bishop.robinson at gmail.com
Thu Mar 11 04:28:33 CST 2010
On Wed, Mar 10, 2010 at 11:45 PM, Warren Baird
<wjbaird at alumni.uwaterloo.ca> wrote:
> There seems to be a fair bit of buzz right now...
> 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.
A noble goal.
> [many new devices] are being released by small asian companies
> ... and they don't all have a clear [upgrade path] to the latest version
> of Android.
In several cases consumers are simply waiting for new builds to be
released. Some people root their phone and install newer releases of
Android, for example the CyanogenMod "distro".
> [what can we] 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?
I'm probably preaching to the choir a bit here, but the obvious first
step is to make sure that community-created builds can even run on the
device. This means:
The owner of a device needs the power to install community-created
builds of the Meego OS. If the hardware cryptographically verifies the
OS, the owner needs access to the keys necessary to sign builds.
> 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?
Sure. How about "No closed-source binary drivers allowed" ?
All wishful thinking/joking aside, the driver situation will be the
same for Meego as it always has been for the Linux kernel. Without
checked-in source, the driver code will be an opaque blob that works
with today's kernel and might not work with tomorrow's kernel.
Given that all of the core Meego code will be available under a FOSS
license, any "small asian company" can hoover the whole thing up, add
the necessary drivers for their hardware, and then release the device.
If the company doesn't follow the instructions of the Meego Project
then they might not be allowed to use the Meego name, but they could
use pretty much everything else. As the Meego project seems to have an
aversion to the GPLv3, there's no guarantee that owners would even be
able to run their own builds on the hardware.
The Meego name is a special case. The Meego community could certainly
put conditions on the use of the Meego name and logo. One possibility
would be to reserve "official status" and use of the Meego name for
hardware that runs both vendor-supplied and community-created builds
> 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.
A reduced testing load would be very helpful, however just because
users _may_ upgrade to a newer version of Meego does not mean that
they will. The easier the mechanism to update the OS, the more likely
that users will actually perform the upgrade.
More information about the MeeGo-dev