Android and Open Source (ABN) [LWN.net]

Here is a serious criticism of the Android project posted to the Android Blogging Network. "In a successful hybrid open/closed project, the open source releases drive the closed source forks. Witness Apache httpd (open) and IBM httpd (closed). They have the same codebase, and - shockingly - its not the one in IBMs secret dungeons that generates new releases. IBM does do their own set of releases, but they work just like everyone else - by taking changes from the open tree and integrating their closed code. Google works with Android in exactly the opposite way - development is done mainly in secret, and occasionally someone takes the time to audit it and dump a huge, unmanageable set of changes into the open source tree."

to post comments

Android and Open Source (ABN)

Posted Apr 2, 2009 19:09 UTC (Thu) by davidw (guest, #947) [Link] (1 responses)

I don't know... I hit "their hatred of the community" and kind of rolled my eyes. A more objective version of this article might argue that Android is open source, but doesn't have a truly open development community, yet. I think you could make that argument in a sensible way, without all the vitriol and venom. Still though... come on, we're getting a great deal out of Android: we get a an open source system that's got the corporate muscle behind it to actual get it out in front of lots of people and on handsets. If iPhone and OpenMoko are the alternatives, I'll take Android.

Android and Open Source (ABN)

Posted Apr 3, 2009 1:19 UTC (Fri) by dkite (guest, #4577) [Link]

until you find that the only possible way to get anything fixed or
improved is to wait for Google to do it, or to maintain your own patchset.

IBM used to release the code for their bios'.

Derek

Welcome to embedded...

Posted Apr 2, 2009 20:41 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (5 responses)

Without wanting to be a troll, the blog entry merely points out factors that are standard operating procedure for the majority of product-driven embedded work. Google cannot realistically share details of their release schedule - which would divulge market-influencing product release schedules.

Also, customization is still such a large part of building an embedded product, that following, rather than leading, other open source developers working on the same project is really not an option. Time-to-market pressures are had everywhere - so I'm not using that as an excuse. But product-specific features, unlikely to be mainline-able in the short term, are required to get the product out the door.

Would the author have been happier if Google had pushed all code upstream first, before releasing their product. We'd still be waiting for the first phone if they had done that. (And in many cases, just where would "upstream" be?)

Welcome to embedded...

Posted Apr 3, 2009 7:56 UTC (Fri) by forthy (guest, #1525) [Link] (4 responses)

IMHO, "pushing upstream before the product is released" is the wrong answer to this question. Just develop in the open, i.e. in a public accessible VCS. You can't guess when the release of the product is going to happen, because there will be development all the time - as long as you don't announce "feature freeze" or something like that. You don't have to. When you do feature freeze, you create an internal fork, which is not visible, and you forward-port your remaining bug fixes to the external fork (which can continue to develop at the usual pace).

It looks like Google just has to learn how to do that sort of development. Apple had to learn that, too. An awful lot of managers sleep better when all the stuff they do is strictly confidential, no matter if there is any real benefit. There had been rumors that the toilet paper at Intel have "strictly confidential" written all over it ;-).

The main criticism I have on Android is rather different:

You can't distribute native applications, you can only use their JVM, which limits what you can do.
The JVM is interpreted rather than using a JIT. This means applications take more energy to run than necessary.

Welcome to embedded...

Posted Apr 3, 2009 11:25 UTC (Fri) by job (guest, #670) [Link] (1 responses)

Ditto. Also the absence of copyleft worries me. Telcos historically take any opportunity to close down "unnecessary" access to their services. This runs the risk of every provider essentially having a private fork, with all associated problems.

Welcome to embedded...

Posted Apr 6, 2009 20:19 UTC (Mon) by pphaneuf (guest, #23480) [Link]

I think that's on purpose, because if they couldn't close it down, the telcos would never sell products using it, so Android might as well not exist, as far as the general public is concerned.

You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along...

Posted Apr 3, 2009 13:10 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

You can't guess when the release of the product is going to happen, because there will be development all the time - as long as you don't announce "feature freeze" or something like that. You don't have to. When you do feature freeze, you create an internal fork, which is not visible, and you forward-port your remaining bug fixes to the external fork (which can continue to develop at the usual pace).

Who will develop this "enternal fork"? It's kind of catch22 situation: such organization is useless unless there are big, vibrant community not tied to OHA-imposed deadlines and without such organization it's hard to create external developer community. Right now Google enginners are primary driving force behind Android and so there are no people who can continue to develop at the usual pace when feature-freeze is announced.

You can't distribute native applications, you can only use their JVM, which limits what you can do.

I hope it'll change in the future, but I can see why they choose to go this way.

The JVM is interpreted rather than using a JIT. This means applications take more energy to run than necessary.

Not in Android case. They use scheme where applications are started for a short period of time, do small amount of work and then killed. JIT will be detrimental for such usage and will actually suck MORE energy than interpreter. It'll be good idea to have JIT for background processes, but AFAICS it's not a high priority right now.

You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along...

Posted Apr 3, 2009 15:17 UTC (Fri) by forthy (guest, #1525) [Link]

Not in Android case. They use scheme where applications are started for a short period of time, do small amount of work and then killed. JIT will be detrimental for such usage and will actually suck MORE energy than interpreter.

Hm, I've written lightweight JITs that take similar time to compile the code as an interpreter takes to execute it. Unless you have a completely loopfree application, the JIT-ed code is faster. People use these techniques today to JIT even JavaScript. It's a matter of tradeoffs, as usual. I've doing this sort of stuff for about 20 years now. Furthermore, as one comp.arch poster tells us in his footer: A lot in computing has to do with caching. Cache the JITed code, and reuse it later. You basically have to compile once per download. Gigabytes are cheap now, even on mobile phones.

About this catch22-situation: Android is a distribution of various components, like a Linux kernel, WebKit, a JavaVM, and others. Most of that happens outside Google, anyways; all Google does is to adopt to their needs. This part is what should happen in the open, because merging back big lumps of patches is a PITA. The actual Andriod "distribution" itself can happen with whatever schedule Google likes to have.

Ooookay

Posted Apr 3, 2009 5:37 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

It's pretty easy to see it's all nonsense from Google-hater. Let's reprase for a bit, shell we?

FSF isnt doing this out of their love of the community. (That should be obvious from their hatred of the community..) Google is doing this because XXX (and to a lesser degree YYY and company) are paying them to do this. If FSF was doing this for love, it would be working in the open and letting dev teams (either internal or external) fork GCC into the closed source device trees.

Remember: Google only does now what FSF and Cygnus did for TEN YEARS. Situation is almost exactly the same. Check:
1. Closed "real" repository under tight central control (still strue).
2. Private releases for paying customers ahead of public ones (not true anymore, but Cygnus did it for years).
3. Features are not discussed in the open and no information about when releases will be available (again: it's not true anymore, but was true for TEN YEARS: till egcs fork everything occured behind closed doors in FSF).

Heck: QT and MySQL deveopment is done in the same way today - and it's not some fringe one-person projects at all!

So while it'll be great to have things organized differently it's hypocrisy to say "Google is the only one who does this - they must hate the community". They may not love it enough to endanger important project, true, but to say they hate it... is to say many other projects and companies hate the community... and some of them are somehow very successfull in that some community. Is said community full of masochists who love companies which hate it?

Ooookay

Posted Apr 3, 2009 8:11 UTC (Fri) by cate (subscriber, #1359) [Link] (4 responses)

Hmm, but the community choose EGCS and a lot of user went to xemacs. Glibc
was developed in a more open way, outside FSF. (you can still "cp" and
"make" with old program, so in some program the developement was not an
important issue). These was signal that community don't like closed development (and since 15 years).

I think the problem with google are the false expectations. If google started with more a pragmatic way, without tell people that open source was
a big advantage of Android, we were happier with Android. Now I start
thinking that google uses "open source" only as marketing label, and not as
true believe.

Ooookay

Posted Apr 3, 2009 11:21 UTC (Fri) by roberton (guest, #39680) [Link]

I agree that Google can be accused of over-selling the openness of Android, and that this explains some of the criticism of the limitations of the openness. However, just as someone can overstate something, someone can just as easily over-compensate.

Android is by far the most "open" phone OS out there at the moment on a usable phone (sorry Openmoko). By all means lets look for improvements or even alternatives, but I appreciate it for the step forward that it is.

Roberto/.

This is question of time.

Posted Apr 3, 2009 14:59 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Hmm, but the community choose EGCS

It took TEN YEARS - only when criticall mass of outside developers was formed it was feasible to go with open development model.

a lot of user went to xemacs

May be, but emacs is far from being dead and irrelevant.

Glibc was developed in a more open way, outside FSF

Nope. Glibc was developed very much under control of FSF and in pretty closed manner. Linux libc (actually forkog GLibc 1.x) is dead today. Later development switched to more open model (today you can grab snapshot from svn), but commit rights are still pretty much under control of FSF.

These was signal that community don't like closed development

Vocal members of community hate closed development. But it does not mean "community" as whole dislike it. And for open model to work you need a lot of independent contributors.

Now I start thinking that google uses "open source" only as marketing label, and not as true believe.

Open source is not trademark. And from what I Google truly believe in "open source" - but it has different view of what "open source platform is" than you and me. If you are phone developer (HTC, Samsung, Motorola or HP) - you have full control over destiny of your phone. And this is huge advantage over, for example, Windows Mobile. But if you think that Google does not really believe in the "power of Bazaar" - than you are probably correct. But "open source" != Bazaar...

This is question of time.

Posted Apr 9, 2009 3:51 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

This is kind of amusing. glibc's czar for many years has been Uli Drepper, and for much of that period he and RMS were barely on speaking terms. He even put anti-FSF rants in release tarballs a couple of times, even though the FSF held copyright on the code (because Drepper's employer, which was also not in control of Drepper, had a blanket assignment agreement).

The FSF had tight control of glibc? In their dreams.

Try to talk some time with Drepper

Posted Apr 9, 2009 14:01 UTC (Thu) by khim (subscriber, #9252) [Link]

He even put anti-FSF rants in release tarballs a couple of times, even though the FSF held copyright on the code (because Drepper's employer, which was also not in control of Drepper, had a blanket assignment agreement).

And what does it prove? The fact that FSF has think skin? Sorry, but FSF controlled what it wanted to control: licensing issues, mostly. Like it does with GCC today. Drepper and RMS "were barely on speaking terms" because RMS flat out refused to do some things Uli felt sensible: include some code with questionable ancestry, give access to the GLibc development to some people who refused to sign agreements with FSF, etc. On the other hand technical direction of Glibc development were never FSF-dictated. Does it constiture "tight control of glibc", or not? This is in the eyes of beholder, but I can gurantee you that neither Sergey Brin nor Larry Page control technical issues of Adroid development while they do certainly worry about legal issues (where to get license for codecs, how to make it possible to play video and not get sued, etc).

Eating our young

Posted Apr 4, 2009 20:18 UTC (Sat) by robla (guest, #424) [Link] (1 responses)

Google is a big company with a diverse set of managers and developers that run the gamut from "FOSS veteran" to "FOSS skeptic". While Google invites a higher standard applied to itself (that whole "do no evil" thing), it's going to be really difficult to get a batch of people that large to agree on what the "right" thing to do is.

That's not to say that critiques are unwarranted. However, uncharitable, whiny, and entitled screeds like this do the FOSS community no favors. We can't keep them from getting written, but we don't need to give them a bullhorn either. This type of vitriol and assumptions of bad faith should be reserved for patent trolls and other true enemies of FOSS, not for the people that are merely just not doing it right. We can't expect others to follow in Google's footsteps if this is the treatment we heap on Google.

Android, for all of its faults as an "open" platform, is way more open than the norm (iPhone/MacOS, Symbian [for now], Blackberry, and the plethora of other mobile OSs). As FOSS goes from success-to-success, there's going to be more competitive pressure on Google to open up their development processes. For now, though, the competition is largely proprietary.

Android is a new project, and Google has a lot of very smart people, so it's hard to imagine they won't evolve their community processes. If they don't, my presumption is that the licensing is such that a fork can be viable. So, the competitive pressure will come soon enough. In the meantime, let's not eat our young.

BTW, parent post is my long winded way of saying "I agree"

Posted Apr 4, 2009 20:40 UTC (Sat) by robla (guest, #424) [Link]

...with the "Ooookay" comment by khim. The thing I'm calling a "screed" is the Android Blogging Network post