[thanks for the shift to android-discuss - this way we don't "pollute" android-developers]
I won't go into as much detail as you did, though you raise some very valid points. In a nutshell, yes, at this point, the level of transparency coming from Google about Android is insufficient to sustain an active Open-Source community for the Android Open-Source Project. In turn, this negatively affects the cross-functional decisions between the developer side of things (i.e. android-developers) and the Android side of things (i.e. android-platform) is unresolved (and that's really the fundamental issue here). Even worse, the lack of transparency at the most basic technical level during cupcake development means that it was realistically impossible for non-Googlers even be able to monitor what was coming at the SDK level and to raise a hand. Some of the underlying reasons for the lack of openness are technical (and we're inching our way toward solutions): as an example, hosting cupcake on a perforce server within Google put a limit on how much openness there could be around the source code for the entire duration of the cupcake project. Some of the underlying reasons for the lack of openness are non-technical, and being merely a technical guy I'm not in a position to discuss them. Some of the reasons are indeed related to resources, but that's not an excuse - within a large project, availability of resources for specific tasks is a matter of prioritization, it's not an on-off switch. As an example, I could personally have spent the last 6 months making changes in the Download Provider (which would have been fairly comfortable), but instead I spent about 4 months dealing with technical open-source issues, and 2 months with stability and performance of cupcake (though somehow it feels liek I did 10 months worth of work during that period). For a list of things that could be improved in the Download Provider, see http://android.git.kernel.org/?p=platform/packages/providers/DownloadProvider.git;a=blob_plain;f=docs/index.html;hb=master#Future_Directions I am convinced, though, that transparency and openness isn't an all-or-nothing bit - there are levels there, and every little step helps climb a tiny little level. Google is the most likely source for many of those steps, but some can also come from non-Googlers. JBQ On Fri, Apr 24, 2009 at 9:20 AM, Mark Murphy <[email protected]> wrote: > > Jean-Baptiste Queru wrote: >> Restricting access to those settings >> through an explicit UI was found to be an appropriate mechanism for >> users to known precisely enough what was going on and to get >> appropriate expectations about battery life. > > Key phrase: "was found". More on that below. > >> Another reason that motivated the change is an overall concern about >> privacy and abuse. There've been concerns that changing settings like >> GPS, data roaming, wifi, airplane mode without the user's explicit >> action for each operation was inappropriate. >> >> Both of those areas were broadly reported by users, by carriers, and >> in the press. >> >> 1.5 addresses those concerns based on the feedback that we're >> received, by putting the user in better control of their phone. > > Let us assume, for the moment, that the implemented solution is the best > solution, or at least the best solution given implementation timetables > and available staff. > > The problem is transparency. > > As is evidenced by several posts on the original thread, we in the > development community have ideas relevant to this area. For example, Mr. > Legendre's post that came in while I was writing this seems like a fine > middle ground between the original implementation and what has > transpired with 1.5. > > Why is the core Android team only getting this input now? Because, as > far as I am aware, NOBODY #(#$)@#(@ ASKED! > > I doubt there are all that many people in the developer community who > actually want to drain the device battery excessively or without user > awareness. Similarly, I doubt there are all that many of us who were > using this stuff to violate user privacy and are left twisting our > handlebar mustaches, cursing those meddling Googlers for foiling our > devious plots. Hence, we are all being punished for the deeds of a few. > > When the problems arose, there were three basic ways of addressing them: > > 1. Ask the developer community "Hey, considering some of you are > (intentionally or inadvertently) screwing the users, any suggestions for > how we can fix this?" In other words, involve us in the design. > > 2. Ask the developer community "Hey, we see these problems, here's our > cut at a solution, any ideas?" In other words, involve us in the design > review. > > 3. Don't involve the community in the design. Considering that > implementation of this sort of thing already happens behind closed > doors, you wind up with what has happened -- we only get to provide > input after the cow has left the barn. > > By your use of "was found" and the rest of the tone around this, I am > assuming management chose door #3. > > Going with #1, or even #2, gives Google some benefits: > > -- You might get some good ideas. While many of us wouldn't pass the > Google entrance exam, we're not all complete morons. I, for one, am a > very incomplete moron. > > -- You might get some people interested in contributing to the development. > > -- You avoid giving the development community the sense that we're all > "the bad guys" in this story, by giving the community a chance to help > police itself rather than, in effect, tarring all of us with the same brush. > > If Google *did* involve some folk in the community on the design (e.g., > by private invitation), that's cool, but you might consider letting us > know that happened. > > I know the core Android team is short-staffed. Short of trying to pump > up Google's stock price, the best way I can see for us in the community > to help with that is to help with the development of Android proper. > However, particularly in cases like this, that can only happen if we are > given the opportunity to help, even if only on a small piece of the puzzle. > > Give piece a chance. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > Warescription: Three Android Books, Plus Updates, $35/Year > > > > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
