I know this is somewhat impudent, but I need any help I can get ATM and therefore I try whatever I can.

I offered to do an internal presentation about Maemo (high-level overview of the project and ecosystem, nothing technical) in my company in May/June. They now approached me to do it this week on Friday, but asked that I also include Android and OpenMoko, extending the topic to a comparison of the three. I accepted because otherwise the whole thing would have been cancelled.

I feel reasonably safe talking about Mameo and OpenMoko. Android is what I cannot get 100% reliable information about. I'd need help here, and it would be great if this help would be given as links to sources on the web.

I gathered some technical information already, history of the project etc.

What I cannot confirm (because most material I find online tells what Android is, not what it isn't) is some conceptual differences I have read/heard somewhere.

So, are the following statements true and where could I find more about the claims:

Android is a universe of its own. While Maemo uses established desktop technology (X11, DBUS, GTK+,...) and makes it reasonably easy to port existing applications, Android runs applications in a Java-like virtual machine and requires authors to re-write their applications from scratch.

Android does use "open source" as a development model, but from and end users perspective, an Android based phone is as closed as Symbian or jPhone. One can download and install applications, but it's not possible (without hacks) to replace core components with modified versions. Therefore a user cannot easily replace or completely delete code that ties the phone to Google services. (This is possible because of the Apache license that allows re-distribution of the originally open code as closed binary.)
Manufacturers say this restriction in Android phones is necessary because a completely open phone could potentially ruin the whole infrastructure of carriers, technically and business-wise.
Maemo, OTOH, offers exactly this possibility for the end user for each and every open component. (Closed binaries, of course, are an exception.)

Android is backed by a number of manufacturers and could continue as an OS even if Google pulled the plug at some point. Maemo (if defined as Maemo, not as community-based Maemo variants) depends on Nokia and Nokia alone. If Nokia backs out, it's dead. (See 770 and now OS2008.)


Anything else you would throw in as "difference between Maemo and Android"? (Or maybe between Android and OpenMoko)? It's more about conceptual differences, with emphasis on freedom and openness. Details about how to write code, IDEs, hardware,... are less relevant.

Thanks for any input.

I am not an expert, but from what I have read..

1) Yes
2) Correct, it's not true open-source for the end-user. Google has actually tried to block attempts to bypass their restrictions by patching holes and what not with firmware updates.
3) I don't know. There is a alliance and backing for Android but if Google pulled out I'm not sure if the manufacturers would start bickering or what not.

4) I have no idea, sorry.

On point 2: Google has only issued patches because those jail-break methods were actual security problems. For example, the initial one was that anything you type would be also executed as a command. So if you sent an sms message to someone that had "rm -rf /" then it would be a minor disaster for your phone. But as far as I know, if you have a T-mobile G1 with a newer firmware, you can still downgrade to the earlier (buggy) version and still use those exploits.
But there is no reason to expect that this policy will continue with future devices -- it is up to the handset manufacture to decide if it wants to allow downgrading of firmware.

Another point, is that currently you can install any user app from any source (it doesn't have to be signed), but it is also possible that future handsets (or handsets from other carriers) could lock that down also, just like they lock down current java phones. But if the bulk of Android phones are open (at least from the app side), then it is unlikely that carriers would be able to get away with further locking down their own handsets without customers rebelling. The only reason they get away with that now is because almost all other carrier's handsets do the same thing.

But keep in mind, that any lock downs (either at the OS or app level) are decisions by the individual carriers (not by the phone manufacture or OS vendor). So if you get your handset from a third party (like the developer version of the G1 from Google), then you won't have any lock down.

That's exactly one of the points I keep getting conflicting information about.

So if Android is developed as an open source project (but under an ugly license that permits non-free distribution)... and the end user gets a phone that's de facto closed... Who is the bad guy in the middle?

Some people tell me it's HTC, the manufacturer. Following this theory HTC takes the free code from the Android projects, adds some stuff of their own, re-packages it and makes sure nobody can replace the OS with homemade variations of Android, then finally sells it to T-Mobile. T-Mobile sells it to end users.
According to this, there's no way to get "free" G1 phones, because you either buy a development version (that doesn't work in real networks with real SIM cards), or you buy a retail version that's locked.

Other people say HTC is just the hardware manufacturer and T-Mobile is responsible for the re-packaging and the tivoization. If an end user would buy a phone directly from HTC, it'd be unlocked, would operate normally with every SIM-card and "Just Work". It would only be more expensive. Only those who buy the T-Mobile version get the locked, tivoized phone... but they get it cheaper.

Which version is true?

"Android is a universe of its own. While Maemo uses established desktop technology (X11, DBUS, GTK+,...) and makes it reasonably easy to port existing applications, Android runs applications in a Java-like virtual machine and requires authors to re-write their applications from scratch."

Exactly. Maemo is desktop linux scaled down a bit for use with cramped resolutions and low powered hardware. Android is a whole new sandbox (a very nice one) that requires use of the android API. That being said the android API does wrap quite a few of the same open source libraries maemo and other linux distros use like libpng, openssl and webkit but as you mention can only be used through dalvik. Android isn't really linux and definitely isn't unix. It doesn't include posix-compatible libraries and won't allow users to run programs not written for the dalvik vm.

You're also right about the openness of android being from a development and less from a use standpoint. The andriod OS and API itself are free and open but there is nothing stopping someone from modifying android for a really entry level phone, not including several important libraries and making it impossible to install a large portion of the app market (or they could not include the app market at all). Users would be unable to add the missing pieces back.

I'm not as familiar with openmoko but I believe their approach is very similar to that of maemo except more open, namely leverage existing open source apps and libraries to make a platform (in this case for a smartphone). Nokia is fine with a few key libraries like opengl being closed source

While I don't know the internal workings of HTC or T-Mobile living only a few blocks from RIM headquaters here in Waterloo offers certain glimpses into the industry. Knowing lots of people who work there I can tell you the lock down with blackberries comes from both RIM and carriers, different locks coming from different business needs. The new storm touch screen device for instance doesn't come with wi-fi because verizon didn't want it. They want to ensure people have to pay data and call rates and can't use free wifi for browsing or voip calls. The fact that you can't install an OS not made by RIM is a RIM decision.

I think assigning blame for the locks to a single source would be overly simplifying the situation. The final product is a joint effort from google, t-mobile and htc and I think we can see certain areas of fault that belong to each party. Google won't allow multi-touch because of patent fears even though the hardware supports it and they only offer the gmail and app market for the G1, open source builds don't include those features. HTC doesn't offer source for the radio and opengl drivers among other things, likely due to patent and copyright issues from the real makers of the drivers along with fears of passing FCC inspections (a problem facing fully open source wi-fi drivers). Finally t-mobile wants customers to pay monthly fees for more then just the contract period which is why we get SIM locks.

EDIT:

Almost forgot with andriod being an open platform there are are sorts of different restrictions we can talk about.
First is the restriction to only run applications in dalvik. Since the OS is open someone could come along and allow native applications or port another language to the vm the same way jython or scala run on the jvm
Second is the restriction to the android standard library. Again no reason someone couldn't write a different one
Third is the open source status of the drivers and homebrew. Each device maker has to make their own decisions about what level of access they will allow people to change the underlying libraries and drivers. With the G1 it's middle of the road, some closed source only bits, mostly open code and there is an unlocked development version available. Other phones may be more or less open.
Finally is the amount of carrier lock down. Will the phone accept any SIM? Will it allow you to install things from the app market? Each manufacturer/carrier can decide

Although in my little world Android is Linux (because the term Linux refers to the kernel and nothing else but the kernel), I like your statement. I think it makes a nice catchphrase I'll use. It not being POSIX-compatible will mean nothing to the audience that awaits me, but it sounds great and they'll think I'm an expert.
OpenMoko will only play a marginal role in my presentation... Maemo is what I love, Android is what they know, and OpenMoko will have the role of "and there's also... but it isn't relevant to the market. Yet".
(Which is bad, really. I loved OpenMoko when I first read about it. Their vision was so stunning then: truly open, hardware and software, no compromise, what can't be done with open drivers won't be done at all... But then they simply lost track. Moving from GTK to Qt for no apparent reason and with no communication whatsoever alienated a lot of their followers, and when they turned around again and made it a playground for EFL, I think that was the time when they lost it. Nobody knows right now where they're heading. Maybe they'll re-appear again on somebody's horizon. It would be nice.)

It's true linux is only the kernel but google did make a number of changes that won't be ported to the mainline tree that are necessary for android. Their low memory killer and message passing interface are 2 I can remember off the top of my head but I know their are more. There are OMAP and ARM branches of the kernel but their goal is inclusion in the mainline eventually. Google has no need or desire for their patches to be included and in fact as they are so android specific inclusion in mainline would be silly. The patches are open source but are against a specific kernel version so to use the newest sources you may have to port the patches. None of this strictly makes android not linux but the fact google has made it clear android is not linux makes it easier to think of android as an embedded OS that uses the linux kernel rather then a linux distro

I didn't know that, either. Thank you! I'll really be an expert by the end of this week. This forum is great!
My remark about the term "Linux" didn't make any sense in the context of this thread; it was only to point out (yet again) that I'm on RMS's side and prefer "GNU/Linux" (when talking of a distribution, a desktop system such as Maemo) over "Linux" (which I use only when I refer to the actual kernel).
This is usually enough to start a flame war and make moderators close a thread.
Thank god it didn't this time. Please hold back the flames until Friday, I still need your comments!

While rms is a little overly bombastic in making his point his desire for credit for the userland tools isn't unrealistic. I just hope other upstream packagers get in on the action or we'll have to call it GNOME/X11/GNU/Linux/Whatever else you are running. But since android doesn't use the GNU tools (beyond gcc for compilation of the native portions like the kernel and C library) I guess the rms name would be android/linux