Techcrunch just reported on an important decision by MySpace and Six apart to join
OpenSocial
http://www.techcrunch.com/2007/11/01/confirmed-myspace-to-join-google-opensocial/
Thursday, November 1, 2007
Wednesday, October 31, 2007
More Open discussion about OpenSocial
We are very excited about Google Announcement to release their OpenSocial API.
As a private label social network incubator/accelerator we too want to use its API
for these social network/social media engines:
Mobile Social Network
http://mobiquity.ws
Mobile Ambient and Location Based Network
http://tagr.mobi
IPTV Social Media
http://iptvlatino.ws
Friendster-MySpace Funtionality
http://messagr.us
Urban Comedy - With HBO Sponsorship
http://humormill.net
Digital Locker - What iTunes should be
http://Datr.ws
iHollywood Social Media
http://6bacon.com (Connecting iHollywood Media Mogul)
http://starbiz.tv (Home to hottest Hollywood celebrities)
The Glue that ties OpenSocial / FaceBook and Widgets
http://Gluegl.us ALPHA
Below is an excellent report from
http://blog.pmarca.com/2007/10/open-social-a-n.html
Open Social: a new universe of social applications all over the web
* Oct 31, 2007
My company, Ning, is participating in this week's launch of a new open web API called Open Social, which is being spearheaded by Google and joined by a wide range of partners including Google's own Orkut, LinkedIn, Hi5, Friendster, Salesforce.com, Oracle, iLike, Flixster, RockYou, and Slide.
In a nutshell, Open Social is an open web API that can be supported by two kinds of developers:
* "Containers" -- social networking systems like Ning, Orkut, LinkedIn, Hi5, and Friendster, and...
* "Apps" -- applications that want to be embedded within containers -- for example, the kinds of applications built by iLike, Flixster, Rockyou, and Slide.
This is the exact same concept as the Facebook platform, with two huge differences:
* With the Facebook platform, only Facebook itself can be a "container" -- "apps" can only run within Facebook itself. In contrast, with Open Social, any social network can be an Open Social container and allow Open Social apps to run within it.
* With the Facebook platform, app developers build to Facebook-proprietary languages and APIs such as FBML (Facebook Markup Language) and FQL (Facebook Query Language) -- those languages and APIs don't work anywhere other than Facebook -- and then the apps can only run within Facebook. In contrast, with Open Social, app developers can build to standard HTML and Javascript, and their apps can then run in any Open Social container.
If you recall how I previously described the Facebook platform as "a dramatic leap forward for the Internet industry", you'll understand why I think Open Social is the next big leap forward!
Open Social takes the Facebook platform concept and provides an open standard approach that can be used by the entire web. Open Social is an open way for everyone to do what Facebook has done...
...including Facebook itself, potentially -- more on that below.
Technically, Open Social is implemented as what I call a "plug-in API", or a "Level 2 platform". In other words, it's not a web services API -- rather, it's a way for external applications to "plug into" a host environment (or "container"). And then, in addition to literally showing up inside the pages of a container, the external app can make Javascript calls to retrieve all kinds of useful information from the container and perform all kinds of useful functions within the container, such as "give me a list of all of this user's friends" or "inject this event into this user's activity feed".
Open Social basically standardizes the concept of a plug-in API in such a way that neither host social networking environments (containers) nor external applications will ever have to invent another plug-in API, or have to choose between multiple competing proprietary plug-in APIs.
Open Social's API is based entirely on Javascript. If you know HTML and Javascript today, you will be able to immediately use Open Social to turn your web applications and web sites into Open Social apps. You can also use standard web development tools to build Open Social apps. This is obviously a much better way to operate than having to learn a proprietary marketup language or query language.
Finally, although Open Social provides standard API calls to do many of the things you'll want to do as an Open Social app, nothing will prevent containers from implementing additional Javascript or web services APIs to provide additional functionality to developers. Open Social app developers can therefore choose to stay "onroad" and have their apps run in any Open Social container, or go "offroad" for one or more specific containers to do special things. Open Social standardizes common functionality but doesn't prohibit innovation. More on that below.
Open Social is very practical. Many standards die an early death because they are too complicated and hard to implement. Open Social is what you want in a standard -- it's expansive enough to do useful things, but limited enough to be very easy to implement, both for containers and for apps.
At this Thursday's launch event, you will see Open Social already running in a variety of containers, including Ning, Orkut, Hi5, and LinkedIn, and across a variety of apps, including iLike, Flixster, and Slide. I'm talking about working code. At Ning, it took us only a few days for us to add support for Open Social as a container -- because we already had all the necessarily underlying APIs and mostly just had to map to them -- and the app developers in the launch created Open Social versions of their apps even more quickly. We also have live running examples, such as iLike, of the same app running in multiple containers -- Ning, Orkut, and Hi5 -- proving the interoperability that the Open Social specification promises.
Now, all that said, Open Social is not quite ready to go live on Ning and the other partners. The API has to stabilize a bit, and containers have to finish testing and validating their implementations. But public production systems aren't far off -- Ning, for one, will go live as soon as we possibly can, probably just as soon as Google finalizes the API.
What does this mean for today's Facebook app developers?
Today's Facebook app developers just got very good news -- they will be able to take all of the work they did to build their Facebook apps and create Open Social versions of their apps very easily... and by so doing, get access to a huge new pool of users -- as many as 100 million users just via the initial Open Social partners, more than twice as many users as Facebook has today.
As an app developer, there's no real reason to choose between Facebook and Open Social. It's easy to do both. You've already put in most of the effort -- creating a new set of front-end HTML and Javascript pages is almost trivial, and that's all you need to do to have your app "port" to Open Social and work within Open Social containers like Ning, Orkut, Hi5, and LinkedIn.
What does this mean to web sites that aren't Facebook apps?
If you have a web site today, and you want to turn your web site into an Open Social app, that's perhaps even easier than "porting" a Facebook app. Just take your current HTML and Javascript front-end pages and create a version of those pages that use the Open Social API. QED.
Are people really going to maintain multiple sets of front-end pages for their web sites for Facebook, Open Social, etc.?
I think so, yes. I think any web site going forward that wants maximum distribution across the largest number of users will have a single back-end, and then multiple sets of front-end pages:
* One set of standard HTML and Javascript pages for consumption by normal web browser.
* Another set of HTML and Javascript pages that use the Open Social API's Javascript calls for consumption with Open Social containers/social networks.
* A third set of pages in FBML (Facebook Markup Language) that use Facebook's proprietary APIs for consumption within Facebook as a Facebook app.
* Perhaps a fourth set of pages adapted for the Apple iPhone and/or other mobile devices.
The overwhelming good news here is that these pages can all be served and serviced by the same back end code -- and of course, 95%+ (and usually 99%+) of the effort involved in building any web app consists of building the back end. Having already built the back end, it's a very small amount of effort to create any of these front end pages.
What does this mean for Facebook?
Well, to venture a few opinions...
Facebook did an absolutely outstanding job kick-starting this whole approach with their proprietary Facebook platform. That plus their very large walled garden user base generated a rush of app development and adoption on Facebook that has performed very well for them over the last five months.
Open Social -- by making this exact same kind of opportunity available to any other social network or container and every app developer and site on the web, in an open and compatible way -- will prevent Facebook from having any kind of long-term proprietary developer lock-in. Developers will easily write to both Facebook and Open Social, and have every reason to do so -- in fact, 100+ million reasons to do so.
If you're Facebook, you'd probably prefer to have that proprietary lock-in, and so this announcement may not make you that happy. However, all is not bad for Facebook, because a big part of what's happening today is market expansion, and Open Social will definitely help fuel market expansion, which is in everyone's interest, including Facebook's.
Look at it this way: most users on the Internet (1.3+ billion, with 100 million joining every year) are not yet using any social networking service. The more compelling social networking becomes, the more users who will discover and start using social networking, and the bigger the pie gets for everyone, including Facebook.
Meanwhile, most software developers in the world are not yet building apps for social networks -- Facebook or otherwise. The more developers who build social networking apps -- Facebook or otherwise -- the more apps there will be on social networks, and the bigger the pie gets for everyone, including Facebook.
It's hard to see Facebook losing in a world of a billion or more social network users, and hundreds of thousands or millions of social network apps. And it's also easy to see how a lot of other people -- containers, and app developers -- will win, as well.
In fact, if rumors of a Facebook web-wide ad network are true, then this could be great for Facebook in another way -- such a Facebook-run ad network could be an outstanding ad network for all of these new Open Social web applications!
Finally, note that Facebook can easily support Open Social any time they want. They probably won't do so right away, but in the long run, it will probably be a no-brainer for them, because then they will pick up whatever Open Social app developers who aren't also Facebook developers.
Is this good for the web?
This is very, very good for the web. Open Social is the kind of standard that web developers love, and can easily use. I think it will become a standard part of many developers' toolkits. It builds on HTML and Javascript, many people can support it, and it will be interoperable -- I know that because it already is interoperable for the partners in this week's launch. It's all good.
How will Ning support Open Social?
We will aggressively support Open Social in every conceivable way, including but not limited to:
* Being an outstanding container. Open Social apps will be able to run easily and reliably inside Ning social networks -- all 113,000+ of them. Ning Network Creators will be able to quickly and easily add Open Social apps to their networks, and Ning users will be able to quickly and easily add Open Social apps to their profile pages.
* Being an app publisher. Ning already automatically produces Facebook apps for every Ning network -- specifically, video, photo, and music players -- using the Facebook proprietary platform approach. We will do the exact same thing for Open Social -- we will automatically produce Open Social apps for every Ning network.
You mentioned that Open Social containers can implement additional Javascript or web services APIs -- won't that break compatibility?
No, I don't think so. Think of it this way. As an app developer, you have three options:
* You can write purely to the Open Social API. If you do this cleanly enough, your app will run unchanged in any compliant Open Social container. (Google is actually not making this claim -- they're calling Open Social "learn once, write anywhere", which is not the same as "write once, run anywhere". But in practice, the API is simple enough that "write once, run anywhere" should work just fine.)
* You can write an app that is specific to one container. For example, there may be some apps that make sense only in LinkedIn -- business-related apps, say. There may be other apps that make sense only in Ning -- apps that presume that users are creating their own social networks, say. And there may be yet other apps that only make sense in Salesforce.com, which will also be an Open Social container. In those cases, you are targeting your app to one specific container, and so using whatever additional APIs that particular container provides, in addition to the Open Social APIs, is a no-brainer.
* Finally, you can write an app that behaves differently depending on which of several containers it's running in. Your app just discovers which container it's running in, and then does whatever it wants on a per-container basis.
No standard can possibly anticipate all of the different use cases and scenarios people will think up. Standards that try to anticipate all of the different use cases fail, because they are too complex and generally impossible to implement. Standards that standardize behavior that is clearly standard, while leaving open the ability to innovate on top, succeed. The history of this kind of thing is quite clear, and Open Social is on the right side.
As a private label social network incubator/accelerator we too want to use its API
for these social network/social media engines:
Mobile Social Network
http://mobiquity.ws
Mobile Ambient and Location Based Network
http://tagr.mobi
IPTV Social Media
http://iptvlatino.ws
Friendster-MySpace Funtionality
http://messagr.us
Urban Comedy - With HBO Sponsorship
http://humormill.net
Digital Locker - What iTunes should be
http://Datr.ws
iHollywood Social Media
http://6bacon.com (Connecting iHollywood Media Mogul)
http://starbiz.tv (Home to hottest Hollywood celebrities)
The Glue that ties OpenSocial / FaceBook and Widgets
http://Gluegl.us ALPHA
Below is an excellent report from
http://blog.pmarca.com/2007/10/open-social-a-n.html
Open Social: a new universe of social applications all over the web
* Oct 31, 2007
My company, Ning, is participating in this week's launch of a new open web API called Open Social, which is being spearheaded by Google and joined by a wide range of partners including Google's own Orkut, LinkedIn, Hi5, Friendster, Salesforce.com, Oracle, iLike, Flixster, RockYou, and Slide.
In a nutshell, Open Social is an open web API that can be supported by two kinds of developers:
* "Containers" -- social networking systems like Ning, Orkut, LinkedIn, Hi5, and Friendster, and...
* "Apps" -- applications that want to be embedded within containers -- for example, the kinds of applications built by iLike, Flixster, Rockyou, and Slide.
This is the exact same concept as the Facebook platform, with two huge differences:
* With the Facebook platform, only Facebook itself can be a "container" -- "apps" can only run within Facebook itself. In contrast, with Open Social, any social network can be an Open Social container and allow Open Social apps to run within it.
* With the Facebook platform, app developers build to Facebook-proprietary languages and APIs such as FBML (Facebook Markup Language) and FQL (Facebook Query Language) -- those languages and APIs don't work anywhere other than Facebook -- and then the apps can only run within Facebook. In contrast, with Open Social, app developers can build to standard HTML and Javascript, and their apps can then run in any Open Social container.
If you recall how I previously described the Facebook platform as "a dramatic leap forward for the Internet industry", you'll understand why I think Open Social is the next big leap forward!
Open Social takes the Facebook platform concept and provides an open standard approach that can be used by the entire web. Open Social is an open way for everyone to do what Facebook has done...
...including Facebook itself, potentially -- more on that below.
Technically, Open Social is implemented as what I call a "plug-in API", or a "Level 2 platform". In other words, it's not a web services API -- rather, it's a way for external applications to "plug into" a host environment (or "container"). And then, in addition to literally showing up inside the pages of a container, the external app can make Javascript calls to retrieve all kinds of useful information from the container and perform all kinds of useful functions within the container, such as "give me a list of all of this user's friends" or "inject this event into this user's activity feed".
Open Social basically standardizes the concept of a plug-in API in such a way that neither host social networking environments (containers) nor external applications will ever have to invent another plug-in API, or have to choose between multiple competing proprietary plug-in APIs.
Open Social's API is based entirely on Javascript. If you know HTML and Javascript today, you will be able to immediately use Open Social to turn your web applications and web sites into Open Social apps. You can also use standard web development tools to build Open Social apps. This is obviously a much better way to operate than having to learn a proprietary marketup language or query language.
Finally, although Open Social provides standard API calls to do many of the things you'll want to do as an Open Social app, nothing will prevent containers from implementing additional Javascript or web services APIs to provide additional functionality to developers. Open Social app developers can therefore choose to stay "onroad" and have their apps run in any Open Social container, or go "offroad" for one or more specific containers to do special things. Open Social standardizes common functionality but doesn't prohibit innovation. More on that below.
Open Social is very practical. Many standards die an early death because they are too complicated and hard to implement. Open Social is what you want in a standard -- it's expansive enough to do useful things, but limited enough to be very easy to implement, both for containers and for apps.
At this Thursday's launch event, you will see Open Social already running in a variety of containers, including Ning, Orkut, Hi5, and LinkedIn, and across a variety of apps, including iLike, Flixster, and Slide. I'm talking about working code. At Ning, it took us only a few days for us to add support for Open Social as a container -- because we already had all the necessarily underlying APIs and mostly just had to map to them -- and the app developers in the launch created Open Social versions of their apps even more quickly. We also have live running examples, such as iLike, of the same app running in multiple containers -- Ning, Orkut, and Hi5 -- proving the interoperability that the Open Social specification promises.
Now, all that said, Open Social is not quite ready to go live on Ning and the other partners. The API has to stabilize a bit, and containers have to finish testing and validating their implementations. But public production systems aren't far off -- Ning, for one, will go live as soon as we possibly can, probably just as soon as Google finalizes the API.
What does this mean for today's Facebook app developers?
Today's Facebook app developers just got very good news -- they will be able to take all of the work they did to build their Facebook apps and create Open Social versions of their apps very easily... and by so doing, get access to a huge new pool of users -- as many as 100 million users just via the initial Open Social partners, more than twice as many users as Facebook has today.
As an app developer, there's no real reason to choose between Facebook and Open Social. It's easy to do both. You've already put in most of the effort -- creating a new set of front-end HTML and Javascript pages is almost trivial, and that's all you need to do to have your app "port" to Open Social and work within Open Social containers like Ning, Orkut, Hi5, and LinkedIn.
What does this mean to web sites that aren't Facebook apps?
If you have a web site today, and you want to turn your web site into an Open Social app, that's perhaps even easier than "porting" a Facebook app. Just take your current HTML and Javascript front-end pages and create a version of those pages that use the Open Social API. QED.
Are people really going to maintain multiple sets of front-end pages for their web sites for Facebook, Open Social, etc.?
I think so, yes. I think any web site going forward that wants maximum distribution across the largest number of users will have a single back-end, and then multiple sets of front-end pages:
* One set of standard HTML and Javascript pages for consumption by normal web browser.
* Another set of HTML and Javascript pages that use the Open Social API's Javascript calls for consumption with Open Social containers/social networks.
* A third set of pages in FBML (Facebook Markup Language) that use Facebook's proprietary APIs for consumption within Facebook as a Facebook app.
* Perhaps a fourth set of pages adapted for the Apple iPhone and/or other mobile devices.
The overwhelming good news here is that these pages can all be served and serviced by the same back end code -- and of course, 95%+ (and usually 99%+) of the effort involved in building any web app consists of building the back end. Having already built the back end, it's a very small amount of effort to create any of these front end pages.
What does this mean for Facebook?
Well, to venture a few opinions...
Facebook did an absolutely outstanding job kick-starting this whole approach with their proprietary Facebook platform. That plus their very large walled garden user base generated a rush of app development and adoption on Facebook that has performed very well for them over the last five months.
Open Social -- by making this exact same kind of opportunity available to any other social network or container and every app developer and site on the web, in an open and compatible way -- will prevent Facebook from having any kind of long-term proprietary developer lock-in. Developers will easily write to both Facebook and Open Social, and have every reason to do so -- in fact, 100+ million reasons to do so.
If you're Facebook, you'd probably prefer to have that proprietary lock-in, and so this announcement may not make you that happy. However, all is not bad for Facebook, because a big part of what's happening today is market expansion, and Open Social will definitely help fuel market expansion, which is in everyone's interest, including Facebook's.
Look at it this way: most users on the Internet (1.3+ billion, with 100 million joining every year) are not yet using any social networking service. The more compelling social networking becomes, the more users who will discover and start using social networking, and the bigger the pie gets for everyone, including Facebook.
Meanwhile, most software developers in the world are not yet building apps for social networks -- Facebook or otherwise. The more developers who build social networking apps -- Facebook or otherwise -- the more apps there will be on social networks, and the bigger the pie gets for everyone, including Facebook.
It's hard to see Facebook losing in a world of a billion or more social network users, and hundreds of thousands or millions of social network apps. And it's also easy to see how a lot of other people -- containers, and app developers -- will win, as well.
In fact, if rumors of a Facebook web-wide ad network are true, then this could be great for Facebook in another way -- such a Facebook-run ad network could be an outstanding ad network for all of these new Open Social web applications!
Finally, note that Facebook can easily support Open Social any time they want. They probably won't do so right away, but in the long run, it will probably be a no-brainer for them, because then they will pick up whatever Open Social app developers who aren't also Facebook developers.
Is this good for the web?
This is very, very good for the web. Open Social is the kind of standard that web developers love, and can easily use. I think it will become a standard part of many developers' toolkits. It builds on HTML and Javascript, many people can support it, and it will be interoperable -- I know that because it already is interoperable for the partners in this week's launch. It's all good.
How will Ning support Open Social?
We will aggressively support Open Social in every conceivable way, including but not limited to:
* Being an outstanding container. Open Social apps will be able to run easily and reliably inside Ning social networks -- all 113,000+ of them. Ning Network Creators will be able to quickly and easily add Open Social apps to their networks, and Ning users will be able to quickly and easily add Open Social apps to their profile pages.
* Being an app publisher. Ning already automatically produces Facebook apps for every Ning network -- specifically, video, photo, and music players -- using the Facebook proprietary platform approach. We will do the exact same thing for Open Social -- we will automatically produce Open Social apps for every Ning network.
You mentioned that Open Social containers can implement additional Javascript or web services APIs -- won't that break compatibility?
No, I don't think so. Think of it this way. As an app developer, you have three options:
* You can write purely to the Open Social API. If you do this cleanly enough, your app will run unchanged in any compliant Open Social container. (Google is actually not making this claim -- they're calling Open Social "learn once, write anywhere", which is not the same as "write once, run anywhere". But in practice, the API is simple enough that "write once, run anywhere" should work just fine.)
* You can write an app that is specific to one container. For example, there may be some apps that make sense only in LinkedIn -- business-related apps, say. There may be other apps that make sense only in Ning -- apps that presume that users are creating their own social networks, say. And there may be yet other apps that only make sense in Salesforce.com, which will also be an Open Social container. In those cases, you are targeting your app to one specific container, and so using whatever additional APIs that particular container provides, in addition to the Open Social APIs, is a no-brainer.
* Finally, you can write an app that behaves differently depending on which of several containers it's running in. Your app just discovers which container it's running in, and then does whatever it wants on a per-container basis.
No standard can possibly anticipate all of the different use cases and scenarios people will think up. Standards that try to anticipate all of the different use cases fail, because they are too complex and generally impossible to implement. Standards that standardize behavior that is clearly standard, while leaving open the ability to innovate on top, succeed. The history of this kind of thing is quite clear, and Open Social is on the right side.
On the radar with OpenSocial
O'rielly reports on Google OpenSocial
http://radar.oreilly.com/archives/2007/10/google-opensocial-api-launch.html
http://radar.oreilly.com/archives/2007/10/google-opensocial-api-launch.html
Google OpenSocial opens on Thursday
Techcrunch recently reported on OpenSocial
What does it mean to developers and who are its partners?
http://www.techcrunch.com/2007/10/30/details-revealed-google-opensocial-to-be-common-apis-for-building-social-apps/
What does it mean to developers and who are its partners?
http://www.techcrunch.com/2007/10/30/details-revealed-google-opensocial-to-be-common-apis-for-building-social-apps/
Subscribe to:
Posts (Atom)
