Andy Rubin: Android 4.0 to be open sourced by year end (The H)
Code-named 'Ice Cream Sandwich' (ICS), Android 4.0 was first revealed yesterday (19 October) alongside the new Nexus device, at a joint Google and Samsung event. The new version of the mobile operating system includes features from both the current phone version, 2.3.x "Gingerbread', and the tablet version, 3.x 'Honeycomb'. While it will reportedly work on both large- and small-screen devices, it was only demonstrated on the Galaxy Nexus smartphone."
Posted Oct 21, 2011 1:33 UTC (Fri)
by leoc (guest, #39773)
[Link] (2 responses)
Posted Oct 21, 2011 1:50 UTC (Fri)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
It appears that they plan to eventually release full source to "Ice Cream Sandwich". I guess we'll have to wait to see if anything is missing.
Posted Oct 21, 2011 22:35 UTC (Fri)
by csamuel (✭ supporter ✭, #2624)
[Link]
Posted Oct 21, 2011 8:18 UTC (Fri)
by robert_s (subscriber, #42402)
[Link] (7 responses)
Posted Oct 21, 2011 8:32 UTC (Fri)
by k3ninho (subscriber, #50375)
[Link] (5 responses)
K3n.
Posted Oct 21, 2011 8:44 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Actually it's much simpler: their internal repo contains sources both for open-source and proprietary components. Before open-source part can be released you must carefully review everything and make sure you don't publish things you don't want to publish. This work is not all that problematic, but the last thing you want to do before release is to divert engineering resources to "luxury" tasks. Especially till you are sure you'll have no changes pending which may require synchronized changes in both parts of the package. And you can only be sure there are no such changes some time after release when real users did more testing then Q&A was able to.
Posted Oct 21, 2011 15:46 UTC (Fri)
by robert_s (subscriber, #42402)
[Link] (3 responses)
But that's exactly the problem. They should not be seeing it as a "luxury" task. It should be an inbuilt part of the development process. This is not how things are done in the FOSS world, and until they change the way they see things and repair this culture of "code dumps", they're not going to be seeing any of the advantages people get from the open source model. Open Source will remain just a prestige badge that they can stick on their product, and communities like CyanogenMod will continue to feel (& thus behave) like a bunch of tinkerers & modders, rather than engage with the project like Real Developers.
Posted Oct 21, 2011 16:29 UTC (Fri)
by iabervon (subscriber, #722)
[Link] (2 responses)
Posted Oct 27, 2011 21:17 UTC (Thu)
by rich0 (guest, #55509)
[Link] (1 responses)
I think what everybody wants them to do is just commit their code to a public repository as it is written, like just about any other FOSS project does.
Certainly I prefer an OS that is released as FOSS after the fact to one that is not, it would be better if the actual development process were open as well. You don't wait until everything is perfect to release the code - you release every line as it is written...
Posted Oct 28, 2011 13:36 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Sadly, not everybody. There are open-source developers who really want this and there are partners who don't like the idea at all: they want to separate development from IP issues as much as possible and one simple way of doing it is to commit everything only to internal repo (which is accessible only to people who signed NDA - this means that regular Joe Googler can not see it either). If NDAs are structured to expire when the product is actually released then you don't have IP issues at all - and this is typically as far as most embedded vendors are ready to go. Of course components which require more restrictive NDAs are just not ever released at all - but you can alter your decision at any point. Sure, it's possible to develop in the open while carefully reviewing patches so as to make sure NDA is not violated: this is how Linux-related things are done in server space. But this slows down the pace of development and required additional manpower. In exchange you get what "open source community" is to offer. Is it good trade-off or not? Well, as I've argued elsewhere the answer is: it depends. While "opensource community" is in it's infancy it's more of a hindrance then asset, but as platform matures situation changes. We'll see if Google will change it's development model when it'll make sense or if it'll wait till some kind of fork will become more popular then "real thing".
Posted Oct 21, 2011 11:11 UTC (Fri)
by swetland (guest, #63414)
[Link]
I'd expect to see Ice Cream Sandwhich sources online not long after Nexus Prime is available for purchase.
Sometimes we manage to do this the same day (as has been the case for several Gingerbread (2.3.x) platform updates that have been available when OTA updates for those releases begin). Sometimes the necessary housekeeping takes a little longer.
Posted Oct 21, 2011 8:42 UTC (Fri)
by janneke (guest, #15012)
[Link] (33 responses)
Although Open Source/Free Software without an open/free development
Something like: Open Git Software. Or have several OSI/DFSG freedom
I probably missed a memo from Bruce.
Thanks
Posted Oct 21, 2011 9:10 UTC (Fri)
by khim (subscriber, #9252)
[Link] (32 responses)
Eric did that years ago. The problem you are facing here is more fundamental then you think. It's discussed extensively in the "The Innovator's Solution" (follow-up to bestseller "The Innovator's Dilemma") and is related to Disruptive technology filecycle. The argument goes like this: it's not possible to create "state of the art" technology in a bazaar fashion. To achieve the best possible something (performance, size, power consumption, whatever) you need proprietary technology where all components are tightly coupled. At this stage market rewards pioneers who build everything "in house". But at some point you reach "good enough" state and diversity among the consumers start to reward more bazaar-like approach (because consumers are now ready to use slightly less performing, slightly heavier, etc solutions - if these solutions also include some unique quirk these particular customers like or need very much). This is where bazaar starts to win. It does not make much sense to try to use bazaar model till you crossed the Rubicon - and with open source cathedral model it's usually pretty easy to see when that happened: when bazaar fork of you in-house product becomes preferred over traditional, upstream, version (see egcs, X.org, LibreOffice, etc). CyanogenMod shows great promise, but it'll probably be years before Android will reach state where Cyanogen will be preferred over Google's version by majority of consumers (if it'll ever happen).
Posted Oct 21, 2011 10:22 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (8 responses)
The Cathedral phone maker's ideal is actually not that great for users because it's not for them, it's for the mobile operators, who largely control the market for these devices.
CyanogenMod doesn't need to achieve that ideal, it can head direct for the user's ideal, which is different.
As these ideals diverge, CyanogenMod can afford to be "behind" the phone makers and still come out ahead as far as actual users are concerned.
For example, tethering. CyanogenMod was not the first OS that offered tethered mobile Internet. But for many users CyanogenMod was first to deliver workable tethered Internet at a price they were willing to pay, while the Cathedral was trying to figure out if they could be coerced into buying a new phone, or paying a surcharge to get a service that could technically be delivered to them via an OTA update.
Or consider product lifetimes. For CyanogenMod the reason to de-support phone X or phone Y is either lack of interest (nobody who still has one wants to maintain it) or technical limitations (maybe phone X only has 256MiB of RAM, and that's just not enough for newer code). But for both mobile operators and phone makers, obsolescence is a planned feature. Making the user buy a new phone every 12-18 months is bad for the environment but good for your bottom line. So last year's phone certainly won't get functional improvements, it may not even get bug fixes. This is terrible for the user experience compared to CyanogenMod.
Posted Oct 21, 2011 14:32 UTC (Fri)
by Los__D (guest, #15263)
[Link] (3 responses)
Doesn't seem like they want to, though: http://review.cyanogenmod.com/#change,5677
Posted Oct 21, 2011 14:51 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Oct 21, 2011 16:58 UTC (Fri)
by Los__D (guest, #15263)
[Link]
"This will piss off developers, carriers, and probably Google."
I'm not saying there's anything wrong with that (being locked would be a great step back, esp. now that all seems to open up), but that CM can focus entirely on users is just not true.
Posted Oct 27, 2011 21:24 UTC (Thu)
by rich0 (guest, #55509)
[Link]
They did institute some fine-grained permissions control, but it tends to cause force closes. Others have done it in a way that does not. I think the difference is in willingness to fake API calls - if an app asks for a list of contacts and gets an error it is far more likely to crash than if it simply gets told that your only contact is John Smith and he has no phone number or address.
Posted Oct 21, 2011 19:41 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link] (3 responses)
Posted Oct 22, 2011 0:23 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
Posted Oct 22, 2011 0:24 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
Posted Oct 22, 2011 16:37 UTC (Sat)
by njs (subscriber, #40338)
[Link]
Posted Oct 21, 2011 12:05 UTC (Fri)
by spaetz (guest, #32870)
[Link] (17 responses)
> Eric did that years ago.
Excuse my frankness, but that's simply wrong. What Eric described is an anthropologic observation of an open source project, deriving some general rules from it how OSS works. That's doesn't mean that the term Open Source that Eric coined ensures an open development community. His OSS very well includes MIT licensed stuff that the copyright holder can well hold back as long as he wishes to. In fact, the term Open Source was explicitely coined to don't scare journalists and business people from the word "free".
More along the lines of the original poster's idea is the GPL/AGPL stuff which allows you to get the source code of things you USE.
Also, I challenge you to show me the spot in the Innovations Solution where Chrsitensen mentions proprietary. :-)
Posted Oct 21, 2011 14:21 UTC (Fri)
by Otus (subscriber, #67685)
[Link] (15 responses)
Posted Oct 21, 2011 15:14 UTC (Fri)
by janneke (guest, #15012)
[Link] (14 responses)
It's safe to assume that everyone here read that and no, that's
not what I am after.
As my posting spawned at least two misunderstandings and seems
to involve guess-work, I'll try to clarify.
What I meant by
The freedom, openness and usefulness that goes with getting a snapshot
of the sources once in a while is considerably less than what you get
from an open development community that you can join and invest in?
Posted Oct 21, 2011 15:23 UTC (Fri)
by seneca6 (guest, #63916)
[Link]
Posted Oct 21, 2011 15:27 UTC (Fri)
by Otus (subscriber, #67685)
[Link] (12 responses)
So you want a term to describe an open development process? Again, isn't
Sorry, I think I'm missing something.
Posted Oct 21, 2011 15:46 UTC (Fri)
by janneke (guest, #15012)
[Link] (10 responses)
The term open source was meant as a smart, pr-wise, replacement
Much has changed and I wonder if it is still so smart to apply
You are not going to say: project FOO is open source developed
Posted Oct 21, 2011 16:24 UTC (Fri)
by khim (subscriber, #9252)
[Link] (9 responses)
What's the difference? Gcc was developed for years in cathedral fashion. "General public" had no access to intermediate repos, had no access to Cygnus sources (you needed a support contract to even see that). Heck, even today CodeSourcery develops many features in their own repos! Only later they are submitted upstream. RedHat kernel is developed in similar fashion. Android is nothing special in this regard (except for 3.x fiasco).
Posted Oct 21, 2011 16:42 UTC (Fri)
by JoeBuck (subscriber, #2330)
[Link] (8 responses)
Of course it's true that private companies sometimes develop a GCC improvement for a client and let the client have the code before the general public gets access. But eventually these kind of one-offs either get merged with the official version or they die off, and other developers will often insist on redesign at that point.
Posted Oct 21, 2011 17:04 UTC (Fri)
by khim (subscriber, #9252)
[Link] (7 responses)
And this proves... exactly what? That GCC was driven to bazaar model kicking and screaming? That it was developed for 12 years in exactly the same fashion Android is developed today? From 1987 to 1999 (when 2.8.x effort was abandoned and egcs-based gcc 2.95 replaced it) GCC was developed "behind the closed doors". Indeed the infamous Cathedral vs Bazaar essay uses it as example of cathedral model! Sorry, but realities of today don't change the lessons of the past. Android 1.0 was released about three years ago. Of course "history doesn't repeat itself, but it does rhyme": we can not be sure about timings but if we'll use GCC timeline, for example, then Google Android will rule till about 2016 - when it'll slowly be eclipsed by different kinds of bazaar-like forks.
Posted Oct 21, 2011 18:02 UTC (Fri)
by njs (subscriber, #40338)
[Link] (4 responses)
This is a terrible argument. How GCC *used* to work is not a normative argument for how things should work now -- we've learned stuff in the last few decades.
Posted Oct 21, 2011 21:48 UTC (Fri)
by khim (subscriber, #9252)
[Link] (3 responses)
No. My argument was that most (perhaps all) successful large projects were developed "in a cathedral style" initially. There was small team (sometimes just a single person as in GCC case!) which developed their "vision" - and only later community followed. Where bazaar was tried from the start (things like HURD or MeeGo) the result was often disappointing: when first release was ready to see the world it was usually way too late to fight for the mindshare. Note that some projects switched to "bazaar development" quite early, some were dragged there kicking and screaming, but on the first glance the fatality rate among projects of the first class is lower then among projects of the second class (would love to see statistic which shows otherwise). What does it mean for the esteemed bazaar? Not all that good conclusion: both "stick with cathedral forever" and "switch to bazar ASAP" strategies are losers long-term, but the last one is worse. Easy to understand why, BTW: bazaar gives you more options, but slows down the momentum. If you are in a fierce competition with someone then lost momentum from the switch to bazaar can easily send your project to oblivion. If you are in fact so successful and dominant that even "competing bazaar" on the coattails of your releases can provide valuable artifacts then your leadership may be in jeopardy, but the project itself will probably survive without you.
Posted Oct 21, 2011 22:09 UTC (Fri)
by njs (subscriber, #40338)
[Link] (1 responses)
Err, but most projects fail, and the HURD lost to the canonical bazaar project: Linux.
I think it's pretty uncontroversial that even when talking about "bazaar-style projects", you need a small team to develop the initial version (how else are you going to attract a larger community?), and that it's incredibly valuable to have strong leadership setting the overall vision, shaping community norms, and performing quality control (think how strongly the personalities of people like Linus, Guido van Rossum, Theo de Raadt, Tridge, Larry Wall, ... have affected their respective projects).
But you can have all that while acting in an open way and allowing outsiders to join in. It's not like anyone is asking the Android people to give commit access to everyone with a Google account.
Posted Oct 21, 2011 23:15 UTC (Fri)
by dlang (guest, #313)
[Link]
it doesn't need to be fancy, but if it's not usable the community isn't going to form.
part of being 'usable' includes the ability to build it. When you have 'code dump' releases from companies, it's very common that the initial versions can't be compiled because they were dependant on proprietary stuff (including tools) that aren't part of the release.
If people can compile and start using your release, you have a pretty good chance of surviving. If they can't, you have a struggle ahead.
Posted Oct 23, 2011 9:13 UTC (Sun)
by nedrichards (subscriber, #23295)
[Link]
Posted Oct 21, 2011 18:46 UTC (Fri)
by dbruce (guest, #57948)
[Link] (1 responses)
You're omitting one very big difference - look at the financial and engineering resources of Google vs. those of the GNU project. If Google continues to develop Android seriously, there is no way any open source fork is going to "eclipse" it.
Posted Oct 21, 2011 22:08 UTC (Fri)
by khim (subscriber, #9252)
[Link]
If you don't believe that other companies can ever eclipse Google then it just means that bazaar development will be pointless. But I don't believe that. Yes, Google is about 10 times larger then, for example, RedHat. But Android is not the main Google product and RedHat is not the only company which can decide to develop it. As long as there are important features which can be attractive for all (or at least most) users Google can keep the lead. But there are only so much you can do in this context. At some point you'll ran out of "big" features and "small" features will matter. At this point no single company (not even Google or Microsoft) can compete. You can only fight using courts and format lockins - both venues are not possible for the free software where you can always use yesteryear version to achieve pretty good compatibility.
Posted Oct 21, 2011 15:51 UTC (Fri)
by sciurus (guest, #58832)
[Link]
Posted Oct 23, 2011 14:12 UTC (Sun)
by job (guest, #670)
[Link]
I know esr has a tendency of claiming credit to just about anything but please set this fact straight. According to wikipedia, the term was coined by Christine Peterson.
Posted Oct 21, 2011 16:06 UTC (Fri)
by robert_s (subscriber, #42402)
[Link] (4 responses)
So according to this argument, the Linux kernel doesn't contain any "state of the art" technology?
Posted Oct 21, 2011 16:43 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Sure it does. It's small but important distinction (also explained in "The Innovator's Solution"). Linux as whole is no longer "state of the art" technology. Lost this status years ago, in fact. But it does not mean there are no "state of the art" technologies in Linux! When commoditized platform is moved in new directions quite often you need to introduce some kind of "state of the art" change (some kind of virtualization, the infamous wakelocks or even new filesystem). It happens with Linux regularly. But when you need something "state of the art" in Linux it's usually created in cathedral fashion! New features are not designed piecemeal on the LKML. They are designed by one person (or few persons) in isolation and presented to the wide kernel community when more-or-less complete. Final polishing and debugging... that happens in bazaar fashion. New development? Almost never. Note that it happens despite the fact that such approach is generally frowned upon by kernel developers (they often ask for early reviews, etc)! So no, linux kernel is not an exception to the rule.
Posted Oct 23, 2011 0:01 UTC (Sun)
by robert_s (subscriber, #42402)
[Link] (1 responses)
I would argue that the development of btrfs shows exactly this. Sure, the bulk of it is written by an oracle employee, but it's largely developed out in the open.
Another example might be the continual transformation of Linux (a "general purpose" operating system) into a more and more RT-capable operating system, which, as far I know, is the first time this has ever been done. The general wisdom even states that RT capabilities and general purpose operating systems just don't mix. Again, development is largely done in the open.
"So no, linux kernel is not an exception to the rule."
I'm not saying it's an exception to the rule, I'm saying the rule is bollocks.
Posted Oct 23, 2011 14:46 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Note even close. The problem lies not even with fact that's it's developed by oracle employee. The problem lies with the fact that it's not yet even released! Initially it was planned for eoy 2008 release (and even then it offered little over state-of-the-art reiser4 or state-of-the-art ZFS), but now the development of initial version stretches till 2012 and that's if we'll be lucky. By then we'll be have good, quite solid filesystem - but it'll be of "me too" variety, not even close to "state-of-the-art". Typical result of bazaar development. The general wisdom says that general purpose OS with RT capabilities is called QNX Neutrino and was released over 10 years ago. So, again: good development of "me too" variety. Right - and that's why it so slow. Of course the problem lies not in the fact it's done in the open. The problem lies in the fact that it passes numerous reviews. The end result is probably better code... but it's delivered years after it's "state-of-the-art" expiry date. Just because you don't like rule does not mean it's crazy or stupid. Even your own examples show that it works. Sure, "development in the open" often delivers better result. But it arrives much, MUCH, MUCH later when it's not longer "state-of-the-art" - if it arrives at all. Android had no time (still does not have it, actually: take a look on tablet market) to play bazaar games because there were a lot of alternatives, most of them proprietary (IOS, WebOS, WP7, etc). The only open-source alternatives were Symbian and MeeGo and it's obvious that Symbian just was not good enough and MeeGO was hopelessly late - mostly because it tried to play bazaar: first competitive version is released just recently with N9 and even that is not "real release".
Posted Oct 21, 2011 17:27 UTC (Fri)
by iabervon (subscriber, #722)
[Link]
Now, is he referring to the complete source or just the kernel?
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
Google has always distributed source for the Linux kernel that they use, including their modifications (as they are obliged to by the GPL). They've only been withholding the source to, um, everything else.
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
open sourced by year end
Don't search for the conspiracy where it does not exist
Don't search for the conspiracy where it does not exist
Don't search for the conspiracy where it does not exist
Don't search for the conspiracy where it does not exist
It's a balance, as usual...
I think what everybody wants them to do is just commit their code to a public repository as it is written, like just about any other FOSS project does.
You don't wait until everything is perfect to release the code - you release every line as it is written...
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
Andy Rubin: Android 4.0 to be open sourced by year end (The H)
and most probably was a very big success for the past 10 years
in growing the Free Software ecosystem, has passed its best before
date.
community may have great benefits for Free Software, can't we coin
a term that also ensures such an open development community?
levels (ugh)?
You can certainly try...
Although Open Source/Free Software without an open/free development community may have great benefits for Free Software, can't we coin a term that also ensures such an open development community?
You can certainly try...
You can certainly try...
You can certainly try...
You can certainly try...
"Imma just -2 this now because vendors are already pissed."
"Zodian: basically, we are trying to be a "friendly" distribution while still trying to push things as far as we can get away with. CM is a pretty big project now and it would be quite easy for us to get screwed by any of them."
"and provide cannon fodder for the Man to justify locking more bootloaders"
You can certainly try...
You can certainly try...
Making the user buy a new phone every 12-18 months is bad for the environment but good for your bottom line.
I'm not even sure that's true. If you look at phone prices with and without signing up for a new contract, it looks as if about $20/month of a typical contract is repaying the cost of the phone. But your monthly bill doesn't go down when you move from the long-term contract to month-to-month, which means they're pocketing an extra $20/month. The shiny new phones are a customer loyalty or customer attraction gimmick, not a direct profit center.
You can certainly try...
You can certainly try...
You can certainly try...
You can certainly try...
You can certainly try...
You can certainly try...
It makes the distinction between something developed in a
closed fashion and something developed in an open fashion,
which seems to be what janneke was after.
can't we coin a term that also ensures such an
open development community?
is that I wonder if we should seek to replace the term "Open Source"
(or free software for that matter) for all software that also has
an open development process and open community.
Open-By-Rule? [webmink]
You can certainly try...
You can certainly try...
>
>> can't we coin a term that also ensures such an open development
>> community?
>
> is that I wonder if we should seek to replace the term "Open Source" (or
> free software for that matter) for all software that also has an open
> development process and open community.
that what "bazaar" means as used by esr? Or do you want a new term to
describe such bazaar-developed software?
You can certainly try...
for the term free software. That was probably very successful.
the same term, open source (or free software) to Android as to
Linux, Gcc or LilyPond.
in a bazaar style, but you might call it: <your catchy term for
"open git software" here>; thus stressing the importance and
possibility of joining in the development process?
What's the difference?
Much has changed and I wonder if it is still so smart to apply the same term, open source (or free software) to Android as to Linux, Gcc or LilyPond.
GCC has used a completely open model since the egcs days, and the gcc repository even includes vendor branches (for Red Hat, Google, and others) so that other GCC developers and the public can see the history and code can more easily be merged.
What's the difference?
EGCS days? Ha!
GCC has used a completely open model since the egcs days, and the gcc repository even includes vendor branches (for Red Hat, Google, and others) so that other GCC developers and the public can see the history and code can more easily be merged.
EGCS days? Ha!
Not exactly...
So your argument is that because GCC was developed in a cathedral style until sometime in the mid-nineties, we should therefore be happy about new software being developed in that style now?
Not exactly...
Not exactly...
Not exactly...
EGCS days? Ha!
Not really convincing...
You're omitting one very big difference - look at the financial and engineering resources of Google vs. those of the GNU project. If Google continues to develop Android seriously, there is no way any open source fork is going to "eclipse" it.
You can certainly try...
You can certainly try...
the term Open Source that Eric coined
You can certainly try...
Heh, small, yet important difference...
So according to this argument, the Linux kernel doesn't contain any "state of the art" technology?
Heh, small, yet important difference...
What is there which can be named "state of the art"?
I would argue that the development of btrfs shows exactly this.
Sure, the bulk of it is written by an oracle employee, but it's largely developed out in the open.
The general wisdom even states that RT capabilities and general purpose operating systems just don't mix.
Again, development is largely done in the open.
I'm not saying it's an exception to the rule, I'm saying the rule is bollocks.
You can certainly try...