I'm going to freely admit, this is a biased comment, which probably doesn't belong here, but I think it has to be said.
This isn't the first time that Ars Technica, an otherwise reasonable source of information, has published an utter crap article written by Peter Bright.
If Ars wants to maintain any shred of credibility (and a technically intelligent readership) in the future, they need to can this author, or label all of his articles as "op-ed", because that's the best that can be said of them. These articles contain no facts, no intelligent reasoning; just a spewing of one man's ill-formed opinions. Ars has already lost my paid subscription (and my ad revenue) due to other crap articles by this author, and I can't imagine them not losing more as a result of this article.
I'd love to think they would be better off, but I assume their analytics are telling them right now that cheap trolling increases ad impressions more than journalistic hard work.
While differing in nitty-gritty details, the googler basically confirms what I interpreted to be the main thrust of the Ars article.
AOSP is the carrot, the compliance necessary for google's value add software is the stick.
The last paragraph concludes saying that Android with google apps is the least bad offering out there. That's why I both use it personally, and why I'm not super pumped about the future of any mobile platform these days.
> AOSP is the carrot, the compliance necessary for google's value add software is the stick.
"Because cloud!" seems to be the answer to most of the points raised in the original article, which kinda sounds ok on the face of it; but why can't those backend services be abstracted out as well? Why shouldn't I be able to choose some other provider for all these services, like location?
It reminds me of a commonly suggested solution to the browser wars in the 90s, when the reasoning for Microsoft's integration of IE directly into the OS was all the new possibilities from such deep integration: why not just allow different browsers/engines (e.g. mozilla) to be swapped in? Well, because then you wouldn't be using MS products anymore!
And I think a lot of that is repeating itself here.
The location example is bothersome, but the point about 4.4 adding the storage API to enable Dropbox (a competitor) access to apps and the systems in precisely the same way as Google Drive does demonstrate they aren't nearly as closed as many like to portray them as being. Android has the most pervasive mechanisms of this kind of any widespread system, and the best approach for adding them with applications. This is, by far, the single most underappreciated part of the platform, including by many Googlers outside the Android team.
That said, it pisses me off violently that to get weather from a non-Google source my device still insists that Google get my location data. The location system very much should be pluggable, and it doesn't present the kind of technical hurdles stuff like a generic purchasing API (discussed elsewhere) would.
If you make your own location provider, Google will call you non-compatible and not let you have the Google Play store. They consider users using someone else's location services to be terrible for their company, as per internal emails:
http://www.engadget.com/2011/05/10/internal-emails-reveal-go...
The problem is Google wrapping those in such a way that sends them the data of the underlying sensors before reporting up the stack to the requesting app. They (rightly) point out this enables different sorts of location stuff, like the network parts, but it doesn't allow you to say to the Google Services I only want you using GPS, and no you can't report back without that whole layer becoming completely unusable, unless the app developer wrote it for the lower level stuff before and manually bypasses it in the case they detect Google's service is disabled.
Because I don't trust Google with this data, and will sacrifice battery life and accuracy to prevent them having it. Frankly the weather is the same for a few hundred metres around me in each direction!
They proved with the WiFi slurping on Street View cars they can't be trusted with this stuff at all.
On my devices doing the first causes apps using the Google Play Services to report that you've disabled the location service completely, while the direct GPS based apps continue just fine.
The broader point here is wanting to be able to remove Google's service software from the equation, and run only code you can actually inspect the contents of for this kind of data. To be honest those apps having direct GPS access isn't ideal either and this should all be proxied through a standardised open source app on the device.
On a Nexus 5 doing the first doesn't change anything for me; it's just less accurate (I did so, then opened up Google Maps to double check).
But you're going to have to define what you mean by "Google code", because ostensibly all of Android is "Google code". Doing what I outlined above will stop it from going through any form of sensor fusion. If you want to remove Google's service software then just create a build without Play Services on it, it's that simple. AOSP boots, on the Nexus devices at least, without it, so it's easy to do and gets you exactly what you want.
So really I guess I'm saying: What else do you want? Remove Play Services, the Google Apps, etc, using an AOSP based build and you get a Google free phone.
> This. There will continue to be improvements to AOSP, but only as that makes driving Google's proprietary apps easier and faster.
This isn't remotely true, work continues on the platform in a number of areas beyond just feature requests from other teams. Having application teams able to explain the pain points they feel in the platform and then having the platform team come up with solutions that work for the general use case is a good thing though, it improves everybody's experience. It isn't like there are hidden "makeGmailFaster" APIs that other people can't use.
I've said it before, but it really strikes me that Ars simply don't understand the universe outside of Wintel at all, and this deconstruction is merely one of many you can do whenever they start commenting about stuff outside of that sphere. You could get away with being a tech commentator like that for a long time, but not anymore.
> but it really strikes me that Ars simply don't understand the universe outside of Wintel at all
Doesn't Ars publish the most detailed review of every new Mac OS? I also notice quite a lot of the technical articles I submit to HN from Ars are quite detailed and truthful.
Peter Bright gives a very good comeback to the statements that the google employee made.
With Android 4.4 I felt disappointed that it was just an excuse to integrate more the platform to google services, so, google become the real an unquestionable controller of Android.
The "Android is an open platform" is just a fallacy.
> With Android 4.4 I felt disappointed that it was just an excuse to integrate more the platform to google services, so, google become the real an unquestionable controller of Android.
What parts of the platform became more proprietary in 4.4? The only thing I can think of is Hangouts for SMS, but even then the SMS app still works and is updated to use the new messaging APIs introduced in KK, it just isn't the default on Nexus devices any more.
> Google music, the camera, etc.., you need really need to inform your self.
Music and Camera are still in the AOSP tree, just not Google Music and not all of the fancy camera features. Besides, neither of these changes happened in 4.4. The proprietary music app has been around for a couple years now, and Photosphere has never been in the AOSP version of the camera, which has been out for a couple years as well.
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?
'googleboy' and 'googleliar' aren't really good insults, I'm not a Google employee.
You might buy an Android with GMS, but you might buy one with Amazon's framework, or none whatsoever. It's down to the manufacturer and distributor of the device you purchase.
The real issue is that the open source world doesn't have an answer to the rise of the cloud. As the integration of the phone and the cloud becomes more central, it becomes impossible for open source to provide a matching experience. The open source movement was born when the pendulum was swinging from the centralized mainframe to the PC revolution. But now as the pendulum is swinging back to centralized computing there will be fewer chances for small individualistic rebels to make an impact.
> The real issue is that the open source world doesn't have an answer to the rise of the cloud.
Nonsense. you're speaking as though open-source and cloud storage are somehow related or in competition. But they're orthogonal -- one can obviously make open-source applications available from the cloud, and you can construct the cloud's infrastructure out of open-source elements.
> The open source movement was born when the pendulum was swinging from the centralized mainframe to the PC revolution.
That's true, but the two were coincidental and unrelated. Correlation doesn't prove causation.
> But now as the pendulum is swinging back to centralized computing there will be fewer chances for small individualistic rebels to make an impact.
Wait, what? How does open-source relate to centralized computing? For that matter, how does cloud storage relate to centralized computing? It's not as though cloud storage requires a central repository, any more than the Internet must be a central repository in order to function.
Just one example: Linux (a) dominates the Internet's servers and (b) is open-source.
"Just one example: Linux (a) dominates the Internet's servers and (b) is open-source."
...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
Furthermore, while it is true that quite a bit of web services and "cloud computing" was built with free software, the effect is very different than distributing free software on desktops. If you do not like some new feature of the Linux kernel, you can just not use it -- nobody forces you to upgrade, and in extreme cases it is possible to fork the project. On the other hand, if you do not like a new feature in Facebook...tough luck, you have no authority. Similarly, if you want a new feature in the Linux kernel, you can add it -- maybe Linus won't merge it with the official source, but you can still have the feature and distribute it to others. Your next great idea for a GMail feature is irrelevant, because you cannot add features to GMail.
> ...and untold millions of lines of changes to the Linux kernel are kept secret ...
Are you serious? The entire Linux kernel is open-source and public (and it is available here: https://www.kernel.org/). Most programs delivered along with the kernel are also open-source. Many Linux distributors of large assemblages of code refuse to include anything that isn't open-source.
You are ignoring the long list of companies that modify the Linux kernel for their own purposes, never releasing their changes, and sometimes using their modified kernel on a web server that runs web apps for their users. As long as they are not distributing their modified kernel to anyone they can keep their changes secret.
For the same reason the GPLv2 has nothing to say about patents, even though patents are used to do the kinds of things the GPL was meant to prevent.
The thing to keep in mind is that the changes that web companies make to free software are not usually for internal consumption. The changes are user-facing -- but the software is delivered via the web, rather than distributed to the users, and so the web company never triggers any requirement to make their changes available. The GPL does allow this, but it is not in the spirit of the GPL, and the Affero GPL was created to deal with this problem.
I'm not sure that's true (I'm not the most knowledgeable person when it comes to the exact specifics of the GPL). Without institutions protecting IP (like patents, trademarks, copyright) the GPL couldn't exist, it's just a hack on top of IP.
I agree that it's not in the spirit of the GPL, but they did explicitly not add in sections about that in the GPLv3. The v2 FAQ mentioned that they were considering adding in web-based applications, but the v3 FAQ says it's still okay, but if you're writing software and want to make it not okay, use the AGPL.
> ...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
It's false. Code that is modified and then never released is not what the GPL was meant to prevent.
It is not false in the context of the web being built on free software. The GPL is meant to prevent a situation where free software is used to create proprietary software that denies its users their freedom. In the case of web companies modifying free software and presenting their modified software to users as a web app, that is exactly what happens, and it is only because of a loophole that it does happen. The Affero GPL was created to address this particular loophole.
Along with the point you've just made, I thought about this after my last post, related to the difference between a tablet and the cloud. If a company changes the Linux kernel or an open-source application and includes it in their mobile device, they have to release the source on demand. As intended. (And there have been a number of high-profile cases in which companies tried to avoid releasing source.)
But if they change the Linux kernel or an open-source server utility and put it on their cloud server, they don't. An unintended outcome, and one that makes the cloud different than what came before it.
So I concede that the cloud is different, and it does affect the idea of open-source.
The line is drawn if and when a client machine downloads an open-source app from the cloud. If that never happens, then there's no requirement to release source.
> ...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors
By the people who made the changes but never had to release them, by NDAs that people sign before they work for web companies, etc. There is nothing in the GPLv2 that says, "All your changes must be released." What it says is that if you give a modified version to another person, your changes must be GPL'd also. Since web companies do not give modified versions of the kernel to others, they are not in any way obligated to make their changes available to others, and more often than not they do not make those changes available.
Remember, recipients of GPL code (companies in this case) are not affected by the terms of the GPL until they redistribute the code themselves, until then they can add proprietary code all they want, run it on servers and never release a thing. They are completely free to USE the code however they wish.
So in this example, no cloud company has to release changes to their running linux kernel because it was never distributed to end users, or at all.
Same for all other GPL code running on servers, users of the service, loading web pages and using APIs, are not recipients of the code under the GPL, so they have no rights under the license.
If some company decides their changes to the kernel, or nginx, or apache, or php can be released because it won't destroy their business, they frequently do so. Otherwise you'll never hear about it and changes silently remain secret.
No, there is no proprietary code in the official kernel as distributed on kernel.org. There is a very long list of companies that have their own version of the kernel, which they keep to themselves, which contains their own proprietary changes, and which they never distribute to anyone else. There is no requirement whatsoever that you give your changes to Linux to anyone, there is only a requirement that your changes be GPL'd if you do choose to distribute them.
There are two free software answers to "the cloud:"
1. Open APIs that allow useful, meaningful, and complete interoperability between different services and local software. This is a compromise that allows cloud services to continue to be proprietary while not locking users in to any one particular service or platform.
2. The Affero GPL, which requires service providers to make their source available to their users.
Personally I think that (1) is not only a more realistic option, but in the long run a more beneficial option for users.
1. Open APIs that allow useful, meaningful, and complete interoperability between different services
Also: competition. A lot of people only put up with things Facebook, Google, and Apple get up to because they feel there's no viable alternative that meets their needs. A climate that fosters competition better will encourage upstarts.
"how would you propose that in-app purchasing not go through GMS? Some general platform API to allow the app to do an in-app purchase with whoever wants to be a “purchase provider?”"
Actually, yes. That is how I would propose that an in-app purchasing system not go through GMS.
That was my first thought too, but there's big problems with that if you think about it for a while.
Say they did something like that. Now, I am going to build my own "purchase provider" that just says I paid without ever charging anything. How are you going to stop me from doing that? Somebody would have to authenticate "purchase providers" as actually charging money and paying it to the developer. Either you'd have to manually embed keys for authorized providers in your app, or trust some third-party to authenticate providers. Either way puts you pretty much where you are now.
Then there's the matter of developer authentication. Now I build a "purchase provider", but I'm an honest one who wants to actually bill the customer and pay the developer. How do I know who to pay? No developer has signed up in my system yet, so I have to use some kind of universal token to identify the developer of an app that somebody is making purchases from and tell them they have money to claim from me. It would have to be email, since what else would work? And we all have seen how secure email is lately. Anybody who managed to put a different address into the app or somehow intercept email to your address could claim the money.
Then we have payment splits. The Google app store has a published payment split between themselves and the developer that you implicitly agree to by publishing there. If you had universal "purchase providers" that anybody could implement, who decides what their payment split is? If I wanted my payment provider to split 90% to me and 10% to you, how do you stop that? If we have a third-party doing provider authentication, what are their standards for what payment splits are acceptable?
There's probably even more issues that I haven't thought of yet. If you want to do purchasing like this, you pretty much have to make your own app store and define a proprietary API for it that app developers must explicitly implement.
Although I generally think most of the arguments in this article are bad, I do believe that having all purchases go through google can add value because even though I don't trust them with my data, I still trust them with my purchases.
In addition to those issues, the SDK is not open-source and is instead a proprietary Samsung license that severely restricts and takes control of a programmers applications (despite the software being supported by the linux foundation).
Overall, open webOS or sailfish/mer are much better projects.
Tizen is in a very precarious position at Samsung. If Samsung saw the slightest advantage (or, conversely, threat) to the billions of dollars they make with Android, Tizen would be gone. There is no handset business at Samsung without Android. Samsung lacks an ecosystem like Amazon has so forking is not practical.
Intel, you say? Tell me how many handsets has Intel.
He's not wrong though - competing with Google on Android is definitely possible. I think the best step would be to create an OSS (GNU?) distribution of Android in the same way we have Linux. While Linux doesn't have all the same proprietary apps and services that Windows does, OSS devs have stepped up and provided some really great alternatives. We need to do the same for Android.
The only thing we are really missing is a large OSS project to serve as a base.
This isn't the first time that Ars Technica, an otherwise reasonable source of information, has published an utter crap article written by Peter Bright.
If Ars wants to maintain any shred of credibility (and a technically intelligent readership) in the future, they need to can this author, or label all of his articles as "op-ed", because that's the best that can be said of them. These articles contain no facts, no intelligent reasoning; just a spewing of one man's ill-formed opinions. Ars has already lost my paid subscription (and my ad revenue) due to other crap articles by this author, and I can't imagine them not losing more as a result of this article.
Get rid of him, Ars. You'll be better off for it.