A Google employee's critique of the Ars Technica Android unforkable article
arstechnica.com
arstechnica.com
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.
Then again, this is hardly the first P.B. story that's caused controversy and caused Ars readership/legitimacy, so I am probably wrong.
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.
"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.
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.
You can, just provide an implementation of LocationProvider: http://developer.android.com/reference/android/location/pack...
They proved with the WiFi slurping on Street View cars they can't be trusted with this stuff at all.
and
Settings > WiFi > Advanced > Uncheck "Scanning always available" (which asked for permission on first boot)
These are user settings, not app settings.
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.
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.
If the cloud part is the hard part to implement why not make the app open source ?
Its exactly like Chromium in other words and we see that with Blink.
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.
Peter is a tabloid journalist, he stopped writing interesting balanced articles a long time ago and now just posts linkbait.
His points are thoroughly refuted, but I guess you didn't bother to read them.
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.
Siracusa understands very well Apple ecosystem :)
Not only is AOSP completely open and forkable, THERE IS A COMMERCIALLY SUCCESSFUL ANDROID FORK OUT THERE - and it's called Kindle Fire OS.
The existence of this conversation, this "controversy," is confusing to me.
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.
No it isn't, you're just lying. The response lays out in detail how Android (ie AOSP) is more open than any alternative.
Stop talking crap.
Android is AOSP. AOSP is Apache. https://source.android.com/
QED.
No, Android is AOSP + GMS, googleliar.
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.
AOSP is not an Android, stop lying, googleboy.
Are you more than 10?
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.
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.
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?
But as you take him as if has written the Bible and take all of his words as The Truth it is just a waste of time trying to argue.
If at least he knew just a little of Android perhaps he would write something that it is not utterly wrong
No,they are almost as bad as the article.
And it is funny that he tries to discuss about Android implementation with Dianne Hackborn.
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.
...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.
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.
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 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.
No, I'm addressing your prior claim that the Linux kernel is not open-source. The claim is false.
Also, companies that change the kernel, and then release their changed kernels, cannot do so without also releasing their source.
The claim is false, in whatever form it takes.
I did. Here is what you said:
> ...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.
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.
Kept secret by whom?
This is complete nonsense. There is no proprietary, closed-source code in the Linux kernel.
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.
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.
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.
Actually, yes. That is how I would propose that an in-app purchasing system not go through GMS.
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.
As it stands if you've written an Android store you can (and at least Amazon and Verizon have) write your own in app purchase mechanism as well.
Tizen has potential and is more open: https://www.tizen.org/
The problem is no one uses it on a large scale yet...
https://www.tizen.org/irclogs/%23tizen.2013-01-20.log.html
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.
Intel, you say? Tell me how many handsets has Intel.
Jolla and Firefox OS are better bets.
Kindle Fire will run on ART. Heck of a technology to give to an ecosystem competitor.
The only thing we are really missing is a large OSS project to serve as a base.
What about Firefox OS?