Thanks J, that is an excellent explanation. Good to know the focus is on getting Android devices into the hands of consumers. While I'd love to see more SDK improvements (like everyone else), without actual devices out there, our dev work isn't going anywhere.
-Andrew Jean-Baptiste Queru wrote: > (Notice: I'm a Google Software Engineer working on Android). > > One aspect which I hope is reasonably clear in everybody's minds is > that getting devices available is really at the top of the priority list for > everyone involved in Android. That's important for the Android team > and for the Open Handset Alliance and its members, that's important > for Google. That's also important for the developer community and for > the end users. > > From that point of view, every day that passes without devices out there > hurts the entire Android ecosystem, and therefore has a high cost. > Because of that, whenever anyone has to choose between doing > something that directly helps ship those first devices and something > that doesn't directly help, the latter option has to carry a very high value > in order to outweigh for the cost of delaying the first devices. That's why > the SDK isn't as polished as it could be, that's why Google employees > aren't as present on those forums as they could be: it would distract > from the primary goal of shipping devices in 2008. > > It might sound surprising to many, but Google only has a finite number > of people who are currently familiar enough with Android to be able to > make a significant difference on either the ship date or the SDK and the > developer community. It takes time and it takes money to grow a team, > Google has a significant amount of money but remains careful about > how they spend it like any well-managed company, and they can't do > anything about time: even by having people work hard, there's always > a limit to how much work any single person can achieve every day. > > All that explains why you're not seeing dozens of engineers spending > several hours every day answering questions and helping people on > the forums, or preparing a new SDK every other week: at the end of the > timeline toward the first devices, that would result in delays that would > be counted in weeks or even months. Having to choose is painful, > because we'd all like to get the best of both worlds. You can't have > your (proverbial) cake and eat it too, and right now we're a bit stuck > between a (proverbial) rock and a (proverbial) hard place. > > > > Back to the issue of the SDK, I think that you've put the finger on one > of one of the aspects that are hard to balance: how early and how often > should it be released. Too early, and developers get some software > that is too unstable and too far from the final product to be valuable. > Not early enough, and developers don't have time to get familiar with > it, provide valuable feedback and have applications ready for the first > device. Too often, and developers will spend too much time chasing > porting their code from one release to another and the whole ecosystem > will be confused about what works and what doesn't in every release. > Not often enough, and some developers will be stuck for weeks on bugs > that may have been fixed but be unavailable. And, like I said earlier, > "early" and "often" have a negative impact on the ship date. > > During the software development cycle of a framework, you're likely to > see 3 phases: bringup, unstable, and stabilization. During the bringup > phase, the software improves quickly, but it is too rough and too far > from its final shape to be valuable to many people - this is a phase > that typically sees frequent releases to a very small number of close > partners. During the unstable phase, the framework is large enough > and is used by enough applications that it can't change quite as quickly > as during the bringup, but it is still getting some very significant changes. > This is the phase during which the release strategy changes from > frequent limited releases to infrequent broad releases. This is the phase > that M3 and M5 came from (as an example, you've all seen how the UI > had changed between M3 and M5). Finally, there's a stabilization phase, > where the framework gets fewer and fewer changes and gets closer and > closer to its final shape. That's the phase when there can be frequent > broad releases, that's the phase during which beta programs happen. > > What you've seen so far was definitely in the unstable phase, and when > such a project gets into a stabilization phase is can make sense to > consider more frequent releases, which in the case of Android must > be weighed against the impact that such releases can have on the > final ship date or on the developer challenge. > > Releasing Android SDKs is harder than it seems while in the unstable > period, because of the number of people and companies who work on > it and who therefore need to synchronize their efforts to reach a point > where every module is reasonable usable at the same time. During a > stabilization phase when fewer regressions happen, it's easier to pick > almost any point in time and to use that as a starting point for an SDK. > > > > I'll wrap up with a third aspect: a view ahead. Even though there seem > to be new mobile phones being released all the time everywhere, if you > look closely things are actually moving fairly slowing in the mobile industry. > Extremely often, a new phone is created by starting with a phone from > the previous generation, fixing a few bugs and changing the color and > the shape of the shell. > > Deep changes happen over much longer timeframes, measured > in years. How long? Well, the project has been going on for a while > already, and the goal remains to have the first devices available by the > end of the year (see the Nov 5 press release). If we assume one major > release every year (which is typical in this industry), that means that there > will be devices running the initial version of Android with ship dates all > the way through 2009. If manufacturers take a year to release new devices > (which is also typical in this industry), we'll see devices running the > original Android being sold on the top shelves all the way through 2010, > and they might still be discounted until 2011 (as models from the > previous year). Once you realize that many devices are used for 2 years > or more (contracts in the US are often for 2 years), you get to the point > where you're essentially looking at a 10-year timeline from start to finish. > That 10-year time scale isn't unique to the original release - in fact I have > worked in the past on major versions 6, 7 and 8 of a mobile framework, > and each of those went beyond the 10-year mark or is on track to get there. > > All that means that, right now, as an external developer, you might have > only seen about 4 1/2 months of the history of Android, and therefore a month > or even a week might seem like a very long time to wait for a new release, in > the big pictures you can count on phones running the original version of > Android to still be in people's pockets 5 years from now, and on that scale > a week or even a month isn't that much. On the other hand, a month or even > a week might be enough to miss the 2008 targets if the devices aren't ready > on time. > > JBQ > > On Sat, Mar 29, 2008 at 4:25 AM, Rui Martins <[EMAIL PROTECTED]> wrote: > > > > The biggest problem think is the lack of synchronization, between > > what is on the docs and what is on code. > > Which takes us to scavange the forums for extra info, that might have > > been "leaked", like "stuff X actually doesn't work as documented". And > > this steals a lot of development time. > > > > But this is a known problem for ages. > > > > But the 3 or 4 google guys, that do answer developer questions are > > quite helpful, when the questions are done properly, and when you show > > you have done your homework. > > > > But yes, I do believe that Google should have deployed more personnel > > on this SDK. > > We are being used as "Guinea Pigs", which most of us accept without > > problems, but that doesn't mean it's not frustrating when we get stuck > > on some issue, due to lack of info, mostly. > > > > Google should have prepared better for this event. > > Put probably, some comercial pressure rushed the SDK out of the door > > before it's time, and all the required infra structures where setup to > > handle all developers needs. > > > > We don't have a perfect world, so, we have to live with what we have. > > > > But this may have an adverse effect on developers/companies actually > > adopting Android. And as we all know, for a new product/service to be > > adopted by the masses, there is a need to overcome the required > > "critical mass", which might be harder, given the current conditions. > > > > > > > > > > On 27 mar, 14:51, Anil <[EMAIL PROTECTED]> wrote: > > > Please post your opinion: > > > For me, I am disappointed. There must be scores of Google-Android > > > employees dedicated to this project, but only a handful help out in > > > the forums (digit, hackbod, megha, romain) in their free time. > > > Sometimes I am stuck for days and have to create application > > > workarounds. > > > > > > Most of the people helping are ordinary developers like us helping > > > each other out. > > > Sometimes I wonder if Google is exploiting us in this whole Android > > > project. > > > Google, please don't exploit us, instead help us! > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
