
A Google employee's critique of the Ars Technica Android unforkable article - patrickaljord
http://arstechnica.com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/?comments=1&post=26199423
======
falcolas
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.

Get rid of him, Ars. You'll be better off for it.

~~~
ZeroGravitas
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.

~~~
falcolas
I would hope that Ars' editorial staff realizes that short term gains at the
cost of long term losses is not worth 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.

~~~
alexeisadeski3
Sometimes I feel like the whole internet will eventually turn into Gawker
clones.

------
forgottenpass
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.

~~~
csarva
> 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.

~~~
mdwrigh2
> Why shouldn't I be able to choose some other provider for all these
> services, like location?

You can, just provide an implementation of LocationProvider:
[http://developer.android.com/reference/android/location/pack...](http://developer.android.com/reference/android/location/package-
summary.html)

~~~
fidotron
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.

~~~
mdwrigh2
Why do you want to skip the sensor fusion step? The entire point is it gives
you more accurate data.

~~~
fidotron
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.

~~~
mdwrigh2
Settings > Location > Mode > Select "Device Only"

and

Settings > WiFi > Advanced > Uncheck "Scanning always available" (which asked
for permission on first boot)

These are user settings, not app settings.

~~~
fidotron
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.

~~~
mdwrigh2
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.

------
fidotron
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.

~~~
protomyth
> 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.

~~~
Schlaefer
Ars is not one voice. Imho Peter Bright's articles esp. related to OSS and MS
should always be read with an "open mind".

------
alexeisadeski3
I don't understand how this is even a discussion.

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.

------
adrianlmm
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.

~~~
hahainternet
> 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.

~~~
zwattt
> AOSP ... is more open

AOSP is not an Android, stop lying, googleboy.

~~~
Oletros
Oh, it is ironic that the troll making wrong claims is the one calling others
liars.

Are you more than 10?

------
guelo
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.

~~~
lutusp
> 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.

~~~
betterunix
"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.

~~~
lutusp
> ...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/](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.

~~~
betterunix
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.

~~~
dkuntz2
If the GPL was, as you claim, meant to keep that from happening, why is it
totally permissible by the GPL?

~~~
betterunix
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.

~~~
dkuntz2
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.

------
justizin
"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.

~~~
ufmace
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.

------
caniszczyk
Is it really the least bad offering?

Tizen has potential and is more open:
[https://www.tizen.org/](https://www.tizen.org/)

The problem is no one uses it on a large scale yet...

~~~
hajile
Tizen has it's own large set of problems according to rasterman (EFL guy who
works for Samsung).

[https://www.tizen.org/irclogs/%23tizen.2013-01-20.log.html](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.

------
stcredzero
"Critique."

------
Zigurd
ART is in AOSP. Had Google intended to create a two-speed Android, that would
have been the place to turn AOSP into a second class citizen.

Kindle Fire will run on ART. Heck of a technology to give to an ecosystem
competitor.

------
RyanZAG
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.

~~~
fnordfnordfnord
Cyanogen?

~~~
ZeroGravitas
What I was gong to suggest, with F-Droid as the repository/app store.

