Don't search for the conspiracy where it does not exist

Posted Oct 21, 2011 8:44 UTC (Fri) by khim (subscriber, #9252)
In reply to: open sourced by year end by k3ninho
Parent article: Andy Rubin: Android 4.0 to be open sourced by year end (The H)

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.

Don't search for the conspiracy where it does not exist

Posted Oct 21, 2011 15:46 UTC (Fri) by robert_s (subscriber, #42402) [Link] (3 responses)

"but the last thing you want to do before release is to divert engineering resources to "luxury" tasks."

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.

Don't search for the conspiracy where it does not exist

Posted Oct 21, 2011 16:29 UTC (Fri) by iabervon (subscriber, #722) [Link] (2 responses)

The only thing that's worse to do just before release than "luxury" tasks is reorganize the project and add a lot of developers. The right time to do it is just after release, when you're assigning tasks for the next release, and you can say: "First task: put your component into a public repository. Second task: get it to build and work without anything that's not in the public repository. Then start working on new features."

Don't search for the conspiracy where it does not exist

Posted Oct 27, 2011 21:17 UTC (Thu) by rich0 (guest, #55509) [Link] (1 responses)

I don't think anybody is suggesting that they should reorganize or add a lot of developers RIGHT before release.

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...

It's a balance, as usual...

Posted Oct 28, 2011 13:36 UTC (Fri) by khim (subscriber, #9252) [Link]

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.

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.

You don't wait until everything is perfect to release the code - you release every line as it is written...

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".