(to be clear to you here, I'm not a Google hater. I think GOOG is under a smear campaign from MSFT (e.g. on the privacy front) and I try to defend it when I see it come up.
I really want to love Android and Google; lots of good things have come from Google. But it seems to me that in <i>this particular case</i> you don't want anyone from the "outside" (i.e. outside Google and handset OEMs and carriers) to be let in to the party. From the article, it is clear that this is leading to additional work on your end and generally isolation of Google from the rest of, well, everybody who's not in your list of People Google Cares About. I'm apparently in the group of People Google Doesn't Care About (unless you want money from me). I kind of take offense at that.
Please be clear: what kind of community do you wish to foster with Android? This seems like the key point here.
Posted Apr 15, 2010 22:16 UTC (Thu) by cdibona (subscriber, #13739)
[Link]
Honestly, I'm not sure you can plan your community like that (you can try, but I don't think that's how it works). I consider certain minima to be important:
1) the technical interaction with people outside the project (which we do in spades, but not for every part of the stack)
2) Proper, real, oss licensing so others can even consider taking part without having to contort.
3) An eng staff on the google side that knows that they can work with people outside the company.
What I don't think is my role is to tell the Android team 'you must take a patch' or set some minimum number of patches that must come from 'outside'. They're simply under enough pressure that they don't need me to do that, nor do I think it would be ipso facto reason enough to change what isn't fundamentally broken.
Also, I'm not sure I actually believe in an outside/inside distinction. How is it possible that someone 'outside' can be part of the community? So...."what do you mean by community" is the existential crisis that we must think about, and we should think about it while also making shipping deadlines...
Anyhow, thanks for the kind words regardless. I've tried to not sugar coat this, android and its developers probably are what people want -technically- from a handset project, but there is a clear desire for 'more' that I don't think google will be able to satisfy in the short term. Our priorities are on iterating the os and stack first and everything else second, third and so on.
With hiring and some tweaks of internal processes we might be able to make a few more people happy, so I think that the only thing that will 'fix' this is time. That said, I suspect in 2 years I'll be talking about some practice someone has glommed onto on some google project that they disagree with. But, so long as code is releasing, I'm pretty happy :-)
ELC: Android and the community
Posted Apr 15, 2010 22:32 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
in this case 'outside' means people like the linux kernel developers who don't work for google or the companies that you have decided that you care about enough to consider 'inside'.
a community is not a collection of people and companies that you (google) decide should be part of the community. A community is those people _plus_ others from outside that group who have enough interest in the project to participate (and participate may be testing, documentation, and even bikeshedding as well as submitting code)
in the case of the android kernel modifications, there is lots of evidence that people are interested in being part of the android community, but google appears to be saying that you are not interested in allowing those people to be part of what you have defined as the android community.
ELC: Android and the community
Posted Apr 16, 2010 15:28 UTC (Fri) by mdz@debian.org (subscriber, #14112)
[Link]
I think what you're seeing here is people wanting to see Google move more toward the latter end of this continuum.
ELC: Android and the community
Posted Apr 19, 2010 11:56 UTC (Mon) by lmb (subscriber, #39048)
[Link]
I very recently moved away from a Symbian phone to a Nexus One, partly because (with the exception of MeeGoo, where I didn't find a handset I liked) Android is the closest we currently have to an Open Source environment. I'm throughly impressed with the platform.
It was strange to be paying for applications again after 15 years on Linux! ;-)
I also understand there may be some things like regulatory requirements that make fully open code out of the box a bit difficult in some areas. That's fine, but there are quite a number of areas that shouldn't be affected.
In any case, I encountered a few small bugs - in areas like contact syncing or the mail client, that I thought I could fix. Finding out that the Android code repositories were a few months out of date (and documentation seems to be something that happens to other people) quite put a dent into that.
I could see that, maybe, Google is not actually interested in community contributions; licensing reasons come to mind, or whatever. (Perish the thought that it might be a desire to push people towards paid apps for which Google receives a cut of the transaction.) But, why then make the code fully available at all? What kind of goals are being pursued here?
Sure, for kernel changes, it's a compliance thing. But the whole platform, even code written from scratch, is GPL'ed. I like that, but what's the point? Who benefits from not having a feature-rich calendar or bug-free mailer as part of the base? (Note that the replacement applications I installed for these needs turned out to be free, even without the AdMob crap, so the paid app argument doesn't apply.)
It looks as if Google's position on this platform is somewhat inconsistent, and this creates an expectation mismatch.
ELC: Android and the community
Posted Apr 19, 2010 16:12 UTC (Mon) by jeremiah (subscriber, #1221)
[Link]
Reading between the lines here, it looks like you're all just sling code as fast as you can to meet deadlines and what not. Where as the OSS community generally deals with deadlines a little differently than commercial organizations. There seems to be a little more flexibility in OSS timelines. It can make working with outside people difficult, because you've got problems to solve as opposed to focusing on cleanup, refactoring, and documentation. I'd imagine that a large amount of your communications are offline and in real-space etc. One of the ways we've tried to deal with the internal/external problem is to put someone in charge of it, and only it. Their job is to run around, and figure out WTF is going on, and to make sure that patches and information hit the street faster, without making your over-stressed deep-coders have to worry about it. I'm not saying this is an ideal solution, but might be some food for thought.