LWN: Comments on "Android 4.0 source released"

Android 4.0 source released

jjs — Thu, 17 Nov 2011 13:58:46 +0000

> ome people would like Android to be an open project so that they could participate into it and help shape its future.

Many would, and I would. Cyanogenmod is actually trying to do that. However, in terms of what Google is doing, they made public statements and promises. They carried out those statements. So "delay" is NOT what happened. Delay would be them not delivering ICS.

Whether it's leadership is slightly different, but I point out they ARE doing more than most companies - we might want to be more involved, but at least they ARE dumping the code.

Android 4.0 source released

dw — Thu, 17 Nov 2011 02:50:36 +0000

Any chance of you tarring up the relevant files, or your manifest.git? Can't find any references in the current repo.

Hmm...

jra — Wed, 16 Nov 2011 23:39:15 +0000

"but then later rewrites (Samba3, Samba4) were done in quite Cathedral fashion."

This is not true. Whilst we have architects who know particular subsystems best, the code is still open and hacked on at will by pretty much everyone.

Jeremy.

So far we have two failures...

rgmoore — Wed, 16 Nov 2011 20:39:03 +0000

I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader.

Linus Torvalds might be able to point out a couple. The Linux kernel is a very good example of a project that started out in bazaar mode and developed to become a real leader. GIT is another great example.

Significantly more often open project is born as fork of cathedral project (like GCC, X.org, or OpenOffice.org) when said cathedral is slowed down for one reason or another.

The obvious reason for a cathedral style project to slow down is because something happens to the architect. Top-down management helps to provide focus for the project, but the focus is only as good as the person at the top. If the project leader has a clear, good idea of where the project should go, having strong direction will help to get the project there. But if the leader gets bored or distracted, the project will lose direction. If the leader gets off track with a crazy idea, the project will go off track and focus on that crazy idea.

A bazaar project has the opposite situation. There isn't a single voice telling people what to do, so people are more or less free to pick their own interest. That means you don't have a single clear direction, but it also means the project can't get sidetracked by a single person's mistake. It's good if you have a lot of obvious work to do, like fixing bugs or writing a bunch of drivers for diverse hardware, where individual coders can pursue their personal interests and still add obvious value to the project.

My impression is that the very best projects have a mix of the two modes going on. They have a strong, but often fairly small, core that can push forward new ideas. The core often replaces a single architect with a formal or informal steering committee to avoid the risk of a single leader getting distracted, burned-out, or lost on a tangent. Outside that group, they have a larger set of people who are working on cleaning up and polishing the work done by the core. They take care of things like fixing bugs, writing drivers, translating documentation, creating artwork, etc.

the Elephant in the room

dlang — Wed, 16 Nov 2011 18:51:03 +0000

what about the linux kernel?

Also Cathedral vs Bazaar has less to do with the number of people who are writing the code than it has to do with the barrier to entry for new people writing code (who is allowed to submit code), visibility (how hard is it for someone new to find out what's happening), and to some extent how open the project is to suggestions from outsiders (but this is the hardest part to objectively evaluate)

Android 4.0 source released

xxiao — Wed, 16 Nov 2011 18:43:40 +0000

it's 32 minutes here on i7 4-core(2670) with 8GB memory, i used make -j8 to do it.
it boots up on pandaboard well

Hmm...

spaetz — Wed, 16 Nov 2011 13:20:12 +0000

Seems we just have different definitions of what cathedral and what bazaar is:

You mean by "cathedral" that most code comes from few people. If that is your definition of cathedral I concur, as most if not all projects have 90% of their code written by 10% of the contributors.

I would characterize a Project as a bazaar model that is dominated by a few core coders (who by contributing most of the code, determine most of the architecture), but which is willing to listen and to react to its community, and which is willing to take patches from the outside. Bazaar relates to 2 aspects, transparency (can look) and accessibility (can touch) in my book. If a project exposes all its dirty laundry via public email lists (see Apache's "if it's not in an email it doesn't exist" mantra), that is a bazaar aspect.

So in the end, this boils down to a discussion of how you exactly define cathedral-style :-).

Hmm...

khim — Wed, 16 Nov 2011 13:04:13 +0000

Apache?

Fork of the most popular server.

Samba?

This is borderline case: at the time of The Cathedral and the Bazaar it was already developed by large group of people - but then later rewrites (Samba3, Samba4) were done in quite Cathedral fashion.

GTK?

Similar: initial version was developed buy a couple of guys for their own need and when bazaar style was adopted it was quite established.

There are plenty of examples of both failures and succeses, so I am not sure how useful it is to just mention a few as proof.

Actually I'll be interested in seeing at least one "success story". Most successful projects which are currently developed in bazaar model were initially developed in cathedral manner and only switched to bazaar model when they were well-established and popular.

Android 4.0 source released

oever — Wed, 16 Nov 2011 10:14:18 +0000

I would love to use it on my desktop. It is really a shame that Android applications cannot simply run on the desktop. The whole stack would be much more attractive if it was as easy to do this as it is with QtCreator for the Linux, Mac, Windows and MeeGo.

At the moment, the best strategy to write code that runs on desktops and mobile phones is to use a combination of C/C++ for the core logic on top of whatever the phone/desktop requires. If the C/C++ is written nicely enough it can even be converted to JavaScript and run in a webpage.

So far we have two failures...

spaetz — Wed, 16 Nov 2011 10:02:09 +0000

> We'll see. So far the tack record is not great: failure after failure.

Others have already commented on the fact that Meego has not been an "open project" at all. As for OpenMoko, are you surprised that a technologically inferior geek phone did not conquer the masses?

> I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader. Well, may be KDE - end even then it's leadership is questionable.

Apache? Samba? GTK, Gnome (well for some :-))? There are plenty of examples of both failures and succeses, so I am not sure how useful it is to just mention a few as proof.

Perl is great example...

dgm — Wed, 16 Nov 2011 09:48:06 +0000

The two styles (Cathedral and Bazaar) serve different goals.

Cathedral, that is, one or a few directors and many workers, is the best to start because is the fastest way to get somewhere, when that "somewhere" is well defined. It also requires less resources. The requisite is, obviously, that the leader knows where he wants to go. It also

Bazaar is great for exploration when there's no defined destination. In this style projects usually take a long time to reach anything in particular, but in the mean time many options are tested. It's main benefit is that it's safer in terms of preventing choosing the wrong destination, but also that sometimes unexpected gold is found in an apparent minor branch.

So far we have two failures...

tajyrink — Wed, 16 Nov 2011 09:04:54 +0000

Yes, it might be so, and at least it does a huge promotion of Linux the kernel. Over time Android as a project probably also continues to improve, and can be eventually be truly forked if it gets mature, the modding communities continue to get larger, but Google won't open its governance.

There's also risk that Android has problems lurking in its approach (throwing everything away from top of Linux kernel and not co-operating with other similar projects) and Android goes away, but let's hope it's not so.

Also possible would be that parts of Android would be separated into components of their own, usable by other projects. For example if their mobile phone / modem stuff would triumph over oFono/FSO.

Ah, N9...

tajyrink — Wed, 16 Nov 2011 08:56:16 +0000

Again I find it quite "forum chit chat" level of discussion to argue with you, but to each one of your replies my answer is more or less "you're wrong": N9 is GNU userspace + Linux + freedesktop.org (X, bluez, pulse, gstreamer, etc) + Qt + MeeGo Touch framework, all open source, with proprietary compositor and applications. Can be made by someone else on the same basis, and Nemo Mobile basic UI by the community is already quite nice and smooth - hopefully some vendor would do it as well. Comparison to MacOS X is pure trolling.

MeeGo did not push the same story. Compatible UI comes from the app story API and its selected (single) toolkit, not the system toolkit or eg. compositor technology. And yes I've noticed you're always ready for predictions.

Ah, N9...

khim — Wed, 16 Nov 2011 07:22:22 +0000

To khim: The free/open stack itself is not a failure, the smoothest and most innovative mobile phone of 2011 (Nokia N9) was made with the stack.

Bwa-ha-ha. Sorry, but no. Nokia wanted to sugar-coat it's failure so they took Maemo, replaced open-source UI with proprietary swipe interface and marketed it under Meego name. N9 is cool phone but it's most definitely not the success of "GNU userspace + Linux + freedesktop.org" or even remotely similar. And it's "last one of the kind" anyway.

You can as well say that MacOS X is real triumph of GNU...

Tizen at least seems to have promises that vendors can do their own variations of the stack, contributing to various pieces of open projects, as long as they fulfill the app story as is.

MeeGo pushed the same story - and look how well it flew.

So Samsung can push Enlightenment, others can push Qt, etc.

In other words: you'll not have a compatible UI and you'll have repeat of "Linux Desktop" story all over again.

Diversity and non-fragmentation at the same time, while keeping truly open middleware projects competing against each other.

This is pipe-dream: noone was able to produce anything like that so far. Either you have diversity and fragmentation which attracts tiny slice of market or you have large market share - and diversity then happens too, but it's in individual applications, not in OS variations.

Of course it might go in any direction in the end, but I'm not here to make predictions.

Well, I am. My crystal ball is cloudy today, but I can see only two possibilities:
1. Tizen will be abandoned soon, or
2. It'll linger for years but only few geeks will ever know that it exist.

It's actually similar to gcc 2.96 situation...

khim — Wed, 16 Nov 2011 06:58:19 +0000

One gets the impression that Google, retrospectively, would rather Honeycomb had never happened

Well, it's like RedHat and gcc 2.96: they don't want to support it (even Cygnus people often refused to answer questions about gcc 2.96... and Cygnus was RedHat subsidiary at this point), but they needed it because gcc 2.95 had such a poor C++ support.

Honeycomb is the same way: Google needed it (because otherwise the whole year would be lost), but now they want to switch to ICS as fast as possible.

Both "fiascos" come from the good understanding of the facts of life. Namely the fact that "it'll be ready when it'll be ready" is not the best long-term strategy: sure, the initial release will be better but mindshare will be lost and eventually it'll lead to stagnation of the project.

So far we have two failures...

jcm — Wed, 16 Nov 2011 06:53:04 +0000

Actually, I think Android will wind up doing the most for FLOSS. It will put the software in the hands of millions of actual users and ensure a standards based, stable platform. At the same time more purist FLOSS projects will look at Android and say "hey, wait, why is that working so well?", and after accounting for the size of Google, etc. they might realize that the platform standardization angle is why Android is so successful after all. I think both will ultimately learn from each other. Google is not evil, Google is a big corporation in the business of making money and they know how to do that while offering products based on Open Source that consumers will use.

So far we have two failures...

tajyrink — Wed, 16 Nov 2011 06:41:41 +0000

To jcm: ok, now your wording is much clearer. The biggest confusing part was the place where the words seemed to put open source somehow against GPL, and even though GPL says nothing about requiring open project/governance either.

To khim: The free/open stack itself is not a failure, the smoothest and most innovative mobile phone of 2011 (Nokia N9) was made with the stack. But more importantly: I don't mean the platform couldn't or shouldn't be strictly controlled if companies don't get (and/or want) open governance done right, but that it would be made up of pieces mostly done in open projects instead of one gigantic non-open project like Android put on top of Linux kernel. The platform and its app story needs to be something clear, but it doesn't automatically mean that the components, especially lower level, of the platform should be developed behind closed doors.

So again, Linux + GNU basic tools + freedesktop.org + Qt/EFL/GTK as building blocks of the platform is much better for FLOSS in general than Android (even though Android is a very good thing as well - I'm just discussing, not bad-mouthing Android), even if the platform itself would be very strictly controlled. MeeGo.com was actually very non-open in parts, managed by Intel internally, despite the promises. WebOS was very closed development but freedesktop.org stack, it didn't fly either but not because of these technical reasons. I don't doubt Tizen will be different, and it does not need be. Tizen at least seems to have promises that vendors can do their own variations of the stack, contributing to various pieces of open projects, as long as they fulfill the app story as is. So Samsung can push Enlightenment, others can push Qt, etc. Diversity and non-fragmentation at the same time, while keeping truly open middleware projects competing against each other.

Of course it might go in any direction in the end, but I'm not here to make predictions.

Android 4.0 source released

swetland — Wed, 16 Nov 2011 04:47:59 +0000

The ICS tree is a direct descendant from the HC tree.

Android 4.0 source released

anselm — Wed, 16 Nov 2011 00:01:47 +0000

It's arguably not Google's job to support these devices, but the device makers'. It is they who did put the devices in the field, not Google. Whether the manufacturers are keen on doing more than they would do with most other, and especially non-Android, devices they sell (i.e., nothing) is of course anybody's guess.

One gets the impression that Google, retrospectively, would rather Honeycomb had never happened; not making it straightforward to find out exactly what it consists of is perhaps Google's way of encouraging everybody and especially the device manufacturers to upgrade to Ice Cream Sandwich. I've heard that, resource-wise, ICS is supposed to run on any device that can run Gingerbread, which includes a large number of not-quite-new phones, so this shouldn't be a physical impossibility.

Android 4.0 source released

ajross — Tue, 15 Nov 2011 23:44:13 +0000

Agreed, but that's not really the point. My point was that Red Hat shipped a compiler based off of FSF source, but it was a snapshot that didn't correspond to an actual release. So while you could see the source code in the FSF tree, you'd be SOL if you wanted to track a bug (or whatever) in the compiler based on that alone. Obviously Red Hat did ship source to their compiler (and the GPL required it), but if they didn't, it would have been ... rude, no?

Google has products in the field running software they don't want to support. That's just a mess, and hiding the release tags doesn't make it less so.

Android 4.0 source released

anselm — Tue, 15 Nov 2011 22:09:42 +0000

GCC is under the GPL, which means that people who distribute binaries of GCC forks must also supply the corresponding source code. Android, on the other hand, is almost exclusively not under the GPL, so no such obligation exists on the part of Google and its partners (the handset manufacturers). Google is fairly diligent about publishing source for those parts of Android that they adopted from third parties under the GPL (like the Linux kernel).

Android 4.0 source released

dlang — Tue, 15 Nov 2011 22:01:57 +0000

just upgrade them to ICS

Perl is great example...

khim — Tue, 15 Nov 2011 21:32:28 +0000

Well, Perl and Python actually show my point quite nicely. Even major changes (like Perl4 to Perl5) were done quickly and efficiently when development was driven by a single person (or small tightly-knit team). When Larry decided to do next step using "bazaar approach"... the result was unmitigated disaster. Note that while python2 to python3 transition is not as smooth as many hoped it's still goes much better.

When project is mature enough bazaar development can work just fine (there are numerous examples) but still major refactorings must be done in cathedral manner. Bazaar can fix things, but to create something new you need master. Someone who may say: "no, we will not do X or Y - this is outside of scope of this work". Otherwise feuterism makes advances in development so slow that project either never reaches the "release" state or if it ever does it produces useless chimera (because there are thousand features out of which may be 10% works as advertised, 50% works poorly and the rest are just confusing everyone because noone is sure what they were supposed to do).

Of course if you do have a release and the base is robust you can start adding features (this is where bazaar shines), but BDFL is still good to have around because otherwise features will be added in half-backed state which can eventually kill the project anyway (because at some point features are so intermixed that you can not add anything to this mess). Some projects break apart at this stage, some decide to "reboot the franchise" (like GNOME, KDE, or Netscape/Mozilla/Phoenix^WFirebirn^WFirefox), some do the hard thing and actually clean the code instead (Linux kernel is good example, GCC developers are trying to do that for last few years, LibreOffice is now enthusiastically does that too). It's be interesting to compare fate of "rebooters" to fate of "cleaners" but we don't have enough projects to actually make a good comparison: this is fate of large projects and they all are too unique for the stats to say anything definitive.

So far we have two failures...

Cyberax — Tue, 15 Nov 2011 20:21:44 +0000

Python and Perl? They had a rather open model, though they have their BDFLs.

Android 4.0 source released

ajross — Tue, 15 Nov 2011 18:55:11 +0000

Or just from the perspective of someone wanting to hack their Xoom. Again, there are real devices running this code. It's not an academic problem.

Mmm... Why not?

khim — Tue, 15 Nov 2011 18:34:49 +0000

Thinking back a few years: consider if Red Hat had never made the source of its forked "2.96" gcc available and just told you to figure it out from the FSF source history. Would *that* be acceptable?

Great example, thanks!

How many users do you know who successfully used "gcc 2.96" sources for anything after gcc 3.x release? In time between 2.96 binary release and gcc 3.x release? Well, it was useful on rare occasions. Later? It was just a dead code which hurt people who knew nothing about this fiasco and tried to use it in production instead of gcc 3.x (or gcc 2.95 for the ones who needed stability).

So far we have two failures...

khim — Tue, 15 Nov 2011 18:27:27 +0000

Meanwhile, it's more likely that GNU userspace + Linux + freedesktop.org continues to evolve as a competitor to Android than that Android itself would become an open project.

We'll see. So far the tack record is not great: failure after failure. I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader. Well, may be KDE - end even then it's leadership is questionable.

Significantly more often open project is born as fork of cathedral project (like GCC, X.org, or OpenOffice.org) when said cathedral is slowed down for one reason or another.

So my bet will be with CyanogenMod or some other alternative version of Android rather then "GNU userspace + Linux + freedesktop.org".

Android 4.0 source released

karim — Tue, 15 Nov 2011 18:21:43 +0000

Lenovo W520 (workstation replacement): Quad-core i7 w/ Hyper-Threading, 8GB or RAM and RAID-1 disks (real disks, not solid-state.) It's the best-performing Lenovo I could find.

Android 4.0 source released

ajross — Tue, 15 Nov 2011 17:50:35 +0000

I don't buy that at all. There are devices in the wild running that code, and we need to use forensics to figure out what it is? Thinking back a few years: consider if Red Hat had never made the source of its forked "2.96" gcc available and just told you to figure it out from the FSF source history. Would *that* be acceptable?

Android 4.0 source released

jcm — Tue, 15 Nov 2011 17:25:08 +0000

If you're referring to what I said, I stand by it. Google is taking leadership because they realize that worse than not releasing the code sooner is platform fragmentation caused by people taking their release and inflicting incompatible changes on it. I also did not say Open Source is not GPL, I said that Android is not released under the GPL. They are free to decide when they publish their own code, and under what terms.

I actually think Google is being very pragmatic. Their heart is in the right place when it comes to releasing the code, but they are trying to avoid the zoo that will result if there is too much flexibility for others to create a giant moving target. When users install software from the Market, it needs to "just work". This is where Google have an actual *platform*.

Android 4.0 source released

marcH — Tue, 15 Nov 2011 17:20:17 +0000

> Honestly, some are never going to be satisfied until every git pull comes with a $100 Android Market gift certificate personally delivered by Page and Brin

I guess the same people would complain about dirty carpets if they were offered a car for christmas.

Only 5 years ago, anyone pretending such a successful system would be available as open source some day would have been laughed at. Well done Google.

Android 4.0 source released

cwillu — Tue, 15 Nov 2011 17:01:48 +0000

The GPl doesn't do much to prevent fragmentation, it just makes it possible to fix it eventually. As the ongoing ARM cleanup in the kernel demonstrates, that's still a labour intensive process.

Android 4.0 source released

tajyrink — Tue, 15 Nov 2011 16:40:46 +0000

The comment was answering a quite confused post about taking leadership and saying apparently something that open source means closed development (and that open source "is not GPL"), so the comment was merely pointing out that maybe "taking leadership" was not really to the point.

The delay is the delay where Android is not an open project but a code dump, but Google also admits this. Some people would like Android to be an open project so that they could participate into it and help shape its future. Meanwhile, it's more likely that GNU userspace + Linux + freedesktop.org continues to evolve as a competitor to Android than that Android itself would become an open project.

Android 4.0 source released

clump — Tue, 15 Nov 2011 14:33:28 +0000

You might wish to re-read my comment and the thread it pertains to.

Android 4.0 source released

rvfh — Tue, 15 Nov 2011 14:32:08 +0000

I understand that you want to make things clear, but unfortunately you are fighting people who want to be right when they say Google is bad, no matter that the whole source code for all Android releases is now available from Google (Honeycomb being in Ice Cream Sandwich's history).

I do not always agree with the decisions Google takes on Android, but I fail to see how people can complain about their code releases. They are barking at the wrong tree altogether, when not biting the hand that feeds them.

I have only two words to add: Thanks Google!

Android 4.0 source released

aorth — Tue, 15 Nov 2011 13:54:52 +0000

Curious about the specs on your build system. For posterity's sake :)

Android 4.0 source released

jjs — Tue, 15 Nov 2011 13:35:55 +0000

What delay? They said they would release it when the Google Nexus came out (1st device with ICS) and they did.

Even the GPL does NOT require releasing source before you distribute the binary. And most of ICS (and most of all Android) is not under the GPL, but instead the Apache license (which does NOT mandate source release).

Android 4.0 source released

clump — Tue, 15 Nov 2011 13:05:28 +0000

An open source project that delays source release and then takes steps to make it harder to find the source (Gingerbread) is "taking leadership"?

Android 4.0 source released

jbv — Tue, 15 Nov 2011 08:35:05 +0000

What? Are they only gonna give us $100 for each pull? That's
ridiculous!

Android 4.0 source released

karim — Tue, 15 Nov 2011 06:33:30 +0000

... since the story was posted, JBQ did post a message saying that people can now sync at will: https://groups.google.com/group/android-building/browse_t...

I've finally got my copy and have started toying around. The first and most glaring observation for now is that it took about 55 min to build. Gingerbread takes 20min on the same system ...

Let the fun begin