Hi,
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" <[EMAIL PROTECTED]> 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.
>
> JBQ
>
> 2008/3/29 Stone Mirror <[EMAIL PROTECTED]>:
>
> > On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <[EMAIL PROTECTED]> wrote:
>
> > > 2008/3/29 Stone Mirror <[EMAIL PROTECTED]>:
>
> > > > 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
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Internals" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-internals?hl=en
-~----------~----~----~----~------~----~------~--~---
