Joe Hewitt: Android and Open Source(joehewitt.com)
joehewitt.com
Joe Hewitt: Android and Open Source
http://joehewitt.com/post/android-and-open-source/
5 comments
"Most Android hardware is carrier locked, has proprietary firmware, or has proprietary services loaded on top and therefore is closed for users."
Does Android mandate this or can you go and create a phone that has none of the carrier restrictions you noted? I think you can.
Does Android mandate this or can you go and create a phone that has none of the carrier restrictions you noted? I think you can.
all Android phones have three sets of restrictions:
1.) Restrictions imposed by Google, which you are free to ignore if you stick to just the released source code of Android (like the Market or their proprietary apps) 2.) Restrictions imposed by the Manufacturer (which you could ignore by making your own phone) 3.) Restrictions imposed by the Carrier (which you can presumably ignore if you make an unlocked GSM phone).
Working outside of all three of those restrictions would basically put you in the same category as OpenMoko (which while an enterprising idea was pretty much guaranteed to not go anywhere).
So I'd agree, "you" can go create a phone without any of the carrier restrictions, provided you are a handset manufacturer. I'm not a handset manufacturer, so I can't.
1.) Restrictions imposed by Google, which you are free to ignore if you stick to just the released source code of Android (like the Market or their proprietary apps) 2.) Restrictions imposed by the Manufacturer (which you could ignore by making your own phone) 3.) Restrictions imposed by the Carrier (which you can presumably ignore if you make an unlocked GSM phone).
Working outside of all three of those restrictions would basically put you in the same category as OpenMoko (which while an enterprising idea was pretty much guaranteed to not go anywhere).
So I'd agree, "you" can go create a phone without any of the carrier restrictions, provided you are a handset manufacturer. I'm not a handset manufacturer, so I can't.
Huh? If you want a phone without carrier restrictions, you just need to buy it somewhere else.
It's not cheap, but it's very easy. See, for example, http://www.htcphonestore.com/
It's not cheap, but it's very easy. See, for example, http://www.htcphonestore.com/
I was actually referring to making a phone, not buying one; but I thanks for the link. It could come in handy if I need a phone for development.
But what of those "Chinese Android" phones I hear about? That they're based on Android but aren't officially Android?
As far as I know, any phone that runs Android is "Officially Android", of which there are a number of Chinese handset manufacturers making handsets.
Many of them don't have access to the Market, or run Google's applications, but I don't think that makes them "not officially Android".
Many of them don't have access to the Market, or run Google's applications, but I don't think that makes them "not officially Android".
You can buy a developer phone. However, I'm not sure you can get one for any carrier.
It seems whenever someone tries to come up with tangible benefits of Android's "openness" they invariably end up describing properties of the Palm Pilot, Windows Mobile, and Blackberry operating systems that have absolutely nothing to do with open source. Case in point:
> I've been pleasantly surprised at how much more
> configurable Android is. The fact that you can
> replace the home screen with a third-party launcher
> or even make your own app store is a clear sign
> that Google's heart is in the right place.
It's sad that we've reached a point where what is good design is such an absolute, with no consideration for customization as a design goal.
To be fair, its been tried a couple of times to build really customizable machines. It is just more expensive from a manufacturing point of view and the market is never really there. The Treo lost its slot and I seem to remember an attempt by some of the Amiga team to build a PC in a modular way (ended up in a museum somewhere).
The problem has really been the cellphone focus which means "open" = "what carriers want". The lack of a true iPod touch equivalent has hurt the potential of Android.
I really think if you were trying to build and open, customizable, modular platform, it would be competitive with Apple, Microsoft, and RIM. Android really doesn't have a love for an ecosystem of gadgets around it. It is a lone wolf and needs to really have a high speed connector where people could really build cool add-ons that it can plug into. Make it the "I can carry my world" device that can be plugged into other things to get more power / capability.
The funny thing is that the inside of the Mac Pro has so many niceties from a hardware expansion point of view that never really appear on PCs.
The problem has really been the cellphone focus which means "open" = "what carriers want". The lack of a true iPod touch equivalent has hurt the potential of Android.
I really think if you were trying to build and open, customizable, modular platform, it would be competitive with Apple, Microsoft, and RIM. Android really doesn't have a love for an ecosystem of gadgets around it. It is a lone wolf and needs to really have a high speed connector where people could really build cool add-ons that it can plug into. Make it the "I can carry my world" device that can be plugged into other things to get more power / capability.
The funny thing is that the inside of the Mac Pro has so many niceties from a hardware expansion point of view that never really appear on PCs.
To be fair, its been tried a couple of times to build really customizable machines. It is just more expensive from a manufacturing point of view and the market is never really there.
Customizable machines are a billion dollar industry, chances are, you're sitting in front of one right now. It's not a matter of making a customizable machine, we know how to do that. It's a matter of actually allowing the user to customize things, which can be done by allowing core components to be swapped out for alternatives. In this context, the customization doesn't need to be complete/absolute, it just needs to recognize that different users have different needs and work differently. A consumer/home user may find the grid of icons on the iPhone screen to be easy to use, but the business user may want a calendar or email listing on their home screen (interestingly enough, we laugh at the members of both of these groups who end up with a massive grid of icons on their desktops, which is obviously bad for usability ("The link to the website was at the tip of the penis!" -- Sales Guy vs Web Dude). And Android offers the capability for apps to provide this functionality, but Android isn't considered to have Good Design(tm) (or is at least "less" than Apple's design) despite this capability.
Customizable machines are a billion dollar industry, chances are, you're sitting in front of one right now. It's not a matter of making a customizable machine, we know how to do that. It's a matter of actually allowing the user to customize things, which can be done by allowing core components to be swapped out for alternatives. In this context, the customization doesn't need to be complete/absolute, it just needs to recognize that different users have different needs and work differently. A consumer/home user may find the grid of icons on the iPhone screen to be easy to use, but the business user may want a calendar or email listing on their home screen (interestingly enough, we laugh at the members of both of these groups who end up with a massive grid of icons on their desktops, which is obviously bad for usability ("The link to the website was at the tip of the penis!" -- Sales Guy vs Web Dude). And Android offers the capability for apps to provide this functionality, but Android isn't considered to have Good Design(tm) (or is at least "less" than Apple's design) despite this capability.
Isn't this a rather old trend? As technology becomes more complex, we rely on the creator to make sensible decisions about the interface to allow us to focus primarily on what is relevant to achieving our goal.
Abstraction is the only way technology can become more powerful and more accessible at the same time.
Abstraction is the only way technology can become more powerful and more accessible at the same time.
Things aren't better just because they're more configurable, even if customization is a goal. More often options are just varnish because the defaults aren't reasonable. Make the defaults good first and then add configuration and options.
Yeah, and they don't suck just because they do let you change something you don't like.
Every Apple product is so well designed, until the next Apple product comes out.
Every Apple product is so well designed, until the next Apple product comes out.
First off, no Android device sold blocks installing custom home screens from the market. In the US at least, all major carriers but AT&T allow side-loading applications. What you do see across the board is restricting root access, which, while unfortunate, still allows for a lot of customization.
Secondly, different users will always have different preferences and use cases; the variety enabled by customization allows for more users to be happier. Furthermore, such openness has produced custom apps that blow away everything else away. Swype, a custom keyboard that cannot be distributed to the end-user of rival mobile OS's, is the most obvious example. At least at the OS level, this modularity is a sign that Android is well-designed.
Secondly, different users will always have different preferences and use cases; the variety enabled by customization allows for more users to be happier. Furthermore, such openness has produced custom apps that blow away everything else away. Swype, a custom keyboard that cannot be distributed to the end-user of rival mobile OS's, is the most obvious example. At least at the OS level, this modularity is a sign that Android is well-designed.
Swype is also available on Symbian. The company that makes it has stated that it wants it to become a standard on all mobile platforms.
What Joe considers important (public source tree and outsider commits) are probably amongst the absolute least important and interesting aspects of openness. It's the type of thing only a maintainer would care about.
He's arguing a point that nobody cares about. Even RMS is probably saying, "You're being a bit pedantic here about the definition, aren't you Joe?"
He's arguing a point that nobody cares about. Even RMS is probably saying, "You're being a bit pedantic here about the definition, aren't you Joe?"
That's a disappointing attitude. Let me give you a great counterexample.
Chrome was initially a completely fork of Webkit, but Google eventually chose to work with Apple and merge all of their changes to the Webkit trunk. This was only possible because Webkit, unlike Android, allows outsiders to commit.
The costs of maintaining a fork of a project as large as Webkit (or Android) are so huge, even Google didn't want to bear them for long. The benefits of the merge are huge for all users. Not only does Chrome continue to get Apple's changes downstream, like CSS transforms, but Safari gets Google's changes, like web sockets. In Android today, this sort of collaboration would be impossible.
Chrome was initially a completely fork of Webkit, but Google eventually chose to work with Apple and merge all of their changes to the Webkit trunk. This was only possible because Webkit, unlike Android, allows outsiders to commit.
The costs of maintaining a fork of a project as large as Webkit (or Android) are so huge, even Google didn't want to bear them for long. The benefits of the merge are huge for all users. Not only does Chrome continue to get Apple's changes downstream, like CSS transforms, but Safari gets Google's changes, like web sockets. In Android today, this sort of collaboration would be impossible.
I just wanted to say thanks for the blog post. It conveyed a lot of the nuances that might not have come through in the tweets.
And while everything you say may be true, I still don't think most people care. In fact, I'm fairly certain most people don't care. Ask your average developer, much less consumer, the difference between Chrome and Android with respect to openess and you'll probably get blank stares.
Clearly Google doesn't think the benefits of public commits outweighs the costs, otherwise it would economically make sense. Additionally I suspect given the current state of mobile OS development vs browser development they probably realize that public contributions would be fewer and of less general utility than what we've seen with browsers.
I still think the fact that one can pick up Android, even if it is just 2.2 today, and build it, and port it to any device they want, and rip out any code they like, and add any code they like is a pretty reasonable definition of open -- at least given that openness is a gradient and not absolute term.
Clearly Google doesn't think the benefits of public commits outweighs the costs, otherwise it would economically make sense. Additionally I suspect given the current state of mobile OS development vs browser development they probably realize that public contributions would be fewer and of less general utility than what we've seen with browsers.
I still think the fact that one can pick up Android, even if it is just 2.2 today, and build it, and port it to any device they want, and rip out any code they like, and add any code they like is a pretty reasonable definition of open -- at least given that openness is a gradient and not absolute term.
And while everything you say may be true, I still don't think most people care
Just because most people don't care doesn't mean it's not important.
Just because most people don't care doesn't mean it's not important.
When you're arguing about the definition of a word, in a natural language like English, what people care about actually is kind of important.
In the days before this site, when we poor cave-developers had to get our news from places like Slashdot, there were regular huge flame-fest threads complaining about Apple's lack of "openness" with WebKit. Sure, you could download it, there was code under an OSI-certified license, but they were TERRIBLE HORRIBLE BAD NO-GOOD COMMUNITY MEMBERS because of how they treated the upstream KHTML project they'd started from.
Why was it wrong -- so wrong that they were bullied into changing their process -- for Apple to behave this way, wrong enough to get so many people worked up, so many people to care, when Google engages in the same sort of "open license, closed project" behavior and get a pass?
Why was it wrong -- so wrong that they were bullied into changing their process -- for Apple to behave this way, wrong enough to get so many people worked up, so many people to care, when Google engages in the same sort of "open license, closed project" behavior and get a pass?
...
And while everything you say may be true, I still don't think most people care. In fact, I'm fairly certain most people don't care. Ask your average developer, much less consumer, the difference between Chrome and Android with respect to openess and you'll probably get blank stares.
...
and what subset care about:
the definition of open: "mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make"
?
and what subset care about:
the definition of open: "mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make"
?
A much bigger subset. Although even that misses the larger point.
Probably the most useful part of the Android story is side-loading. After that the ability to host Android on any device I like. After that the ability to add or remove any part of Android I like. At somet point we eventually get down to something like public commits, but that's far below things like ability to audit and escrow code.
Again, I'm not saying that the things Joe wishes for are bad things. But the absence of them does not make something closed.
Probably the most useful part of the Android story is side-loading. After that the ability to host Android on any device I like. After that the ability to add or remove any part of Android I like. At somet point we eventually get down to something like public commits, but that's far below things like ability to audit and escrow code.
Again, I'm not saying that the things Joe wishes for are bad things. But the absence of them does not make something closed.
> He's arguing a point that nobody cares about.
Right, that's why it's been in the top 5 of HN for two days.
> Even RMS is probably saying, "You're being a bit pedantic here[...]"
Have you ever read a word of RMS? :P
His position would be that Hewitt is being insufficiently pedantic, particularly with regard to the complete closed-ness of the hardware and manufacturer/carrier-specific software.
Right, that's why it's been in the top 5 of HN for two days.
> Even RMS is probably saying, "You're being a bit pedantic here[...]"
Have you ever read a word of RMS? :P
His position would be that Hewitt is being insufficiently pedantic, particularly with regard to the complete closed-ness of the hardware and manufacturer/carrier-specific software.
Yeah, I was using a bit of hyperbole with RMS. Taking someone who is the most pedantic about naming, e.g., GNU/Linux, and most extreme about what freedom and openness is, and then making a joke that he even thinks Joe has taken it too far.
No, public source tree and a process for outsider commits are critical for proper open source projects. Otherwise, while you have the code, your only choice is to fork, not collaborate. The code may be OSI compliantly licensed, but the community, the decision process, and the opportunity to actually make a difference are closed.
"Otherwise, while you have the code, your only choice is to fork, not collaborate"
If you look at this the right way, every checkin is a new fork. There's no such thing as a mainline branch. There's absolutely no reason you can't simply fork some branch of Android and start working on it and tell everyone to work from your branch. Each developer has the choice, including Google to use your branch or checkin to a different fork.
Again, AFAIK, Google is not preventing anyone from branching and checking into a new branch. This is fundamentally no different than Google allow public commits, but then branching after each of their checkins.
To put it another way, if you were to take the 2.2 branch of Android and you forked then contributed an incredible 7" tablet UI experience that Google nor Apple could ever match, you may have forced Google to begin picking up your branch.
There's is nothing stopping any of this from happening, except the apparent attitude that Google needs to bend over backwards to accomodate people who haven't shown any inclination nor aptitude to an interesting contribution.
Goodness, I can't believe I'm defending Google.
If you look at this the right way, every checkin is a new fork. There's no such thing as a mainline branch. There's absolutely no reason you can't simply fork some branch of Android and start working on it and tell everyone to work from your branch. Each developer has the choice, including Google to use your branch or checkin to a different fork.
Again, AFAIK, Google is not preventing anyone from branching and checking into a new branch. This is fundamentally no different than Google allow public commits, but then branching after each of their checkins.
To put it another way, if you were to take the 2.2 branch of Android and you forked then contributed an incredible 7" tablet UI experience that Google nor Apple could ever match, you may have forced Google to begin picking up your branch.
There's is nothing stopping any of this from happening, except the apparent attitude that Google needs to bend over backwards to accomodate people who haven't shown any inclination nor aptitude to an interesting contribution.
Goodness, I can't believe I'm defending Google.
The point that Joe is making is that people can't participate in the official, Google-supported, widely distributed version of the code.
They can fork the code and do whatever they want, but that fork doesn't have a lot of value if it doesn't have distribution. They can fix a bug, but they can only fix it for themselves, not their customers who get Android through retail stores.
You may of course say "Google has no obligation to let people contribute to their distribution". And you'd be right. But this is like saying "I am under no obligation to smile and say hello when you enter the elevator". You'd be right. But people do it anyway because it makes the world a better place.
Likewise, Joe is saying it would be nice if Google allowed people to contribute directly to the main distribution of Android. They're under no obligation to do so, but it sure would be cool.
I hope this clears things up.
Full disclosure: I work on Chrome at Google which has some of the features Joe is asking for in Android. I also wish Android had them, but I have no special insight into why they're missing.
They can fork the code and do whatever they want, but that fork doesn't have a lot of value if it doesn't have distribution. They can fix a bug, but they can only fix it for themselves, not their customers who get Android through retail stores.
You may of course say "Google has no obligation to let people contribute to their distribution". And you'd be right. But this is like saying "I am under no obligation to smile and say hello when you enter the elevator". You'd be right. But people do it anyway because it makes the world a better place.
Likewise, Joe is saying it would be nice if Google allowed people to contribute directly to the main distribution of Android. They're under no obligation to do so, but it sure would be cool.
I hope this clears things up.
Full disclosure: I work on Chrome at Google which has some of the features Joe is asking for in Android. I also wish Android had them, but I have no special insight into why they're missing.
I agree those things would be nice. But that's not the issue. The issue is if Android is open or not.
I personally think it would be nice if nothing shipped with the GPL as it restricts my freedom, but I won't claim gcc is not open.
The issue isn't if Android can improve along a given vector. Rather it is is Android a closed platform because there exists a branch that doesn't take public contributions or have a public tree. I don't think so.
I personally think it would be nice if nothing shipped with the GPL as it restricts my freedom, but I won't claim gcc is not open.
The issue isn't if Android can improve along a given vector. Rather it is is Android a closed platform because there exists a branch that doesn't take public contributions or have a public tree. I don't think so.
Personally I hate fake smiles.
Also, try contributing to the Linux kernel.
Also, try contributing to the Linux kernel.
Also, try contributing to the Linux kernel.
I did, and now it includes some of my code. What's your point? Their standards for code quality are high, but let's face it, the kernel wouldn't have reached 10MLOC if it was written like Wordpress. Android won't accept your patches at all.
Speaking of the kernel, the Android project hasn't been very good about merging back their kernel patches. Getting better, but they're now pretty far from mainline.
I did, and now it includes some of my code. What's your point? Their standards for code quality are high, but let's face it, the kernel wouldn't have reached 10MLOC if it was written like Wordpress. Android won't accept your patches at all.
Speaking of the kernel, the Android project hasn't been very good about merging back their kernel patches. Getting better, but they're now pretty far from mainline.
This article (please read the whole article, including the PDF that is mentioned) mentions that Google might be "open" regarding the source code, but it is not open regarding which components can be replaced in Android.
It seems that Google doesn't allow the carries to replace the Google Location Service.
http://daringfireball.net/2010/09/the_welcome_to_android
It seems that Google doesn't allow the carries to replace the Google Location Service.
http://daringfireball.net/2010/09/the_welcome_to_android
...if they want to use the Google trademark and have the non-open Google apps like Maps and GMail.
[deleted]
Android source code is licensed under the GPL and Apache licenses and therefore the source code is open for developers.
The Android project isn't really developed in the open therefore the process is closed for most developers.
Most Android hardware is carrier locked, has proprietary firmware, or has proprietary services loaded on top and therefore is closed for users.