Marks: Hello there, I'm--
I've been asked to talk to you about, um,
the social web, um,
and how entrepreneurs can take advantage of that.
So...the way-- the way I look at this
is that, um,
the web keeps developing over time.
So it's--the web grew out of an open network
on open standards.
Um, we built it that way so that, um,
you could run applications without worrying about things.
So you didn't have to worry about
where other computers were,
you could just send a message to them.
That was the first thing that happened.
Um, then when we got to the web, it was,
"I don't have to worry about where my documents are.
"I can get those from anywhere in the world.
"Oh, and I don't have to worry about user interfaces.
"I can just write a form and the form will post that
to the other side of the world where my server is."
So there's increasing abstraction over time.
Um, because these abstractions are there,
it means, basically, you have to write less code.
So the trend that's been happening over the last year,
and the one that we've been very involved with
in OpenSocial,
is coming up with abstractions for social--
for the social part of the web.
Um, a year ago, what we saw was
there were lots of different social networking sites,
and people were spending lots of time on them.
But to develop for them was very hard.
'Cause each of them had a separate API.
Um, you often had to wedge, um, code in there
through--through back doors
or embedding flash or something like that.
So building something that worked across many sites
was quite hard.
Um, so we put together the open social initiative
to come up with a way,
a common set of APIs
for social applications on the web,
to make the social part of the web, um,
as easy as writing HTML forms.
That's the goal, to make it something you can just
rely on being there.
Um, and a year on,
we're very excited with what's happened with that.
Um, I'm speaking today from OpenSocial's first birthday.
Um, and we just announced that we have
over 600 million users of OpenSocial worldwide,
across, um, most of the countries in the world.
I can't even remember the list of countries.
So that's, um, that's very exciting.
But the point of this, really,
is that, um, is to make application development easier.
At the moment, if you want to build a social application,
you have to find out information about people.
And that tends to mean you write a large form
for them to fill in,
where they have to tell you who they are,
where they live,
any other personal information you need.
And then the second thing you have to do
to make it really social
is find out who their friends are
and gather the same information from them.
So you either end up saying,
"Tell me who your friends are,"
or you--they have to re-friend everyone on your side,
or you go into the "let me import your address book
and email your friends and tell them to join my side."
Um, and that ends up annoying people
more than it helps them.
Um, the other thing is
when you go to a website that has a big form at the front
asking for information,
people sort of back away from it and leave.
And so you find that what you've got into a database
is a sort of bad copy of their real information
that they store somewhere else.
'Cause they're a set of sites
they actually trust with social information.
'Cause those sites are-- specialize in gathering.
So, um, what you're able to do with OpenSocial
is to draw on those existing sites
that have these large collections
of social data,
um, build your application
that specializes in what you want to do,
um, and then take advantage
of the social network that already exists.
So you can...whatever your application's about,
you can almost always enhance it
by making it more social,
by making it something you do with friends.
Even if it's just a, um, a news site
that's telling stories,
um, you can be more interesting stories
that your friends have read or recommended,
um, than--than you are in general
the stories that--that everyone's looking at.
So by--just by adding that little social feedback loop,
you can make each, um, each experience
more interesting.
Um, so another aspect of this--
now, there--there's--
in building social applications,
there's a lot of talk about becoming viral
and spreading.
And--and there's--there's been a set of applications built
whose primary goal
is to get as many members as possible.
Um, and this is-- this--this is--
there's, you know, we're seeing a backlash against that.
And what I like to argue is that this is--
this is because people are using the wrong metaphor.
If you think of yourself as a virus,
you're basically saying,
"I would like to be a disease.
"I would like to take advantage or people to spread myself,
and that's my only goal in life."
So what I say people do is think of different metaphors.
Think of organic metaphors.
Um, think instead of infecting someone,
think of inviting them.
Um, so think of how plants work.
Plants have fruit.
A fruit is a seed,
but it has something delicious wrapped around it.
If you send someone an invitation
that actually makes them happy,
they're much more likely to follow through,
plant the seed, and grow it.
So if you se--rather than sending out invitations
to everyone in the address book,
um, if you let people
send out photographs of people,
um, that contain them,
they're much more likely to look at it.
If I get an email with
"Your friend has a photograph of you,"
um, I'm gonna look at that, go back, and click on that.
So think about how you can actually spread this stuff
so it's a natural part of the experience
rather than something you're exploiting
for your--for your own ends.
Because if you behave like a disease,
people develop an immune system,
and they learn to reject you, your applications.
And that's something we're seeing now.
Um, the applications that spread rapidly
go up like this, and they collapse like that
as people start uninstalling them
and as containers start banning them.
Um, I said container there,
so I should back up and explain that a little bit.
Um, with OpenSocial, we split the development world
into what we call containers and applications.
The idea is the container
is the custodian of the social data.
It's the place that knows who your friends are,
has information about you and them,
and can reveal that to the application.
Now, clearly, they have to do that
with permission of the users.
So there are three people involved.
There's the container, the application,
and the user.
Um, and the user chooses which applications
to add to the container,
and the container manages the personal information
so the application doesn't have to worry about that.
Um, and also, the other--
the key thing, the value that, um,
the application gets from the container
is the friends of the user can see that application too,
and they can learn to install it.
So it can spread, um, rapidly in that way.
But, as I say, you shouldn't be focusing
on spread as your goal.
You should be focusing on delighting the users
so they want it to spread,
rather than they feel like something's taking them over
and exploiting them.
Um...the--
so the other thing that I want to mention
about the growth of OpenSocial
and the way it's changed in the last year,
um, up until recently,
the model for OpenSocial
has been literally having an application
embedded inside somebody else's site.
So if you've got the container site,
the application was part of their page.
Um, this has some advantages.
It makes the context very clear to the user.
It makes it easier to integrate, um,
the--the friend stuff
'cause it's fairly clear what's going on.
But the drawback is that, um,
you have to write it in JavaScript.
Um, and...
well, you can write some in CSS as well,
but primarily, you're writing JavaScript application.
Um, and plus your application
can only actually run code when somebody's looking at it.
So one of the things we added in OpenSocial.8
is a REST API,
which makes it easier for you to write
your application on your own server over here,
and call into the social network,
um, use the information from there,
and present that back to the user there.
So what we use is a set of open protocols for that.
We use, um, REST,
which is the basic standard for communicating on the web.
We use OAuth to authenticate that,
um, and to let the user say,
"Yes, this application's allowed to do something
with my application."
Um, and the three parts of OpenSocial are--
well, actually, there's four parts of OpenSocial
that are exposed with REST APIs.
The first is the people and contact stuff,
finding out who you are, who your friends are,
and information about you.
Um, the second is data persistence.
You can actually store data within the container,
which means when the app is running in the container,
it can have access to that quickly.
And also, it handles the hard problem
of I'm storing information for user--
for one user.
I need the information for that user
plus his friends.
Um, for a large number of users,
that's actually quite a hard database problem.
But the social networks have already sold that
because they already have large numbers of users,
and they solve that problem every day.
So you're basically piggybacking
on their ability to do that there.
The third one is activity streams.
Now, this is the page where you have a list
of what you and your friends have done
within the-- the social network site.
That's been extended with OpenSocial
so that anything you do with the applications
could show up in there too.
And with .8, you can run an application remotely
and send activities into the site.
So if they do something on your site,
their friends on the social network can see that too.
And again, it adds value for everyone.
It adds value for you because the social network
where people are watching and loading the pages 20 times a day
has information about your applications.
It adds value for, um, for social network
because stuff that's happening elsewhere is--
becomes part of their world.
And it adds value for the people
'cause they can keep track of their friends.
So again, you know, you have this ability to do this.
You could abuse that and fill it with noise,
but if you do, you'll get shut down fairly quickly.
So think about how you can keep that
in a way that adds value to all three.
Then the fourth thing is messaging.
You can send messages to people
through the social network.
Um, and this is-- this is, um, valuable
in that there is a large group of people
who have moved from using email
as their primary messaging system
to using social networks for that.
Because this--explicitly because the social networks
are whitelisted.
So if your application has gained trust
of both parties,
it can send messages between them.
And that--that makes that more useful for them too.
So the mod--the model here
is very much adding new infrastructure to the web
such that every application you make can become social.
Um, the other, think way of looking at it
is it's freeing you
from having to maintain that database of users.
One of the things you often have to do
in doing web applications is say,
"Okay, your user database.
I need to start collecting this stuff."
And it's a sort of bunch of extra make work
you have to do at the beginning
before you can focus on what you really want to build.
So this means that you can delegate that to other sites
and not worry about, um, how that works.
And that's-- that's a strong piece
of the, um, what we're calling the...
um, open stack of standard protocol
that's for connecting between sites.
Um, there's--there's a set of these,
and I won't go into every place--
OpenID, OAuth, and OpenSocial
are the three key ones to know about.
OpenID means using another site's URL
as a login instead of an email address.
OAuth means getting authorization--
letting you use a grant permission
to access another site in a standardized way.
And then OpenSocial is the specification
that defines what kind of data
you're exchanging over these connections.
And also has the connection to the gadget model
so you can actually embed an application
entirely inside another site as well.
Man: Great.
- Kevin: Okay. - Man: Nice job.
Kevin: How long was that?