I've read it, but my point is none of this got more proprietary in 4.4, which is the line I quoted and refuted. Cloud services have always been proprietary because it costs money to run them.
If you want to complain that not everything in Android is completely open source, including the cloud services part, that's a different issue. But many of Peter Bright's complaints are just plain wrong:
> The non-Gmail e-mail client has a poor reputation in this regard.
> Right; you can use forks of some of the apps because Google hasn't done a very good job of maintaining the AOSP ones. Which is... what I said.
Yeah, and people are forking Linux because it isn't well maintained. Oh, no wait, people are forking Linux because that's one of the main ideas behind open source software: you can fork it and make it do what you want.
> Sure, except neither of those fulfils the contract of the API. They might be good enough, but if an app has a button that says "share this on G+" and it ends up sharing on Facebook instead, that'd be a little weird, don't you think?
This isn't how the sharing API works at all, and he's clearly never used it. All you do is add a ShareActionProvider to your ActionBar and it works with anything that supports the sharing intent. You don't say "I can share with G+, or Facebook, or..." like he seems to think. (http://developer.android.com/training/sharing/shareaction.ht...)
> What on earth are you talking about? You're railing against strawmen.
No, this isn't a strawman, she's refuting exactly what he said. The Android platform has standards and you have to stick to them, just like any other platform you want to base yourself on if you want to be compatible. The APIs happen to be the standard for Android. Without them there would be no compatibility between various Android distributions. You can, of course, always add additional APIs on top, which is exactly what Samsung, Motorola, etc. do with their SDK add-ons. Really though, you can't complain that "[a]ny platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose" because "[v]arious aspects of how Android is used are determined by the underlying APIs", and then complain they don't provide an API for other, more proprietary things like an IAP system ("Why not ship an IAP system that has code that defaults to using Google's services on the back-end, but could be swapped out without breaking apps"). This point is total insanity by Peter.
> Read Ben Evans' piece on how Microsoft should relegate Android to being nothing more than a stack of debugged device drivers. Sure, you might take bits of Google's userland too.
This is exactly what FirefoxOS and Ubuntu Touch did to bootstrap. They both took the Android kernel, the input system, etc. So clearly it works, and I think is a much more interesting use of the platform than just taking the whole thing and slapping some new paint on it; why would I use that over stock Android?
If you want to complain that not everything in Android is completely open source, including the cloud services part, that's a different issue. But many of Peter Bright's complaints are just plain wrong:
> The non-Gmail e-mail client has a poor reputation in this regard.
Both it and GMail are based on the same code base, UnifiedEmail, which is maintained: https://android.googlesource.com/platform/packages/apps/Unif...
> Right; you can use forks of some of the apps because Google hasn't done a very good job of maintaining the AOSP ones. Which is... what I said.
Yeah, and people are forking Linux because it isn't well maintained. Oh, no wait, people are forking Linux because that's one of the main ideas behind open source software: you can fork it and make it do what you want.
> Sure, except neither of those fulfils the contract of the API. They might be good enough, but if an app has a button that says "share this on G+" and it ends up sharing on Facebook instead, that'd be a little weird, don't you think?
This isn't how the sharing API works at all, and he's clearly never used it. All you do is add a ShareActionProvider to your ActionBar and it works with anything that supports the sharing intent. You don't say "I can share with G+, or Facebook, or..." like he seems to think. (http://developer.android.com/training/sharing/shareaction.ht...)
> What on earth are you talking about? You're railing against strawmen.
No, this isn't a strawman, she's refuting exactly what he said. The Android platform has standards and you have to stick to them, just like any other platform you want to base yourself on if you want to be compatible. The APIs happen to be the standard for Android. Without them there would be no compatibility between various Android distributions. You can, of course, always add additional APIs on top, which is exactly what Samsung, Motorola, etc. do with their SDK add-ons. Really though, you can't complain that "[a]ny platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose" because "[v]arious aspects of how Android is used are determined by the underlying APIs", and then complain they don't provide an API for other, more proprietary things like an IAP system ("Why not ship an IAP system that has code that defaults to using Google's services on the back-end, but could be swapped out without breaking apps"). This point is total insanity by Peter.
> Read Ben Evans' piece on how Microsoft should relegate Android to being nothing more than a stack of debugged device drivers. Sure, you might take bits of Google's userland too.
This is exactly what FirefoxOS and Ubuntu Touch did to bootstrap. They both took the Android kernel, the input system, etc. So clearly it works, and I think is a much more interesting use of the platform than just taking the whole thing and slapping some new paint on it; why would I use that over stock Android?