Google Developer Day sneak peek with Bret Taylor
[Ed] You've been working at Google since 2003. How did you find your way there?
[Bret] Most people here came from smaller startups. I was interested in building products that would impact a lot of users. One day I was thinking of all the projects I used daily, and Google was at the top of the list. That's what made me come here: millions of users access our work every day.
[Ed] And now you're in charge of everything at code.google.com?
[Bret] Actually the engineers in each area are in charge, and I don't want to take anything away from their work. But yes, that's my responsibility. I manage all the product managers for developer products.
[Ed] What is Developer Day?
[Bret] On May 31, Google Developer Day will open around the world. It's Google's first ever global developer conference. Google speakers will be attending all of them. Well over 1000 people signed up in Mountain View, and thousands more around the world.
[Ed] That's a lot more than you expected, isn't it?
[Bret] Yes, the original plan was to hold the California one on Google's campus, but we didn't want to have to turn people away so we moved it to the San Jose convention center. For those that can't attend, we'll be webcasting all the sessions live from San Jose and providing a YouTube channel with videos of sessions from around the world, so you can attend virtually. There will also be live blogging.
[Ed] Will this be a yearly event, then?
[Bret] I hope it will turn into a yearly thing, at all 10 cites. Developers are growing in importance at Google. [Ed] So what's on the agenda?
[Bret] There are two high level categories we'll be focusing on: integration and reach.
Integration is how Google is exposing its infrastructure and scalable services. For example the Google Maps API and Google Data APIs. These are XML web services that let you use Google servers as a backend to your applications.
Reach means ways to empower developers to reach Google users. We have a whole lot of servers and lots of traffic. Developers want better ways to access that traffic. For example through the Google Gadgets API they can incorporate their products into the iGoogle personalized home page.
On my home page I have a Pacman gadget that I like. This little gadget gets over 6 million pageviews per week. This is an example of an opportunity to improve quality of our home page plus drive traffic for developers. We provide the building blocks.
We'll have multiple sessions on Google Maps API and KML. In the morning there will be introductory material, and in the afternoon there will be a "deep dive" with the engineering teams to explore more complex features. We'll do something similar with Google Web Toolkit.
Our goal is not only to hear feedback from developers, but we want every developer to come away with new ideas.
[Ed] Can you talk about what you're doing to make all your APIs work better together?
[Bret] We want to have one approach with a simplicity of integration. It turns out this is not a big technical burden. Our Google Data APIs have a single client library to use all the data APIs - Google Base, Google Calendar, etc..
We just started the process of reviewing the JavaScript APIs. If you're using JavaScript APIs every one has consistent API and version scheme.
One issue with JS APIs is that they're hosted on google servers. Everytime we push a new version, your site could potentially be impacted. In the Google Map APIs, there's a JS tag at the top of your HTML file to pull in our code. Because we make changes all the time, there are a lot of developers concerned about stability. So we introduced an elaborate versioning mechanism, they can say what version to use in their code and HTML, and continue to use older version so we won't break their site.
[Ed] Aren't you worried about developers sticking with an old version so you'd have to support it forever?
[Bret] No, we have this feature so developers can test our changes before they incorporate them into their site. It's a balance between innovation and stability. We got good feedback from the Maps API so we're applying the same scheme to all other JS APIs.
It's kind of a gentleman's agreement with the developers. Google does not support older versions of the APIs. We test the recent versions, but don't officially support them. In practice, what happens is we'll do a push every week or so, and 90% of the developers will be one version back. If there are any problems, they post on the developer support forum so we can roll back if necessary. It's a constant iterative testing and deployment system. [Ed] But those old versions will stop working at some point, right?
[Bret] Eventually yes, maybe some server side dependencies could change and break the code. But so far it hasn't happened yet.
[Ed] Why does Google do all this, and give it away for free?
[Bret] That's a good question. There are two main benefits we get from the APIs. The first is traffic. Google Gadgets is a good example of this. Developers get access to traffic from the Google personalized homepage, but a lot of that traffic is ultimately due to effort they put into making interesting Gadgets, like the Pacman gadget on my homepage.
The second benefit we get is that our APIs enable developers to build on top of our services in ways we might never have done ourselves. Developers benefit from access to our services, and Google benefits from the way developers extend and improve our products. It's a symbiotic relationship.
[Ed] Do you see technologies like Flex, Silverlight, and JavaFX replacing Ajax?
[Bret] No, there's just so much investment in HTML. We're excited to see people innovating with web apps in general. One thing people don't realize is that we rarely approach a problem from technology first -- we approach it from the user first. We try to create a product for user, and then use whatever technology meets that need. Today, Ajax and JavaScript meet that need. But we're always open to using new technology when appropriate. For example we use use Flash on the Google Finance page.
[Ed] Are you involved much with HTML5?
[Bret] There are a lot of Google engineers that participate in various standardization efforts. I know one is on the HTML5 effort, and we have a representative on the OpenAjax alliance.
Eventually we want to see all user applications running inside a web browser. Right now, the industry is in an experimentation phase. It's great to see all the people innovating. [Ed] Google doesn't have a good story in the area of Ajax effects. Is that going to change?
[Bret] Our focus has not been to be comprehensive. Dojo and scripta.culo.us do fine with that. What we do is provide unique value, like the combination of Ajax + google services. We complement the more comprehensive libraries that are more general purpose.
[Ed] What are you hoping to get from Google Developer Day?
[Bret] We're there to get feedback from community. What do they need from us? What we should be doing better? We're all ears.
[Ed] Thanks Bret, it's been great to talk to you.
[Bret] My pleasure.
Bio: Bret Taylor is the Group Product Manager responsible for Google's developer products. Before working on Google's developer efforts full time, Bret launched Google Maps, Google Local, and the Google Maps API. He joined Google in early 2003, initially working on Google's web search infrastructure and ranking. Prior to Google, Bret worked as a software engineer at Reactivity, a startup incubator in Silicon Valley. Bret holds an MS and BS in Computer Science from Stanford University.