ReadWriteTalk » Blog Archive » David Glazer - Engineering Director, Google

David Glazer - Engineering Director, Google

Introduction

On this weeks episode of Read/WriteTalk I have a wide ranging conversation about OpenSocial with David Galzer an Engineering Director at Google. This is a topic we’ve talked about before on ReadWriteTalk with our interview of Kevin Marks. It also is particularly timely after Marshall Kirkpatrick’s interesting piece this week on APIs and Developer platforms. Hope you enjoy the episode!

Standard Podcast [34:29m]: Play Now | Play in Popup | Download

Also, a quick thank you to my friend Eric James for recording some intro music for me!

Transcript

	Sean Ammirati: This is Sean Ammirati with Read/Write Talk. Today, I have David Glazer, an engineering director at Google. So thanks for joining me today, David.David Glazer: My pleasure, Sean. Sean Ammirati: Could you start by just giving people who aren’t familiar with your background and then your role here at Google now? David Glazer: So I have been at Google for a couple of years. I did work for a bunch of companies, some small ones I started, some small ones I didn’t and a couple of big ones before coming here. I have worked on a few different projects in the Google Apps area. Google does search, ads and apps, so I have been working in the apps side because I like doing things that are user interfacing and bring value directly to end users. In over the past while, what I’ve been working on at Google is efforts to help the web become more social. The most noticeable thing we’ve done in area so far has been OpenSocial. Sean Ammirati: That’s what we will be focusing on today. For people who hadn’t guessed that is the OpenSocial project. For those who aren’t familiar, could you give a quick overview on the project?
01:36	David Glazer: Sure. The problem we set out to solve with OpenSocial is we looked at the walls in the point of view of application developers who want to build applications that do interesting things to help users connect with their social contacts. The challenge for app developers is that people’s social contacts are fragmented. They live in lots of different sites, and there is no one way to build applications that take advantage of that. But with OpenSocial, what we set out to do is create an environment that would let any app developer build an application that took advantage of the social context that ran within the web context of any particular social site.So instead of an app developer having to figure out how to cope on Hi5 and how to cope with MySpace and how to cope with Orkut and how to cope with LinkedIn, they can figure out how to build the social app once, write it and then have it reach lots and lots of users in context of their social relationships across the web.
02:33	Sean Ammirati: For people who might not remember, we had Kevin Marks on. I will link to that in the podcast. That was a couple of months ago. We have been covering OpenSocial a little bit here on Read/Write Talk. I think it’s an interesting project. You just had some big news around the release coming out. Do you want to give an update on that?David Glazer: There has been a bunch of ongoing progress. The big news I think you’re referring to is we reached the launch ready version of the API spec which is obviously the precursor, actually getting everyone live with that. Then, related to that, we now have a bunch of sites that are running developer’s sandboxes of supporting the OpenSocial development environment, and that includes Orkut and Hi5 and MySpace. All of those sites are now in their countdown towards final consumer launch. Sean Ammirati: I do want dig into the MySpace thing a little bit? Before that, I guess this release is considered a 0.7 release of the OpenSocial.
03:36	David Glazer: Yes. There is no rocket science in that naming. We started with 0.5. We iterated twice and got to 0.7. Said ‘geez it smells like soup to me. That was as much marketing went into the numbering of the release.Sean Ammirati: OK. What was the big difference from 0.6 to 0.7? Maybe just elaborate on that a little bit. You talked about the APIs, but just talk a little more about that. David Glazer: There weren’t any big differences. There were a handful of small differences. From 0.5 to 0.6, there were probably one or two bigger things. In particular, there was some functionality people really needed to be able to have their applications securely, and with trusted credentials connect back to their application servers. We internally just call that “secure phone home.” So that was a big request we got from the first wave developers, and that went into the 0.6.
04:33	In 0.7, it was largely a bunch of small enhancements and cleanups. We added some methods to allow applications to do user-to-user messaging and to allow applications to let users’ request sharing an application with their friends in the social context, so some viral enabling features and then lots of smaller pieces.Sean Ammirati: So 0.6 to 0.7 is just a cleanup. Talk a little bit about the request sharing app because at the end of the day when you use one of these platforms, developers are using it for distribution purposes. So how does that work exactly?
05:24	David Glazer: I’m giving a slightly roundabout answer because it touches one of the interesting areas that we had to learn by actually working with multiple sites and developers. There is a three-party conversation going on in the world of building OpenSocial apps where the three parties are the end user, first and foremost, that’s the whole point, it’s to deliver user value, the developer who is trying to create an application that can reach a lot of users, and the site that is hosting these applications to improve the attractiveness and value of their site to their users.Each of those people had to agree and feel good about the balance of information quality control and everything else. This request install app is a good example. What OpenSocial does in several places is provide a standard mechanism for the application developer to say, “Here is what I would like to do,” but then allowed each site to implement that mechanism in a way that’s appropriate to the mood in more ways of that site.
06:42	Let me use request Request SendMessage as an example. It’s very similar. It’s a just a little easier to talk through. Request SendMessage is a similar call where any app developer can make a call in their application that says “request SendMessage.” What that says is the user of this app would like to send the following message to the following other users of the social site.Then, the implementers of the API which means the actual social site, the MySpace and the Orkut, can choose to either just say, “Yes, fine. Message delivered,” or to say, “No, we don’t like user user-messaging. We’re going to return an error code that says this is not supported, don’t bother asking.” Or to do what’s the more likely case, they can choose to put up some sort of dialogue that says to the user, “This application is trying to send this message on your behalf. Are you OK with that?” The user can either say, “Yes / Yes always,” or, “No / No always,” or whatever that site thinks is the right policy.
07:46	To go back to your question how does this work, what it does is it gives the app developer the means to say, “I would like to spread my application. I would like to reach more users from inside my application.” Then it allows the site to do that as permissive and open and as controlled a way as it makes sense that meets the expectations of the users of that site.Sean Ammirati: That’s very interesting in terms of obviously one of the reasons people are doing it. It makes sense that would be an important thing to get right in this version. What do you think are the big holes or big opportunities to improve in OpenSocial between 0.7 and I guess a full release, a 1.0 release. Do you think maybe the numbering system is not as relevant there as it might seem?
08:41	David Glazer: I wouldn’t read a lot into the numbering system. I think there are absolutely things to improve. I think we have good ideas on what some of them might be and many other ideas that I expect will arise from people using it.One of the things that we also designed into OpenSocial is we wanted the ability for different sites to build site-specific extensions where if they had specific functionality that they wanted to allow developers on their site to use, they should be able to. Our guiding principle around site-specific extensions was for app developers, no gratuitous differences.
09:24	If an app developer is building an app that does the same thing in site one and site two, they should be able to do it the same way without changing a line of their code. On the other hand, if site one provides some unusual functionality that site two doesn’t provide, the app developer should be able to take advantage of it.One of the benefits of that kind of an extensibility model is it’s beautiful for experimentation. It lets different sites try out adding capabilities, and the sticky ones, the ones that actually turn out to be very successful in terms of developers use them, and users love them, will then end up being adapted by other sites. We as the community of people working and defining the future versions will be able to say, “We have a couple of proof points. It will be really great to add a video primitive into OpenSocial. We have an example of this website. We have already implemented one. We’ve got a lot of updates. Let’s adapt that as a standard piece of OpenSocial so no one will need to a one-off video extension.”
10:33	Sean Ammirati: My understanding is, going back to the MySpace announcement, that’s part of how the MySpace integration has worked, that they’ve taken advantage of some of these site-specific extensions.David Glazer: That’s right. I think if I remember, video is one of the very first ones that they said, “We actually on our site have this accessibility rich information about video so we’d like to make that available to our developers,” and they have made that available. Sean Ammirati: So let’s talk a little bit the MySpace integration. Where is that at this point?
11:06	David Glazer: The developer.myspace.com is the site that has their latest and greatest. It has been open for business since, I forgot exactly when in February, but they had a nice kick off party up in their San Francisco offices. They actually did something really fun. They brought in real-life sandboxes with little buckets and shovels and big piles of sand all over which set exactly the right mood for a developer site.So it’s a live developer site. Developers are building OpenSocial applications and shaking them out in MySpace as we speak. MySpace hasn’t announced the date but they’re working closely towards the public availability of those applications to all MySpace users. Sean Ammirati: I imagine that has certainly increased the number of just general OpenSocial applications being developed. Do you have metrics that you track that you can share about that? How does this increase activity?
12:07	David Glazer: I don’t think we have any metrics we publish. It’s a good question but I think, at the moment, we’re letting each site manage their own messaging around what they are and aren’t ready to say. We haven’t done any roll-ups of that.Sean Ammirati: Sure. Intuitively, it seems like with MySpace releasing this to sandbox now, the activity around generally OpenSocial developers would increase. Is that consistent with what you’re seeing, at least, qualitatively? David Glazer: Indirectly, it is. There is a really interesting dynamic we saw that we were very happy to see which was that the critical mass of enough users at enough sites saying, “We’re going to adopt OpenSocial,” that’s what got the developers’ interest.
13:04	So for example, there was hackathon that Six Apart host that is also up in San Francisco over a month ago now where MySpace had not yet released their sandbox but they got up and they demoed their sandbox that said, “Coming real soon now for you. In the meantime, although you can’t build an application for MySpace, why don’t you just go ahead and build an application for Hi5?” Because it’s OpenSocial, anything you develop for one OpenSocial site, you’re on the fast track to getting your application running on MySpace.So the aggregate reach of the total number of users you reach, that’s the exciting part. The particular timing of which site turns it on and when is smaller.
13:51	So what we’re seeing now as all of the first wave of sites are getting close is we’re all holding our individual get your app ready for my site, tune it for my site, make sure it works exactly well. Orkut had a couple of hackathons over the last of couple of months. MySpace is running a hackathon. I think it’s this Saturday in San Francisco. I believe you can go to, again, developer.myspace.com to get the information on it.So we’re seeing real bursts of excitement as you get on the countdown. The general level of activity is driven by the aggregate reach, not by any one platform.
14:26	Sean Ammirati: Got it. You started to touch on this, but at the end of the day, I’m sure you interact with a lot of developers who are making these choices, what platform to build on. Obviously, the general choice seems to be Facebook’s platform or this Google OpenSocial or I guess both. How are you seeing developers work through the logic of picking which platform to build on top of?David Glazer: This is one piece of your question I’m going to be pedantic and say there’s no such thing as Google OpenSocial. Sean Ammirati: Correct. I’m sorry. OK.
15:05	David Glazer: I’m picking on the words because people could be confused, and we’re very careful to make that distinction. It’s important to us because, remember, the reason we did this is we want to help the web be more social. We don’t think it helps the web be more social to have yet another island in which people can work. The whole premise of it is we don’t like walls. We don’t like islands. The web doesn’t like walls. Let’s do what we can to help the web move the way it’s already moving, which is an open way to be social.Anyway, enough of my self talks. You hit a button there. When I hear that phrase, I have to react. So I apologize for coming on strong. Sean Ammirati: No, that’s fine.
15:50	David Glazer: The question is exactly right. How do developers make a choice? At the highest level, there is the same answer that any developer has always used to make a choice which is, “How do I get the most users quickest?” What is the easiest way for me to get the biggest reach? That’s always the calculus that a developer has to apply. They’re in the business of reaching users. What is the easiest way for me to reach more?What developers do therefor is when they’re looking at, “Where am I going to invest?” They look at how many users per programer hour can I reach? In an ideal world for a developer, and I’m speaking in general now.
16:30	My personal experience with this dates from the days of building software where in order to reach a lot of users in the enterprise, you ‘only’ had to support about 40 different operating systems, 30 of which were variants of Unix. It’s a repeating theme that happens over and over in software development that you get in an early stage market like client-server computing was back when people called that client-server computing. You always get fragmentation because every vendor tries to do their own one-off. That never lasts. Markets always mature, and as markets mature, you get fewer and fewer different proprietary choices because it’s in everyone’s interest to do interoperable single way to build applications to reach everyone.In the world of building social applications, that means, at the moment, if you want to reach a lot of users, you no longer have to choose between 15 or 16 different development environments. There are a couple of development environments that between them cover most of the potential targets. The developers pick between those based on the expediency of how frequently can I get my app to the users I care about?
17:43	Sean Ammirati: Right, which is basically a combination of, as you said, reach and then I guess efficiency in terms of how quickly you can build it.David Glazer: That’s exactly right. By the way, there’s a virtuous cycle that goes on where as a particular environment has high reach, it attracts a lot of developers. When it attracts a lot of developers, there’s a lot of value in creating the tools to make it more efficient to develop for that platform. As it becomes more efficient, you get more developers. As you get more developers, you get more users, and so on. That’s how platforms always work. What we’re starting to see with some of the open source contributions to the overall ecosystem around OpenSocial is exactly that dynamic where we’re starting to see people contributing in different ways to make it easier to support OpenSocial and take advantage of OpenSocial. I suspect that, like most virtuous cycles, it takes a little while to get started, but when they get going, they’re hard to stop.
18:45	Sean Ammirati: Can you give some of those examples, the things that are making it easier to contribute to OpenSocial?David Glazer: Yes. I’ll give you two examples; one, which is relatively low tech but important which we touched on before, and another one which is actual code. The low tech and important one is just a community of shared expertise. You are starting to see a lot of developers that can share ideas with each other, that bump into each other at hackathons and can say, “I’m trying to do this” or that can post on to various discussion groups, some of which are hosted on code.google.com, some of which are hosted at various container-specific sites where people say, “I’m having a problem. I’m trying to figure out how to do this.” Someone else says, “Yes, I have that problem too. Here is what I did about it.” So that’s a completely low tech answer but it’s one of those critical mass things. The more different people you have trying to solve the same problem, the more multiplication of knowledge you get.
19:50	Another example is there’s an open source project, Shindig, which is working to build an open source reference implementation of OpenSocial. The initial work that was done in Shindig because of the initial community’s interest was all done in Java which meant that if you were a site and you are a Java-based social site and wanted to embrace OpenSocial, you had a pretty good starting place, and you have some code that would help you get going. But not all sites are Java-based. There are some sites which are PHP-based.Well, lo and behold, and this is something that everyone who told me that this open source stuff is really cool and said, “This is going to happen.” I said, “Show me.” Lo and behold, there are a couple of programmers in Europe who has said, “I’d really like a PHP version of this,” so they built one, and they committed or they’re about to actually. His post last night said coming in the next day or so. He has built a complete PHP version of the OpenSocial reference implementation. So the number of sites that are able to easily implement OpenSocial just grew dramatically because there are now two languages to choose from.
21:01	Sean Ammirati: Interesting. As I understand, Shindig is more on the container side and not if you’re actually an app trying to fight things into OpenSocial. Is that not correct?David Glazer: That’s exactly right. I think part of the virtuous cycle is things that get there to be more containers, get there to be more developers which feeds things. But no, that example was one about how easy it is to create more reach for applications by having there be more containers in which they run.
21:33	Sean Ammirati: Here’s the thing that is obvious. Maybe I’m thinking about it wrong, but here’s my concern. So I haven’t tried to build a Facebook app nor have I tried to build an OpenSocial app (notice I didn’t use Google that time, so you got through to me there). But I haven’t tried to build neither a Facebook nor an OpenSocial application myself, but I do tend to just intuitively agree that picking a platform is a function of reach plus how efficiently you can build the thing that you want to create that reach.Part of it could be just that Facebook has been around a little longer but it seems to me as a bit of an outsider like there’s more activity on a Facebook platform. So I’m wondering if the issue is more getting this developer productivity worked out because the OpenSocial platform has more reach. Correct? David Glazer: Depending on any reasonable count of users, yes.
22:34	Sean Ammirati: So is the issue just these tools to build the apps coming along? This is an interesting angle to drill into a little bit. What are some of the other things that are making it easier to build these apps so that maybe that the choice will be different in the coming months?David Glazer: Good question. Let me first say I want to just qualify answer on reach. Right now, the potential reach of OpenSocial is much larger, but OpenSocial containers have not gone live yet. Last quarter was the quarter where we announced OpenSocial. This is the quarter where everyone is implementing, and next quarter is the quarter of deployment. So that’s the normal rate at which new platforms kick in. So what we’re seeing now is we’re seeing everyone doing the work - this is the boring quarter. This is the quarter where there is a lot of work and there’s not yet a lot of new value. We made a wonderful progress last quarter, and users are going to get the benefit from it next quarter. This is the quarter where we do the work.
23:41	Sean Ammirati: OK. So some of it is obviously the reach thing. Do you think that there’s a developer productivity issue as well though? Just that the reach as you say is it was promised but not able to delivered on completely quite yet as these sandboxes roll to life systems, or do you think there are some productivity issues that need to be worked through on the OpenSocial platform?David Glazer: I think there are always opportunities to make productivity better, and I think platforms that have been around longer tend to be more know-how. There has been more shared understanding of how to squeeze the best out of them, but that’s something that time fixes quickly and easily. Sean Ammirati: OK. Interesting. You think it’s more of a community thing and less of a tool. David Glazer: Well, I think the community will sometimes contribute to them. Sean Ammirati: Right.
24:37	David Glazer: I think that will happen also. I want to be clear that this is not something where we think that a master plan is the best way to solve this. We think that when you create something that’s valuable and you allow lots and lots of folks to take advantage of it and build on it, the nature of the web wasn’t that there was some central force that say, “We need better tools for creating HTML.” The nature was as it became obvious it was valuable to have better tools for creating HTML, lots and lots of them came into being.Sean Ammirati: Sure. I guess I’m curious. Are you starting to see that happen with the OpenSocial platform? David Glazer: Early stages. Sean Ammirati: Are there a couple you can point to? David Glazer: Trying to think if I have any good examples. Not off hand. We might be able to get back to you with some pointers, but I think it’s still early. Sean Ammirati: That’s completely fair. David Glazer: It’s a fine question.
25:41	Sean Ammirati: One other thing going back to the answer before we talked about reach in frequency, the other comment that you made it is in everybody’s interest to build interoperable systems. I think if you look at Microsoft, some people might argue that’s not true. What’s your impression of this? Do you think that at some point Facebook will participate in the OpenSocial platform? What’s your anticipation of that?David Glazer: I can’t speak for Facebook. I do not know what they’ll do. I know that gravity points towards open on the web. Gravity points towards interoperable on the web. Even the Microsoft example, every time Microsoft tries to do something where they create a new document format that you can’t open outside of using Microsoft Windows, that doesn’t tend to last very long anymore. That used to be possible and it’s harder these days.
26:47	I can’t speak to what anyone else in particular will do on any particular timeframe, but from the developer point of view, the fewer different islands they have to work for, the better. I think already we’re seeing lots of people responding to the moves of the web towards openness.Facebook and any other website is welcome to support OpenSocial when it makes sense for them, and every website should make their own choice about whether they think it is good for their users to do something that’s open and interoperable or whether they think it’s better for their users to do something that’s proprietary and closed or both. That’s an individual decision that every site should make. I know the mega answer is everyone’s going to move towards open because that’s always what happens on the web. Individual answer are individual.
27:36	Sean Ammirati: OK. This is maybe a point question. I’ve heard different answers to this question just in interacting with people in prepping for this. One of the things that I think is difficult for platforms as they’re in their early stages is maintaining backward compatibility. I’ve heard some people say from 0.5 to 0.6 to 0.7, backwards compatibility has been maintained, and then it seems like some people have implied it hasn’t as well as I’ve just read through some discussion boards and stuff. What is the truth around that? What are the plans going forward?
28:19	David Glazer: From 0.5 to 0.6 to 0.7, we provided very weak backwards compatibility guarantees. There were some guidelines on how to change things. We tried to make it as easy as a global replace or possible to build a shimt but that was not a high priority. From 0.5 to 0.6 to 0.7, we tried to set the expectation. These are development versions. They’re out there to help us make the API better. They’re not out there to go live in production and we don’t recommend that you go live in production with 0.5 and 0.6.With 0.7, we have said, “This is the version based on the feedbacks that we’ve been hearing from the app developers where they think they can build applications that are production worthy that they want to put in front of millions of users.” Therefore, we’re saying moving forward from 0.7, there will be backwards compatibility. Beforer 0.7, we had explicitly said, “Maybe, maybe not.”
29:11	Sean Ammirati: OK. That makes plenty of sense. It was a little ambiguous as I was doing some research prepping for this. I was curious around that. OK.So I wanted to end with two questions, and I’m pretty sure I know the answer to one, but they’re good summary questions and they’re the inverse of each other. In your opinion, if you’re sitting there and you’re pitching app developers to build on top of OpenSocial, which I assume you do pretty regularly, what’s the best thing about OpenSocial? Then also, we touched on this a little bit earlier but got sidetracked. What’s your opinion on the biggest opportunity to improve OpenSocial? David Glazer: The best thing about OpenSocial is it’s open and it’s social. Sean Ammirati: I had a feeling that was going to be your answer.
30:00	David Glazer: That’s a little trite sounding but it really is. The best thing about OpenSocial is it is a step towards the original goal of web developers building social applications, a rich social application that can reach the most users easiest. It’s exactly the metric we talked about earlier, and we believe that OpenSocial is the best single choice you can make for hitting that goal.In terms of the biggest opportunity to improve, we put out a whole bunch of ideas in the first OpenSocial 0.5, and that included the ability to have some server side APIs. So as an app developer, if you wanted to build an application that needed to talk to the site server in addition to interacting directly through JavaScript on the web page, you’d have a choice. People told us that was not as important, that they could build and launch interesting apps without those server side APIs, so we prioritized on that. But they also told us that they care a lot about it.
31:09	So one of the very next areas that I expect we’ll see agreement on in deployment in OpenSocial after 0.7 will be server side APIs. There is an active discussion going on the OpenSocial and spec discussion group, we can get you the URL afterwards if you want to link to it, that has a proposal for one such possible API that is being debated right now, but I think that’s going to be the next interesting stuff forward.Sean Ammirati: One more question came up in that answer, which is something that I don’t know. I think part of the reason, and I won’t say it again, but I called it Google OpenSocial maybe incorrectly before is because I think there is this impression that obviously a lot of the people behind this are Google employees which I think is true. What is the decision making process for what’s in and what’s out? How does that happen? David Glazer: For what actually is part of the OpenSocial spec. Sean Ammirati: Platform, yes. Spec exactly.
32:16	David Glazer: Although we have not put the energy into writing a formal charter document, our model was very much the IETF model of rough consensus and running code. So it’s get a community of people who are the folks who area actually trying to build this thing by active discussions both in public discussion groups, email forums and face to face occasionally, and get to the point where people are all nodding at each other saying, “Yes, I could build to that. Yes, I could implement that. Yes, I could take advantage of that.” Then, write it down and get an implementation running, and if it’s not right, iterate.Sean Ammirati: The people who are building it include people outside of Google as well then.
33:04	David Glazer: Yes. It’s certainly true that there are a lot of people at Google who are contributing to OpenSocial. We at Google think it’s a very good thing for the web, to help the web become more social, and we’re willing to put a bunch of energy into it. We are far from the only people doing that. There are lots of good ideas in here.If you look at the difference between the originals, take those server side APIs I talked about, we had a put out a proposal for, “Here’s what server side APIs could look like.” We put that out on November 1st, and we got a bunch of feedback on it. If you look at the latest proposal for what those server side APIs look like, you’ll see that there are some common elements and some very different elements from the initial one. That came from many sources. Sean Ammirati: Interesting. David, I really appreciate you taking some time. I know you have a lot on your plate being an engineering director at Google and being involved in this project, so I appreciate you taking some time to talk today. David Glazer: My pleasure, Sean. It was fun. Sean Ammirati: Thanks.

This entry was posted on Friday, March 7th, 2008 at 1:26 pm and is filed under Entrepreneur. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.