First, cross-posting is a bad practice.
Second, Android declares to be open, but not open source; you can read
it as open minded, for example. However probably, we hope, it will
become fully open source when it will be more mature. Remember it's
only an early look at SDK.
On Mar 28, 7:02 am, Ze <test1....@gmail.com> wrote:
I am not satisfied with your justification; even if it isn't mature
its source must be released. So that the open source community can
enhance it more.
Ze
On Mar 28, 4:31 am, Carlo Brualdi <carlo.brua...@gmail.com> wrote:
> First, cross-posting is a bad practice.
> Second, Android declares to be open, but not open source; you can read
> it as open minded, for example. However probably, we hope, it will
> become fully open source when it will be more mature. Remember it's
> only an early look at SDK.
> On Mar 28, 7:02 am, Ze <test1....@gmail.com> wrote:
> > I don't understand how Android is an open source project as its source
> > hasn't been released?
That wasn't a justification, I don't work for Google :)
That I said is only the reality. As Google say. I agree with you, but
the facts are these. And maybe there's a reason, or there's not. I
don't know!
> I am not satisfied with your justification; even if it isn't mature
> its source must be released. So that the open source community can
> enhance it more.
> Ze
> On Mar 28, 4:31 am, Carlo Brualdi <carlo.brua...@gmail.com> wrote:
> > First, cross-posting is a bad practice.
> > Second, Android declares to be open, but not open source; you can read
> > it as open minded, for example. However probably, we hope, it will
> > become fully open source when it will be more mature. Remember it's
> > only an early look at SDK.
> > On Mar 28, 7:02 am, Ze <test1....@gmail.com> wrote:
> > > I don't understand how Android is an open source project as its source
> > > hasn't been released?
On Fri, Mar 28, 2008 at 8:36 AM, Carlo Brualdi <carlo.brua...@gmail.com> wrote
> That wasn't a justification, I don't work for Google :) > That I said is only the reality. As Google say. I agree with you, but > the facts are these. And maybe there's a reason, or there's not. I > don't know!
> On Mar 28, 4:13 pm, test1....@gmail.com wrote: > > I am not satisfied with your justification; even if it isn't mature > > its source must be released. So that the open source community can > > enhance it more.
You're correct that Google is approaching this in a completely inverted fashion relative to any real open source project.
Android isn't open source; it's "going-to-be-open-someday" source. Google has only published the portions whose licensing requirements demanded that they do, and there's no community around the Android platform itself, other than within the Googleplex.
This posting at Livejournal <http://robilad.livejournal.com/22312.html>, which also gets into some interesting aspects of the terms and conditions (which are between you and Google, and not with the "Open Handset Alliance") points out that Google will release some unspecified "most of" the Android source under the Apache license, but not until phones ship, "the second half of 2008" according to Google. Samsung, a pretty aggressive company, doesn't expect that *their *Android phone will be out before 2009, however.
It's unclear what this "most of" amounts to. So, no one knows whether it'll, for instance, include Dalvik or not, or Surface Manager or not. All we know is that, so far, Google's only released what they had to, and hasn't actually engaged with the open source community on this "open source" project in any discernible way. Maybe Dan Morill, or someone like him, would liketo try to clarify this.
> On Fri, Mar 28, 2008 at 8:36 AM, Carlo Brualdi <carlo.brua...@gmail.com>
> wrote
> > That wasn't a justification, I don't work for Google :)
> > That I said is only the reality. As Google say. I agree with you, but
> > the facts are these. And maybe there's a reason, or there's not. I
> > don't know!
> > On Mar 28, 4:13 pm, test1....@gmail.com wrote:
> > > I am not satisfied with your justification; even if it isn't mature
> > > its source must be released. So that the open source community can
> > > enhance it more.
> You're correct that Google is approaching this in a completely inverted
> fashion relative to any real open source project.
> Android isn't open source; it's "going-to-be-open-someday" source. Google
> has only published the portions whose licensing requirements demanded that
> they do, and there's no community around the Android platform itself, other
> than within the Googleplex.
> This posting at Livejournal <http://robilad.livejournal.com/22312.html>,
> which also gets into some interesting aspects of the terms and conditions
> (which are between you and Google, and not with the "Open Handset Alliance")
> points out that Google will release some unspecified "most of" the Android
> source under the Apache license, but not until phones ship, "the second half
> of 2008" according to Google. Samsung, a pretty aggressive company, doesn't
> expect that *their *Android phone will be out before 2009, however.
> It's unclear what this "most of" amounts to. So, no one knows whether it'll,
> for instance, include Dalvik or not, or Surface Manager or not. All we know
> is that, so far, Google's only released what they had to, and hasn't
> actually engaged with the open source community on this "open source"
> project in any discernible way. Maybe Dan Morill, or someone like him, would
> liketo try to clarify this.
> there's no community around the Android platform itself
I betcha the other 8,463 current members of this forum would disagree with you. But then, every forum needs a troll, I guess.
> It's unclear what this "most of" amounts to. So, no one knows whether > it'll, for instance, include Dalvik or not, or Surface Manager or not. All > we know is that, so far, Google's only released what they had to, and hasn't > actually engaged with the open source community on this "open source" > project in any discernible way. Maybe Dan Morill, or someone like him, would > liketo try to clarify this.
Certainly. I actually talk about this publicly all the time, so quite a few people know. Ironically, I may not have said it on this forum yet, so now's as good a time as any.
The short version is that anything we can get the rights to open-source, we will -- and one of the key reasons for the Open Handset Alliance is to make sure we have the rights to open-source everything we need to. If we needed a particular feature to be open sourced, we either built our own or found someone to join the Alliance and contribute their implementation.
The entire system will be open-sourced, excluding certain pieces. Things that will be opened include Dalvik, SGL, the libc implementation, the Surface Manager stuff, the Binder, the various frameworks and APIs, the core applications (like the dialer, SMS client, Home screen, etc. but possibly excluding any Google-branded apps like Gmail), the media codecs (including ones for H.264, etc.) and so on.
Anything original to us (such as Dalvik) will be Apache 2.0. Anything that has to be another license like GPL/LGPL (such as the kernel, WebKit, and Qemu) is already released. Last I heard, a few things that were derived from other projects, notably the libc implementation, will probably be released under the original BSD license.
The "certain pieces" that will remain closed are some corner cases at the device driver level. The engineers on that tell me that in general this will be a similar compromise to situations you frequently see in the 802.11 world, where you have binary-only firmware with an open-source driver. I'm sure someone will now make the inevitable "but device drivers are the most important part!" criticism, but as I said we are aiming to open-source as much as we physically can. The IP for ICs can get pretty convoluted, unfortunately. I can't be more specific than this, because I don't know that much about this level of the system.
The reason we haven't released the source yet is primarily logistical. One of the team once said "Android will be the largest open source project in the world". That may or may not be technically true, but I think it eloquently captures the scope of what we're doing. When your project is this large, the simplest questions like governance become a big deal. Dalvik by itself is huge, and so are Binder, SGL, etc. Should we have a single gigantic source tree or split up into multiple smaller projects? Anyone who's ever worked in open source knows that it can take a long time to come to consensus on decisions like that. Once we do, we have to then physically tidy up the source, make sure it builds outside our internal infrastructure, set up a public source repository that can handle the load, and so on.
Those are distractions that we can't afford right now since we are working closely with our partners to get the first devices launched. Our plan is that once we reach version 1.0, we will turn our attention to the squishier issues of releasing source.
On Fri, Mar 28, 2008 at 11:00 PM, Dan Morrill <morri...@google.com> wrote: > I betcha the other 8,463 current members of this forum would disagree with > you. But then, every forum needs a troll, I guess.
Whoops, I just noticed this went to the Internals list; the 8465 count is for the Developers list. Sorry about that -- you can pick whether you want to add them up or just take the larger number. ;)
> 2008/3/28 Stone Mirror <stonemir...@gmail.com > <mailto:stonemir...@gmail.com>>:
> there's no community around the Android platform itself
> I betcha the other 8,463 current members of this forum would disagree > with you. But then, every forum needs a troll, I guess.
> It's unclear what this "most of" amounts to. So, no one knows > whether it'll, for instance, include Dalvik or not, or Surface > Manager or not. All we know is that, so far, Google's only > released what they had to, and hasn't actually engaged with the > open source community on this "open source" project in any > discernible way. Maybe Dan Morill, or someone like him, would > liketo try to clarify this.
> Certainly. I actually talk about this publicly all the time, so quite > a few people know. Ironically, I may not have said it on this forum > yet, so now's as good a time as any.
> The short version is that anything we can get the rights to > open-source, we will -- and one of the key reasons for the Open > Handset Alliance is to make sure we have the rights to open-source > everything we need to. If we needed a particular feature to be open > sourced, we either built our own or found someone to join the Alliance > and contribute their implementation.
> The entire system will be open-sourced, excluding certain pieces. > Things that will be opened include Dalvik, SGL, the libc > implementation, the Surface Manager stuff, the Binder, the various > frameworks and APIs, the core applications (like the dialer, SMS > client, Home screen, etc. but possibly excluding any Google-branded > apps like Gmail), the media codecs (including ones for H.264, etc.) > and so on.
> Anything original to us (such as Dalvik) will be Apache 2.0. Anything > that has to be another license like GPL/LGPL (such as the kernel, > WebKit, and Qemu) is already released. Last I heard, a few things > that were derived from other projects, notably the libc > implementation, will probably be released under the original BSD license.
> The "certain pieces" that will remain closed are some corner cases at > the device driver level. The engineers on that tell me that in > general this will be a similar compromise to situations you frequently > see in the 802.11 world, where you have binary-only firmware with an > open-source driver. I'm sure someone will now make the inevitable > "but device drivers are the most important part!" criticism, but as I > said we are aiming to open-source as much as we physically can. The > IP for ICs can get pretty convoluted, unfortunately. I can't be more > specific than this, because I don't know that much about this level of > the system.
> The reason we haven't released the source yet is primarily > logistical. One of the team once said "Android will be the largest > open source project in the world". That may or may not be technically > true, but I think it eloquently captures the scope of what we're > doing. When your project is this large, the simplest questions like > governance become a big deal. Dalvik by itself is huge, and so are > Binder, SGL, etc. Should we have a single gigantic source tree or > split up into multiple smaller projects? Anyone who's ever worked in > open source knows that it can take a long time to come to consensus on > decisions like that. Once we do, we have to then physically tidy up > the source, make sure it builds outside our internal infrastructure, > set up a public source repository that can handle the load, and so on.
> Those are distractions that we can't afford right now since we are > working closely with our partners to get the first devices launched. > Our plan is that once we reach version 1.0, we will turn our attention > to the squishier issues of releasing source.
> > there's no community around the Android platform itself
> I betcha the other 8,463 current members of this forum would disagree with > you. But then, every forum needs a troll, I guess.
No Dan: the *platform, *the Android system itself. The part that you *haven't *released, Surface Manager, Dalvik, the Android libraries themselves (and thanks for being a little clearer around that, I'm pretty sure I've never seen a statement to that effect anywhere previously). I clearly mentioned the two first ones as examples in my email, in fact in the very next paragraph you quote, but I guess it's easier to ignore that and call people names instead.
There's a *community *around the Linux operating system; actually several communities, including the kernel community, the GTK+ community, the BlueZ community. There are no equivalent communities (or community) for the Android platform. Maybe there will be someday, or maybe there won't.
The open source community at large, historically speaking, *hates *"code dumps" (aka "toss-it-over-the-wall-ware") *especially *extremely huge ones. And I'm not sure it's realistic to expect that the folks currently working on GTK, Gstreamer, PulseAudio, BlueZ, and the like--the *real* open source software community--are going to drop what they're doing to take on Android instead.
The reason we haven't released the source yet is primarily logistical. One
> of the team once said "Android will be the largest open source project in > the world". That may or may not be technically true, but I think it > eloquently captures the scope of what we're doing. When your project is > this large, the simplest questions like governance become a big deal. > Dalvik by itself is huge, and so are Binder, SGL, etc. Should we have a > single gigantic source tree or split up into multiple smaller projects? > Anyone who's ever worked in open source knows that it can take a long time > to come to consensus on decisions like that. Once we do, we have to then > physically tidy up the source, make sure it builds outside our internal > infrastructure, set up a public source repository that can handle the load, > and so on.
As I say, I wonder who you expect is going to be rushing in to take it on for you. Evidently the existing work in the open source community wasn't good enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, for the LiMo Foundation and numerous others. LiMo had *eighteen *phones to show at Mobile World Congress.
> Those are distractions that we can't afford right now since we are working > closely with our partners to get the first devices launched. Our plan is > that once we reach version 1.0, we will turn our attention to the > squishier issues of releasing source.
Heaven knows, we'd hate to distract you. We'll just keep plugging along on the stuff that actually available now, I guess...
On Fri, Mar 28, 2008 at 11:02 PM, Dan Morrill <morri...@google.com> wrote:
> On Fri, Mar 28, 2008 at 11:00 PM, Dan Morrill <morri...@google.com> wrote:
> > I betcha the other 8,463 current members of this forum would disagree > > with you. But then, every forum needs a troll, I guess.
> Whoops, I just noticed this went to the Internals list; the 8465 count is > for the Developers list. Sorry about that -- you can pick whether you want > to add them up or just take the larger number. ;)
Oh, it doesn't make any difference to me, Dan, take your pick. Certainly there's plenty of overlap between the lists, and it seems sure that not everyone on the lists is a developer, much less a professional one. I see an awful lot of "Can I put Android on my iPhone/Treo/Nokia N95...?"
Of course, there's a variety of perspectives. Chris Glover, who* is* a long-time professional Java developer, has an interesting one on his blog<http://www.jroller.com/complier/date/20080204>.
> The open source community at large, historically speaking, *hates *"code > dumps" (aka "toss-it-over-the-wall-ware") *especially *extremely huge > ones.
Yeah, that's definitely on our minds. We feel pretty bad that we've got such a huge pile of changes that we haven't been able to send upstream. We understand how open source projects operate, and we'll work with the specific upstream teams to send them our code in whatever way works best for them.
Implicit in your observation is that large dumps are a lot of work. It would be pointless and rude to dump a huge pile of changes on a project all at once. Waiting until we can do a good job of releasing the source also means waiting until we can dedicate the attention to the upstream projects that they deserve.
Evidently the existing work in the open source community wasn't good enough
> for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, for > the LiMo Foundation and numerous others.
You seem to be saying that open-source is a zero sum game, and that effort we spend on Android somehow detracts from those other projects. By your argument, Linus Torvalds was wrong in creating Linux; he should have bit the bullet and contributed to Minix, instead.
We believe that the more open source code is out there, the better.
We'll just keep plugging along on the stuff that actually available now, I
> guess...
Please do! The last thing we want is to force developers to pick a single platform.
> > The open source community at large, historically speaking, *hates *"code > > dumps" (aka "toss-it-over-the-wall-ware") *especially *extremely huge > > ones.
> Yeah, that's definitely on our minds. We feel pretty bad that we've got > such a huge pile of changes that we haven't been able to send upstream. We > understand how open source projects operate, and we'll work with the > specific upstream teams to send them our code in whatever way works best for > them.
Well, good luck with that. Which "upstream teams" do you think will be taking on Surface Manager, Binder, Dalvik and the remainder of the never-before-seen portions of the platform (i.e. almost all of it), I wonder...
> Implicit in your observation is that large dumps are a lot of work. It > would be pointless and rude to dump a huge pile of changes on a project all > at once. Waiting until we can do a good job of releasing the source also > means waiting until we can dedicate the attention to the upstream projects > that they deserve.
Sounds like these "upstream projects", whoever you imagine them to be, may be waiting a while. I'm not sure how something like Surface Manager or Dalvik can be released, other than to effectively "dump a huge pile of changes" into some entirely *new *project... They certainly seem to have no relation to any existing "upstream project".
> Evidently the existing work in the open source community wasn't good > > enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, > > for the LiMo Foundation and numerous others.
> You seem to be saying that open-source is a zero sum game, and that effort > we spend on Android somehow detracts from those other projects. By your > argument, Linus Torvalds was wrong in creating Linux; he should have bit > the bullet and contributed to Minix, instead.
No, that's not what I'm saying. Remember, Linus started Linux for his own edification and amusement, "just for fun", as he put it. There was not nearly the mature open source community in 1992 that there is today. If there were, and if Minix had a significant community around it, then yes, I'd think it might well make more sense for Linus to have worked with that community rather than start a whole new effort from scratch. You're comparing apples and oranges here.
What I'm saying it that--to take Surface Manager as an example--the folks most qualified (outside of Google) to do continuing work on such a project are *already *working on GTK+ or Qt or compiz or something similar. I don't see that they're going to be interested in dropping those efforts to help Android's Surface Manager out. They may be interested in taking *pieces *of it to improve specific aspects of GTK or Qt, and thanks to the "developer friendly" Apache license, you won't really be able to keep them from doing so. None of that's likely to help Surface Manager for Android.
There's a finite number of folks working on open source platform development today, that's a simple fact. In order to get those developers to work on Surface Manager, they'd presumably have to free up some time from their current efforts. I'm saying that I believe they're unlikely to do so. So, in a sense, it *is *a "zero-sum game", but not in the way that you're suggesting.
> We believe that the more open source code is out there, the better.
Well, I don't think it's a simple numbers game. I'd suggest that quality, and consonance with existing efforts is at least as important as the sheer number of lines of code out there. There's no shortage of moribund projects. Functionally, Android is in large part duplicative of existing efforts.
Of course, until it's released, the quality of Android's underlying code is unknown and unknowable. As far as consonance with existing projects, there isn't any, and deliberately so--as I said, that was a completely conscious decision that Google made. This is what I mean about Google's unwillingness to work with the existing development communities preferring instead to go the "massive code dump" route.
> We'll just keep plugging along on the stuff that actually available now, I > > guess...
> Please do! The last thing we want is to force developers to pick a single > platform.
Well, not that you *could, *even if you wanted to. But if you don't want to "force developers to pick a single platform", why have you created a platform to (or from) which it's effectively impossible to port existing code, and on which one can't use existing languages, frameworks and APIs...?
When we looked at the other [mobile] Linux activities out there, oftentimes they're initiatives that are based on Linux but their resulting platforms aren't completely open. Or they're completely open and they're Linux, but they're missing most of the things that [Android has]. They probably don't have video codecs, Midi sequencer, speech recognition. So they're not a complete phone stack. The goal with Android was to build into it everything you needed to release a phone: an entire stack to build a competitive smartphone or high-end feature phone.
So, why couldn't Google provide just the missing, un-free pieces, for the benefit of existing projects, and work with the community to make improvements where Google felt they were needed, *with *the community. Why the necessity to come out with a whole new platform to go along with them?
Also, does this suggest that, for instance, Nuance (for instance) is going to be somehow giving away their speech recognition software for free to the world at large, turning what's now proprietary into an open source project? Does it mean that Google is going to somehow pay the patent and licensing fees on behalf of the rest of the world to be able to provide "free" video codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, for starts, would be happy to hear about it...)
I'm a little skeptical of either of those things happening, actually. Please correct me if I'm mistaken here.
> On Sat, Mar 29, 2008 at 3:04 AM, Dan Morrill <morri...@google.com> wrote:
> > 2008/3/29 Stone Mirror <stonemir...@gmail.com>:
> > > The open source community at large, historically speaking, *hates *"code > > > dumps" (aka "toss-it-over-the-wall-ware") *especially *extremely huge > > > ones.
> > Yeah, that's definitely on our minds. We feel pretty bad that we've got > > such a huge pile of changes that we haven't been able to send upstream. We > > understand how open source projects operate, and we'll work with the > > specific upstream teams to send them our code in whatever way works best for > > them.
> Well, good luck with that. Which "upstream teams" do you think will be > taking on Surface Manager, Binder, Dalvik and the remainder of the > never-before-seen portions of the platform (i.e. almost all of it), I > wonder...
> > Implicit in your observation is that large dumps are a lot of work. It > > would be pointless and rude to dump a huge pile of changes on a project all > > at once. Waiting until we can do a good job of releasing the source also > > means waiting until we can dedicate the attention to the upstream projects > > that they deserve.
> Sounds like these "upstream projects", whoever you imagine them to be, may > be waiting a while. I'm not sure how something like Surface Manager or > Dalvik can be released, other than to effectively "dump a huge pile of > changes" into some entirely *new *project... They certainly seem to have > no relation to any existing "upstream project".
> > > Evidently the existing work in the open source community wasn't good > > > enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, > > > for the LiMo Foundation and numerous others.
> > You seem to be saying that open-source is a zero sum game, and that > > effort we spend on Android somehow detracts from those other projects. By > > your argument, Linus Torvalds was wrong in creating Linux; he should have > > bit the bullet and contributed to Minix, instead.
> No, that's not what I'm saying. Remember, Linus started Linux for his own > edification and amusement, "just for fun", as he put it. There was not > nearly the mature open source community in 1992 that there is today. If > there were, and if Minix had a significant community around it, then yes, > I'd think it might well make more sense for Linus to have worked with that > community rather than start a whole new effort from scratch. You're > comparing apples and oranges here.
> What I'm saying it that--to take Surface Manager as an example--the folks > most qualified (outside of Google) to do continuing work on such a project > are *already *working on GTK+ or Qt or compiz or something similar. I > don't see that they're going to be interested in dropping those efforts to > help Android's Surface Manager out. They may be interested in taking *pieces > *of it to improve specific aspects of GTK or Qt, and thanks to the > "developer friendly" Apache license, you won't really be able to keep them > from doing so. None of that's likely to help Surface Manager for Android.
> There's a finite number of folks working on open source platform > development today, that's a simple fact. In order to get those developers to > work on Surface Manager, they'd presumably have to free up some time from > their current efforts. I'm saying that I believe they're unlikely to do so. > So, in a sense, it *is *a "zero-sum game", but not in the way that you're > suggesting.
> > We believe that the more open source code is out there, the better.
> Well, I don't think it's a simple numbers game. I'd suggest that quality, > and consonance with existing efforts is at least as important as the sheer > number of lines of code out there. There's no shortage of moribund projects. > Functionally, Android is in large part duplicative of existing efforts.
> Of course, until it's released, the quality of Android's underlying code > is unknown and unknowable. As far as consonance with existing projects, > there isn't any, and deliberately so--as I said, that was a completely > conscious decision that Google made. This is what I mean about Google's > unwillingness to work with the existing development communities preferring > instead to go the "massive code dump" route.
> > We'll just keep plugging along on the stuff that actually available > > > now, I guess...
> > Please do! The last thing we want is to force developers to pick a > > single platform.
> Well, not that you *could, *even if you wanted to. But if you don't want > to "force developers to pick a single platform", why have you created a > platform to (or from) which it's effectively impossible to port existing > code, and on which one can't use existing languages, frameworks and APIs...?
> When we looked at the other [mobile] Linux activities out there, > oftentimes they're initiatives that are based on Linux but their resulting > platforms aren't completely open. Or they're completely open and they're > Linux, but they're missing most of the things that [Android has]. They > probably don't have video codecs, Midi sequencer, speech recognition. So > they're not a complete phone stack. The goal with Android was to build into > it everything you needed to release a phone: an entire stack to build a > competitive smartphone or high-end feature phone.
> So, why couldn't Google provide just the missing, un-free pieces, for the > benefit of existing projects, and work with the community to make > improvements where Google felt they were needed, *with *the community. Why > the necessity to come out with a whole new platform to go along with them?
> Also, does this suggest that, for instance, Nuance (for instance) is going > to be somehow giving away their speech recognition software for free to the > world at large, turning what's now proprietary into an open source project? > Does it mean that Google is going to somehow pay the patent and licensing > fees on behalf of the rest of the world to be able to provide "free" video > codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, > for starts, would be happy to hear about it...)
> I'm a little skeptical of either of those things happening, actually. > Please correct me if I'm mistaken here.
> -- > 鏡石
-- take care, Muthu Ramadoss. Founder, IntelliBitz Technologies.
> Interesting discussion or dare I say different perspectives ;)
*I* think it's interesting, and we *definitely *have different perspectives. Dan, apparently, thinks I'm "a troll" for disagreeing with *his * perspective.
> Well, good luck with that. Which "upstream teams" do you think will be > taking on Surface Manager, Binder, Dalvik and the remainder of the > never-before-seen portions of the platform (i.e. almost all of it), I > wonder...
Er... we don't expect anyone to; we will maintain them ourselves.
Android consists of several totally new components such as those you listed, and some patches for existing upstream projects (such as Apache Harmony.) Our engineering teams will maintain our original components going forward; we don't expect any third parties to assume ownership of these. When I said that we're sad about having to sit on a large backlog of upstream patches, I was referring to those projects whose software we've used in Android.
Android 1.0 is the beginning, not the end, for our engineers.
> There's a finite number of folks working on open source platform > development today, that's a simple fact.
Finite, but constantly changing. Once we've cleaned up the source and "push the button" to release it, that number will jump upward by the size of our engineering teams. We aren't expecting to poach developers from other projects. We intend to grow the open-source community in every sense.
So, why couldn't Google provide just the missing, un-free pieces, for the
> benefit of existing projects, and work with the community to make > improvements where Google felt they were needed, *with *the community. Why > the necessity to come out with a whole new platform to go along with them?
An excellent question! This is a technical question, though, not an open-source one. The short version is that we think desktop-based environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of building applications, and Android's framework is designed explicitly for mobile applications.
In other words, Android has two goals: First, to be an excellent mobile platform on its merits, and second, to be open and open-source. We decided the existing efforts didn't meet our needs, so we designed one that does.
Also, does this suggest that, for instance, Nuance (for instance) is going
> to be somehow giving away their speech recognition software for free to the > world at large, turning what's now proprietary into an open source project?
That is correct: Nuance's speech-recognition engine will be open-sourced. I believe that's one of the things that will be Apache 2.0 licensed.
> Does it mean that Google is going to somehow pay the patent and licensing > fees on behalf of the rest of the world to be able to provide "free" video > codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, > for starts, would be happy to hear about it...)
Also correct: the source will be released for the media framework, and the codecs. As you say, in some cases there are patent licenses that need to be acquired. I am not involved in the business side of the project, so I don't know what the situation there is, but the traditional industry model in these cases is that the manufacturer, carrier, or retailer pays the license on a per-unit basis.
> *I* think it's interesting, and we *definitely *have different > perspectives. Dan, apparently, thinks I'm "a troll" for disagreeing with *his > *perspective. > ='(
Actually, I thought you were a troll because you frequently seem to have an agenda and say the same things over and over. I now see that you just had a lot of questions and feedback, and had not found a thread to discuss them. You've made some great points, so it looks like I was wrong -- I'm sorry about that.
> > *I* think it's interesting, and we *definitely *have different > > perspectives. Dan, apparently, thinks I'm "a troll" for disagreeing with > > *his *perspective. > > ='(
> Actually, I thought you were a troll because you frequently seem to have > an agenda and say the same things over and over. I now see that you just > had a lot of questions and feedback, and had not found a thread to discuss > them. You've made some great points, so it looks like I was wrong -- I'm > sorry about that.
> > Well, good luck with that. Which "upstream teams" do you think will be > > taking on Surface Manager, Binder, Dalvik and the remainder of the > > never-before-seen portions of the platform (i.e. almost all of it), I > > wonder...
> Er... we don't expect anyone to; we will maintain them ourselves.
Well, that's realistic, anyway.
> Android consists of several totally new components such as those you > listed, and some patches for existing upstream projects (such as Apache > Harmony.) Our engineering teams will maintain our original components going > forward; we don't expect any third parties to assume ownership of these. > When I said that we're sad about having to sit on a large backlog of > upstream patches, I was referring to those projects whose software we've > used in Android.
Aha. Well, as I said, best of luck with getting those accepted, hope the effort doesn't make you any sadder. It did Nokia, and all they had were 50,000 lines of actual improvements to GTK... Like I said, projects hate code dumps, even worthwhile ones.
> Android 1.0 is the beginning, not the end, for our engineers.
From the sound of things, and how!
> > There's a finite number of folks working on open source platform > > development today, that's a simple fact.
> Finite, but constantly changing. Once we've cleaned up the source and > "push the button" to release it, that number will jump upward by the size of > our engineering teams. We aren't expecting to poach developers from other > projects. We intend to grow the open-source community in every sense.
That's good to hear, too, even if it does guarantee a fairly inward-looking, insular, community, at least for a while.
> So, why couldn't Google provide just the missing, un-free pieces, for the > > benefit of existing projects, and work with the community to make > > improvements where Google felt they were needed, *with *the community. > > Why the necessity to come out with a whole new platform to go along with > > them?
> An excellent question! This is a technical question, though, not an > open-source one. The short version is that we think desktop-based > environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of > building applications, and Android's framework is designed explicitly for > mobile applications.
Hm. I guess efforts like GNOME Mobile, Ubuntu Mobile, Moblin, GPE Phone Edition, the LiMo Foundation platform, Maemo, OpenMoko and a variety of others are just kidding themselves. They're all using GTK+, and I'd thought they were managing pretty well with it.
Perhaps you're confusing GTK+, an interaction stack, with GNOME, a desktop program, or with the various window managers it can utilize. There's nothing specifically "desktop-based" about GTK that I'm aware of (although the widget libraries need work for smaller screens, something that's again, already being addressed in the open source community). It works quite well for mobile devices with a window manager (also open source) like matchbox.
Can you be more specific about the technical issues you saw? If nothing else, they'd be excellent feedback for the GTK+ community. (I.e., I wouldn't mind hearing the "long version".)
> In other words, Android has two goals: First, to be an excellent mobile > platform on its merits, and second, to be open and open-source. We decided > the existing efforts didn't meet our needs, so we designed one that does.
Again, no one seems to be clear on just why "existing efforts didn't meet [your] need". "Fighting fragmentation" by introducing a whole different fragment seems a little odd.
> Also, does this suggest that, for instance, Nuance (for instance) is going > > to be somehow giving away their speech recognition software for free to the > > world at large, turning what's now proprietary into an open source project?
> That is correct: Nuance's speech-recognition engine will be > open-sourced. I believe that's one of the things that will be Apache 2.0licensed.
Now, *that's *interesting. Is Google going to acquire Nuance or something? While I'm sure companies like Samsung, who are paying license fees for the use of that software now, will be gratified to save the money, I don't see how that leaves much of a business model for Nuance. Maybe I missed something.
Is the TAT framework going to be open sourced as well? And Esmertec's Java VM? Sounds like serious money savings in store for the mobile industry at large, if so, but it'd seem to throw the futures of the companies making their livings with those technologies into some doubt...
> Does it mean that Google is going to somehow pay the patent and licensing > > fees on behalf of the rest of the world to be able to provide "free" video > > codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, > > for starts, would be happy to hear about it...)
> Also correct: the source will be released for the media framework, and the > codecs. As you say, in some cases there are patent licenses that need to be > acquired. I am not involved in the business side of the project, so I don't > know what the situation there is, but the traditional industry model in > these cases is that the manufacturer, carrier, or retailer pays the license > on a per-unit basis.
Indeed. And passes that cost along to the end user in some way or other. But you seem to contradict yourself: if Google's acquiring the patents and releasing source for the codecs, why would anyone need to pay a license anymore....? Maybe I missed something in there.
Of course, one of the big questions is that, given the non-reciprocal nature of the Apache license, what's to keep anyone from incorporating any improvements they might find in Surface Manager into GTK, or re-purposing those now-free (maybe?) codecs for use with Gstreamer, or getting the now-libre Nuance voice recognition integrated into, say, the LiMo platform...? It'll be dandy for all those projects I mentioned previously, maybe not so helpful for Android: there are a lot more developers working on GNOME-related technologies than Google's likely to be donating to the community to support Android *per se*... Maybe Google doesn't mind if that happens...
> That's good to hear, too, even if it does guarantee a fairly > inward-looking, insular, community, at least for a while.
Yes, that's one possible outcome. The questions you're asking are on our minds, too, but at the end of the day we're just going to have to get the code out there and then work through it. We realize this is a process, not something that happens overnight. We aren't going to send somebody an email and then expect to see patches committed by the next morning.
(I.e., I wouldn't mind hearing the "long version".)
I'd be happy to talk about it -- although I propose a new thread. :) Care to start one?
> Is Google going to acquire Nuance or something?
I'm not familiar with the specifics of the relationship with Nuance. I do not believe that a merger or anything like that is involved, but I am not informed as to what the details are.
Instead let me describe the Alliance in general terms. The purpose of the Alliance is that members join to contribute something that fills a specific need. That is, it's not a consortium in the sense where joining amounts more or less to expressing your interest and support of a particular effort. The Alliance is more like the "core team" of an open source project. Each member contributes something specific and important to Android. In some cases that means source code, in others it means expertise.
For instance, Nuance is contributing a voice-recognition engine to open-source, while TAT is contributing their expertise in UI design. Google is contributing Dalvik (among lots of other software) and staff to handle things like marketing and answering questions in the android-internals forum. ;)
Is the TAT framework going to be open sourced as well? And Esmertec's Java
> VM?
I am not familiar with TAT's products, so I don't know what you mean by "the TAT framework." TAT is designing the UI for Android, and their designs are being implemented directly on the Android APIs. I am aware of Esmertec's product line, but I know nothing at all about the details of their contribution to the Alliance, so I can't answer that question.
if Google's acquiring the patents and releasing source for the codecs, why
> would anyone need to pay a license anymore....? Maybe I missed something in > there.
I don't think you missed anything, it's just messy. :) We plan release the source; patent rights to actually sell a phone using them are a separate matter. I will ask our attorney and see if I can get a more detailed answer to this.
> Of course, one of the big questions is that, given the non-reciprocal > nature of the Apache license, what's to keep anyone from incorporating any > improvements they might find in Surface Manager into GTK, or re-purposing > those now-free (maybe?) codecs for use with Gstreamer, or getting the > now-libre Nuance voice recognition integrated into, say, the LiMo > platform...? It'll be dandy for all those projects I mentioned previously, > maybe not so helpful for Android: there are a lot more developers working on > GNOME-related technologies than Google's likely to be donating to the > community to support Android *per se*... Maybe Google doesn't mind if that > happens...
Yes, you've got it exactly -- and not only do we not mind, we'd love to see it happen. As a general rule, Google prefers the Apache 2.0 license, because we believe it's the most progressive and flexible license available. We want to make it easy for everyone to benefit, including LiMo and other projects. We believe we've got a very solid product and we're going to work hard to be very competitive, but we know better than to assume that we're the only ones who can create something cool.
There is no doubt that the patch situation is going to be interesting. We (Google) don't expect that any project upstream from us would accept giant code dumps from us, just like we probably wouldn't accept giant code dumps from someone downstream from us. The way Android has been developed so far definitely creates some challenges in the way we'll be able to interact with code maintainers upstream from us, we're aware of those challenges and don't expect them to be overcome without some significant and lengthy effort from our side.
Just like anyone contributing to upstream open-source projects, we totally expect that project maintainers upstream from us will want to see cleanly separated patches that each implement a single additional functionality, and they'll want each of those patches to come with documentation, code reviews, additional tests, and test results that are consistent with the standards set by those projects. And we will expect the same from people downstream from us who want to contribute back to us. None of that is fundamentally specific to Android being open-source, and such process constraints can be expected in any well-run software project, whether Google's or not, whether open-source or not.
Going further, we don't, can't, and shouldn't believe that every single one of the changes that we made is going to be suitable for inclusion upstream. I fully expect some of our changes to be fundamentally specific to Android, and fully expect that we will decide that we prefer Android to have those changes while the code maintainers upstream would rather not have those changes in their code. There's nothing wrong with that, and it won't prevent us from collaborating with projects upstream from us in order to avoid drifting and forking. The same is true for projects downstream from us. And if drifting and forking turns out to be the both options, we'll do it or we'll let it happen downstream from us.
There are a few differences between Android (and in fact most cell phone environments) and desktop environments.
As an example, tasks that involve cooperation between multiple applications on the desktop typically involve copy-paste, drag-and-drop, or files that have to be explicitly saved and re-opened. On a mobile phone, it's usually considered more natural to create stacks of "screens" (the Android Activities).
Also, desktop frameworks aren't necessarily prepared for the notion that there might not really be enough memory to hold multiple application processes in RAM, or (worse) for the fact that there might not even be enough RAM to hold all the screens of a single application at the same time. It is definitely correct for desktop frameworks to assume that there is enough RAM for most situations, and that the presence of a hard drive (and therefore of a swap file) will allow performance to degrade gracefully when memory utilization increases; in a vast majority of cases it is enough to let the OS (and by that I mean the kernel) take care of managing the system's RAM on its own. In a mobile environment, those assumptions don't really hold: there's not enough RAM, you can't assume that there's a lot of mass storage (and if there is you have to assume that it's either slow and prone to wearing out, like flash, or so power-hungry that you can't have it available at all times, like a hard drive); because of that, desktop software running in mobile environment tends to me more likely to corner itself into tight memory situations and to not degrade very gracefully when conditions get tight.
In those two cases, I believe that we felt that it made little sense to try to reconcile the two approaches: we believe that both are quite correct given their constraints, but that they are too different to be both embodied in a single unified framework.
You'll also notice some other differences between Android and typical desktop environments, though I won't claim that they're fundamental (but they're more consistent with the way mobile phones typically work):
-applications running within Android are quite protected from one another, more than you typically find in desktop environments.
-Android prefers to hide the fact that there's a hierarchical filesystem and prefers to manage lists of media files regardless of their location.
In the end, we'll all have learned something. Maybe we'll see memory sizes on cell phones grow so dramatically that traditional approaches to memory management become practical on a mobile device. Maybe we'll find that preventing applications from deleting one another's settings is in fact a good thing to have on the desktop and expand that approach out of Android into other environments.
Like you said, it's going to be interesting. Very interesting. I'm personally excited. Very excited.
> On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <morri...@google.com> wrote:
> > 2008/3/29 Stone Mirror <stonemir...@gmail.com>:
> > > Well, good luck with that. Which "upstream teams" do you think will be > taking on Surface Manager, Binder, Dalvik and the remainder of the > never-before-seen portions of the platform (i.e. almost all of it), I > wonder...
> > Er... we don't expect anyone to; we will maintain them ourselves.
> Well, that's realistic, anyway.
> > Android consists of several totally new components such as those you > listed, and some patches for existing upstream projects (such as Apache > Harmony.) Our engineering teams will maintain our original components going > forward; we don't expect any third parties to assume ownership of these. > When I said that we're sad about having to sit on a large backlog of > upstream patches, I was referring to those projects whose software we've > used in Android.
> Aha. Well, as I said, best of luck with getting those accepted, hope the > effort doesn't make you any sadder. It did Nokia, and all they had were > 50,000 lines of actual improvements to GTK... Like I said, projects hate > code dumps, even worthwhile ones.
> > Android 1.0 is the beginning, not the end, for our engineers.
> From the sound of things, and how!
> > > There's a finite number of folks working on open source platform > development today, that's a simple fact.
> > Finite, but constantly changing. Once we've cleaned up the source and > "push the button" to release it, that number will jump upward by the size of > our engineering teams. We aren't expecting to poach developers from other > projects. We intend to grow the open-source community in every sense.
> That's good to hear, too, even if it does guarantee a fairly inward-looking, > insular, community, at least for a while.
> > > So, why couldn't Google provide just the missing, un-free pieces, for > the benefit of existing projects, and work with the community to make > improvements where Google felt they were needed, with the community. Why the > necessity to come out with a whole new platform to go along with them?
> > An excellent question! This is a technical question, though, not an > open-source one. The short version is that we think desktop-based > environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of > building applications, and Android's framework is designed explicitly for > mobile applications.
> Hm. I guess efforts like GNOME Mobile, Ubuntu Mobile, Moblin, GPE Phone > Edition, the LiMo Foundation platform, Maemo, OpenMoko and a variety of > others are just kidding themselves. They're all using GTK+, and I'd thought > they were managing pretty well with it.
> Perhaps you're confusing GTK+, an interaction stack, with GNOME, a desktop > program, or with the various window managers it can utilize. There's nothing > specifically "desktop-based" about GTK that I'm aware of (although the > widget libraries need work for smaller screens, something that's again, > already being addressed in the open source community). It works quite well > for mobile devices with a window manager (also open source) like matchbox.
> Can you be more specific about the technical issues you saw? If nothing > else, they'd be excellent feedback for the GTK+ community. (I.e., I wouldn't > mind hearing the "long version".)
> > In other words, Android has two goals: First, to be an excellent mobile > platform on its merits, and second, to be open and open-source. We decided > the existing efforts didn't meet our needs, so we designed one that does.
> Again, no one seems to be clear on just why "existing efforts didn't meet > [your] need". "Fighting fragmentation" by introducing a whole different > fragment seems a little odd.
> > > Also, does this suggest that, for instance, Nuance (for instance) is > going to be somehow giving away their speech recognition software for free > to the world at large, turning what's now proprietary into an open source > project?
> > That is correct: Nuance's speech-recognition engine will be open-sourced. > I believe that's one of the things that will be Apache 2.0 licensed.
> Now, that's interesting. Is Google going to acquire Nuance or something? > While I'm sure companies like Samsung, who are paying license fees for the > use of that software now, will be gratified to save the money, I don't see > how that leaves much of a business model for Nuance. Maybe I missed > something.
> Is the TAT framework going to be open sourced as well? And Esmertec's Java > VM? Sounds like serious money savings in store for the mobile industry at > large, if so, but it'd seem to throw the futures of the companies making > their livings with those technologies into some doubt...
> > > Does it mean that Google is going to somehow pay the patent and > licensing fees on behalf of the rest of the world to be able to provide
I had an impression so far (from whatever publicity Google has done)
that Android is truely open source. In fact I saw statements where it
has been called "open source". But, when I started to look for the
platform code, I could not find any. Surprisingly, on the android
website there is not even a mention about it. At least they should put
their official stand somewhere on the android website. There are
various possibilities. They should clearly mention their stand on the
website.
(1) They do not intend to make it open source
(2) They intend to make it open source - by when?
(3) They are not sure what they want to do?
While trying to get information about this I searched on the web
and found this post. Here I got a clarity on the current status of
android (which I could not get on android website).
Here is my view about what Google is trying to do.
First this text from Android website
"Today, there are 1.5 billion television sets in use around the
world. 1 billion people are on the Internet. But nearly 3 billion
people have a mobile phone, making it one of the world's most
successful consumer products".
After reading the above information, it is not tough to guess what
Google's objective with Android is. Their intention is to catch this
big consumer base of 3 billion people. Google (with their
applications) is already ruling the Desktop world. Now a logical next
step for them would be to rule the embedded world. they have more
reasons to do that because consumer base is continually shifting from
Desktop to Embedded Devices. Today more people opt for Laptops (than
Desktops). Over a next few years more people will opt for embedded
gadgets (than laptops) as these gadgets will become powerful enough to
serve all their needs.
With android Google will achieve the objective of getting their
applications (either applications from Google or applications built
around Google applications) on to the embedded device (starting with
phone). They have decided to call it "open", so that they can leverage
a large work force working for free (from open source developer
community). Their intentions are justified by the fact that they have
only offered an SDK which allows developers to develop applications on
Android - and have released no information on the Android Internals
(other than an architecture diagram).
Google has been clever to announce US$10 million of price money in
various application development contests. This will not only give them
a popularity among developers, but it will also attract more
developers to do work on Android. Again all this price money goes only
to the developers developing application on Android (around Google
Apps) and not to the people who want to work on Android as such (This
again vindicates my view on Google's intentions). The amount of
software development which Google will achieve by throwing away this US
$10 million will be actually worth a few 100 million US$ :-)
Google's policy on Android is no wonder great. It is bound to help
investors who have picked up the Google stock. It is bound to help
every one at Google. It also may (or may not - in the long term) help
the application developers (who intend to work on Android). But for
the developers who are actually interested in working on development
of a mobile platform - this policy really sucks.
I hope I will have a good day :-)
Regards,
Kunal
PS: This is my personal opinion and I do not intend to offend any one
with my opinion. My opinion may or may not match with other people's
opinion (which is the case with every personal opinion). If you differ
in opinion please show the difference by posting what you feel about
it and not by attacking what I feel about it (and not by just
conflicting with what I said.
On Mar 30, 4:47 am, "Jean-Baptiste Queru" <jbqu...@gmail.com> wrote:
> There is no doubt that the patch situation is going to be interesting.
> We (Google) don't expect that any project upstream from us would
> accept giant code dumps from us, just like we probably wouldn't
> accept giant code dumps from someone downstream from us. The
> way Android has been developed so far definitely creates some
> challenges in the way we'll be able to interact with code maintainers
> upstream from us, we're aware of those challenges and don't expect
> them to be overcome without some significant and lengthy effort from
> our side.
> Just like anyone contributing to upstream open-source projects, we
> totally expect that project maintainers upstream from us will want to
> see cleanly separated patches that each implement a single additional
> functionality, and they'll want each of those patches to come with
> documentation, code reviews, additional tests, and test results that
> are consistent with the standards set by those projects. And we will
> expect the same from people downstream from us who want to
> contribute back to us. None of that is fundamentally specific to Android
> being open-source, and such process constraints can be expected in
> any well-run software project, whether Google's or not, whether
> open-source or not.
> Going further, we don't, can't, and shouldn't believe that every single
> one of the changes that we made is going to be suitable for inclusion
> upstream. I fully expect some of our changes to be fundamentally
> specific to Android, and fully expect that we will decide that we prefer
> Android to have those changes while the code maintainers upstream
> would rather not have those changes in their code. There's nothing
> wrong with that, and it won't prevent us from collaborating with projects
> upstream from us in order to avoid drifting and forking. The same is
> true for projects downstream from us. And if drifting and forking turns
> out to be the both options, we'll do it or we'll let it happen downstream
> from us.
> There are a few differences between Android (and in fact most cell phone
> environments) and desktop environments.
> As an example, tasks that involve cooperation between multiple applications
> on the desktop typically involve copy-paste, drag-and-drop, or files that
> have to be explicitly saved and re-opened. On a mobile phone, it's usually
> considered more natural to create stacks of "screens" (the Android Activities).
> Also, desktop frameworks aren't necessarily prepared for the notion that
> there might not really be enough memory to hold multiple application
> processes in RAM, or (worse) for the fact that there might not even be
> enough RAM to hold all the screens of a single application at the same
> time. It is definitely correct for desktop frameworks to assume that there
> is enough RAM for most situations, and that the presence of a hard drive
> (and therefore of a swap file) will allow performance to degrade gracefully
> when memory utilization increases; in a vast majority of cases it is enough
> to let the OS (and by that I mean the kernel) take care of managing the
> system's RAM on its own. In a mobile environment, those assumptions
> don't really hold: there's not enough RAM, you can't assume that there's
> a lot of mass storage (and if there is you have to assume that it's either
> slow and prone to wearing out, like flash, or so power-hungry that you
> can't have it available at all times, like a hard drive); because of that,
> desktop software running in mobile environment tends to me more likely
> to corner itself into tight memory situations and to not degrade very
> gracefully when conditions get tight.
> In those two cases, I believe that we felt that it made little sense to try
> to reconcile the two approaches: we believe that both are quite correct
> given their constraints, but that they are too different to be both embodied
> in a single unified framework.
> You'll also notice some other differences between Android and typical
> desktop environments, though I won't claim that they're fundamental
> (but they're more consistent with the way mobile phones typically work):
> -applications running within Android are quite protected from one
> another, more than you typically find in desktop environments.
> -Android prefers to hide the fact that there's a hierarchical filesystem
> and prefers to manage lists of media files regardless of their location.
> In the end, we'll all have learned something. Maybe we'll see memory
> sizes on cell phones grow so dramatically that traditional approaches
> to memory management become practical on a mobile device. Maybe we'll
> find that preventing applications from deleting one another's settings is
> in fact a good thing to have on the desktop and expand that approach out
> of Android into other environments.
> Like you said, it's going to be interesting. Very interesting. I'm personally
> excited. Very excited.
> > On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <morri...@google.com> wrote:
> > > 2008/3/29 Stone Mirror <stonemir...@gmail.com>:
> > > > Well, good luck with that. Which "upstream teams" do you think will be
> > taking on Surface Manager, Binder, Dalvik and the remainder of the
> > never-before-seen portions of the platform (i.e. almost all of it), I
> > wonder...
> > > Er... we don't expect anyone to; we will maintain them ourselves.
> > Well, that's realistic, anyway.
> > > Android consists of several totally new components such as those you
> > listed, and some patches for existing upstream projects (such as Apache
> > Harmony.) Our engineering teams will maintain our original components going
> > forward; we don't expect any third parties to assume ownership of these.
> > When I said that we're sad about having to sit on a large backlog of
> > upstream patches, I was
