| |||||||||||||
ELC: Android and the communityELC: Android and the communityPosted Apr 15, 2010 19:04 UTC (Thu) by cdibona (subscriber, #13739)In reply to: ELC: Android and the community by Trelane Parent article: ELC: Android and the community
You mean "Creates a lack of community" that you identify with. I don't want to sound ...well..un friendly, but android may not necessarily want to grow a community like that which you might be used to.
Also, I might ask, which communities of -developers- do you admire that you think that android should model on? A standard distribution?
The word community is nearly totally meaningless without describing what you mean, and more importantly in this context, why you think Android should have that kind of community.
From an intake persepctive, they've worked with, solicited and taken a variety of patches from a community of developers outside of google, but most of these come from developers within the handset, carrier and chipset 'community' more so than some unicorn developer community that everyone seems to have a flavor of in their head.
(Log in to post comments)
ELC: Android and the community Posted Apr 15, 2010 20:41 UTC (Thu) by Trelane (subscriber, #56877) [Link] some unicorn developer community that everyone seems to have a flavor of in their head.Is this Official Google Position, that those outside Google and their official partners are a "unicorn developer community"?!
ELC: Android and the community Posted Apr 15, 2010 22:05 UTC (Thu) by cdibona (subscriber, #13739) [Link]
Nope, but it is hard to address the concerns of people about the lack of community when in fact there is one. It is difficult to even converse about it when one persons community looks like drupal, while another like samba, while still another like the kernel.
ELC: Android and the community Posted Apr 15, 2010 22:25 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the common thing about all those communities is that they do more than just code dumps at every release.
they allow people who are not yet part of the project to see what they are doing, including how and why something is done.
if you only do one checkin per release, then you may as well just publish tarballs, a VCS is of limited help.
This is one huge portion of the problem that is being called out.
ELC: Android and the community Posted Apr 16, 2010 2:44 UTC (Fri) by Trelane (subscriber, #56877) [Link]
Plus, it's hard to winnow out which particular commit broke something; you're stuck with a ginormous monolithic patch. And sadly, not the 2001 type.
It's not quite as bad as tarballs (in the kernel, you'd have to first generate the patch) but it's not far off.
And then the other thing of there are people interested in using the tech in other places (the supercomputing thing in the article above) but are stopped by Google's foot-dragging. This is hardly ideal.
It may be the minimum required, but do you want to just have the minimum pieces of flair?
ELC: Android and the community Posted Apr 20, 2010 19:31 UTC (Tue) by Epicanis (guest, #62805) [Link]
Reminds me of the "what is it with Linux people?" comment from the "Android Open Source and Compatilibility Lead" in the last thread on this topic. There definitely SEEMS to be a firm cultural attitude at Google that they not entangle themselves with "Linux" more than absolutely necessary.
It sounds an awful lot like Google would rather have android be "not Linux" in some fashion, perhaps instead "based on" Linux in the same way that some Disney movies can be said to be "based on a True Story". I hope this is just me being cynical, though.
ELC: Android and the community Posted Apr 15, 2010 20:42 UTC (Thu) by Trelane (subscriber, #56877) [Link] android may not necessarily want to grow a community like that which you might be used to.What kind of community are you trying to grow?
ELC: Android and the community Posted Apr 15, 2010 21:36 UTC (Thu) by Trelane (subscriber, #56877) [Link]
(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.
ELC: Android and the community 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]
In talking with a number of organizations about what's involved in running an open project (hint: more than just licensing), I wrote a blurb at http://mdzlog.alcor.net/2009/10/26/open-vs-open-vs-open-a... to use as a reference.
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.
|
|||||||||||||