13 ms·

Anybody else a bit worried that this basically comes down to the good old "embrace extend extinguish" ? It's slightly different in that the "embrace" step was t

by RyanZAG 13y ago

Anybody else a bit worried that this basically comes down to the good old "embrace extend extinguish" ? It's slightly different in that the "embrace" step was the purchase of Danger and open sourcing of the base AOSP - but the "extend" bit is pretty clearly in full effect here.

Zigurd 13y ago
No. Or not yet. Google is very consistent in their treatment of AOSP. That's not to say it's a bed of roses. AOSP was and maybe still is under-resourced. It hasn't always had stable hardware targets. That's not a good way to treat a resource that is instrumental to creating a community of developers that know how to keep Android updated on a wide range of SoC platforms. Google makes no attempt to create an independent AOSP governance and pool of maintainer resources. I can go on. How much time do you have? But the bottom line is AOSP has been remarkably free of shenanigans. Very unlike some other in-house but nominally open source projects I can think of.
- eterm 13y ago
  That's not the point that GP is making. The point is that AOSP has been extended through google play services in the same way MS used to extend open protocols. It has used that to bring up a lot of people who associate android more closely with the google play services ecosystem than the AOSP ecosystem. If google said "we're ditching AOSP but we're making a new closed source OS with google play services and a compatible API layer" then really would people move to AOSP or the new google OS? The potential for "extinguish" is there. Had this all happened the other way around or had AOSP been around and MS had embraced it and extended it in this manner then I think people would be acting differently.
  - fidotron 13y ago
    That new OS is Chrome OS. Notice that the Chrome OS device manufacturers don't get to rebrand it, modify it in any way, or control delivery of the updates. It is far more closed than Android ever was. Google are applying their lessons from Android to Chrome OS.
    - cromwellian 13y ago
      That's a rather bizarre way of putting it. Another way of looking at it is that Chromium is completely open source and anyone who wants to build a Web-browser based netbook could do so, they just couldn't call it ChromeBook. Since all the apps are web apps, everything would continue to work as normal. There's no "if you don't agree to all of this, you can't use the GMail Web App or Google Maps on your device"
      - fidotron 13y ago
        Can you access the Chrome API from apps not delivered through the Chrome Store? Chrome OS is closer in spirit to iOS than it is to Android.
        cromwellian 13y ago
        AFAIK, you can install apps and extensions without going through the Chrome store, and if you have the source, you can certainly hack it to use an alternate store host. The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend. I don't think forking ChromeOS is as difficult as forking Android.
        fidotron 13y ago
        That's like arguing that iOS is open since you could all become developers and distribute the ObjC. Not all Chrome apps are web apps ( http://developer.chrome.com/apps/about_apps.html http://developer.chrome.com/apps/about_apps.html ) and you can't distribute those packages trivially to end users, so the whole distinction is almost identical to the iOS situation, by design. Google's Chrome group have a serious case of Apple envy, and this is how it manifests itself. The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
  - Zigurd 13y ago
    That can only be partly fixed. AOSP could be improved by creating a parallel out-of-house project. But, maybe, CyanogenMod and other downstream distros serve that purpose. I'm not up to the minute about what kind of job Google is doing accepting fixes and improvements from downstream, but I'd guess that could stand to improve. I don't see a fix for parts of the open Android app layer migrating into dependence on the Google ecosystem, apart from allowing downstream distros to maintain and/or replace the open versions. If Google wants to integrate Photos with G+ what are they going to do about that that would be consistent with their "All of our ecosystem or none of it" approach to licensing?
- fidotron 13y ago
  Precisely. I think the only two real sticking points are what was mentioned about this agreement having to be a company wide deal, and also that stuff against forking the SDK giving Google far too big a veto over proceedings. Ideally to fix this the OHA should become independent of Google, but that would rely on the other members being remotely competent.
pjmlp 13y ago
I imagine someday people will miss Microsoft while realizing there are others worse than them.

by RyanZAG 13y ago

Zigurd 13y ago

No. Or not yet. Google is very consistent in their treatment of AOSP. That's not to say it's a bed of roses. AOSP was and maybe still is under-resourced. It hasn't always had stable hardware targets. That's not a good way to treat a resource that is instrumental to creating a community of developers that know how to keep Android updated on a wide range of SoC platforms. Google makes no attempt to create an independent AOSP governance and pool of maintainer resources. I can go on. How much time do you have? But the bottom line is AOSP has been remarkably free of shenanigans. Very unlike some other in-house but nominally open source projects I can think of.

eterm 13y ago
That's not the point that GP is making. The point is that AOSP has been extended through google play services in the same way MS used to extend open protocols. It has used that to bring up a lot of people who associate android more closely with the google play services ecosystem than the AOSP ecosystem. If google said "we're ditching AOSP but we're making a new closed source OS with google play services and a compatible API layer" then really would people move to AOSP or the new google OS? The potential for "extinguish" is there. Had this all happened the other way around or had AOSP been around and MS had embraced it and extended it in this manner then I think people would be acting differently.
- fidotron 13y ago
  That new OS is Chrome OS. Notice that the Chrome OS device manufacturers don't get to rebrand it, modify it in any way, or control delivery of the updates. It is far more closed than Android ever was. Google are applying their lessons from Android to Chrome OS.
  - cromwellian 13y ago
    That's a rather bizarre way of putting it. Another way of looking at it is that Chromium is completely open source and anyone who wants to build a Web-browser based netbook could do so, they just couldn't call it ChromeBook. Since all the apps are web apps, everything would continue to work as normal. There's no "if you don't agree to all of this, you can't use the GMail Web App or Google Maps on your device"
    - fidotron 13y ago
      Can you access the Chrome API from apps not delivered through the Chrome Store? Chrome OS is closer in spirit to iOS than it is to Android.
      - cromwellian 13y ago
        AFAIK, you can install apps and extensions without going through the Chrome store, and if you have the source, you can certainly hack it to use an alternate store host. The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend. I don't think forking ChromeOS is as difficult as forking Android.
        fidotron 13y ago
        That's like arguing that iOS is open since you could all become developers and distribute the ObjC. Not all Chrome apps are web apps ( http://developer.chrome.com/apps/about_apps.html http://developer.chrome.com/apps/about_apps.html ) and you can't distribute those packages trivially to end users, so the whole distinction is almost identical to the iOS situation, by design. Google's Chrome group have a serious case of Apple envy, and this is how it manifests itself. The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
- Zigurd 13y ago
  That can only be partly fixed. AOSP could be improved by creating a parallel out-of-house project. But, maybe, CyanogenMod and other downstream distros serve that purpose. I'm not up to the minute about what kind of job Google is doing accepting fixes and improvements from downstream, but I'd guess that could stand to improve. I don't see a fix for parts of the open Android app layer migrating into dependence on the Google ecosystem, apart from allowing downstream distros to maintain and/or replace the open versions. If Google wants to integrate Photos with G+ what are they going to do about that that would be consistent with their "All of our ecosystem or none of it" approach to licensing?
fidotron 13y ago
Precisely. I think the only two real sticking points are what was mentioned about this agreement having to be a company wide deal, and also that stuff against forking the SDK giving Google far too big a veto over proceedings. Ideally to fix this the OHA should become independent of Google, but that would rely on the other members being remotely competent.

pjmlp 13y ago

I imagine someday people will miss Microsoft while realizing there are others worse than them.